[r6rs-discuss] [Formal] Replacing the import's "for" syntax with implicit phasing

From: Abdulaziz Ghuloum <aghuloum>
Date: Fri Nov 17 03:47:20 2006

On Nov 17, 2006, at 1:37 AM, Felix Klock wrote:
> Okay, so I think we agree that this example could have been just
> (import (for defsyntax run)). The compilation of D is much simpler
> than we thought, yada yada yada.
>
> This means that, at the moment:
>
> 1.) Your formal comment does not have an example of your first
> difficulty:
> "** The phased model fails to capture the users' intentions"
> The onus is on you to provide a new example of this issue.

Here is another example. I'm trying to keep it simple to illustrate
the point.

Suppose the library F is defined as follows:

(library F
   (export f)
   (import r6rs)
   (define f 12))

Also, suppose G imports F because it needs it:

(library G
   (export g)
   (import r6rs (for F expand))
   (let-syntax ([m (lambda (_) f)])
     (define g (m)))
   --other-stuff--)

Expanding G causes
   F to be visited (not needed: doesn't use any of F's macros)
   F to be invoked (needed to evaluate F's f)

Visiting G causes
   F to be visited (not needed: doesn't use any of F's macros)
   F to be invoked (not needed: doesn't use any of F's variables)

Invoking G causes nothing to happen to F (correctly)

(library H
   (export)
   (import r6rs (for G run))
   --other-stuff--
   (display g))

Expanding H causes
   G to be visited (not needed: doesn't use any of G's macros)
     F to be visited (not needed: doesn't use any of F's macros)
     F to be invoked (not needed: doesn't use any of F's variables)

Visiting H causes
   G to be visited (not needed: doesn't use any of G's macros)
     F to be visited (not needed: doesn't use any of F's macros)
     F to be invoked (not needed: doesn't use any of F's variables)

Invoking H causes
   G to be invoked (needed to evaluate G's g)

There are more unneeded actions performed in this very simple example
than needed actions.

My intention from importing F in G for expand was to use it locally
only. Unfortunately, the import propagated all over the place. Does
this qualify as a simple example of the explicit phases not capturing
my intentions?

> 2.) I agree with your second difficulty:
> "** Macro helpers are unexpressible"
> and I agree that this should be fixed.

Yes. It should be fixed.

> But this issue does not justify the introduction of phase inference;
> that is like saying "The simply-typed lambda calculus can't express
> polymorphic functions. Let's fix it by adding type inference." Why
> is this response incorrect? Because if all you do is infer the same
> simple types you had before, you haven't fixed the problem. The
> solution is to extend the type language with a polymorphic type
> constructor!

We did explore many paths to solve the problem. None of them worked.
This one did work, very elegantly. If you have a better solution,
please share with us.

> In general, when the problem is insufficient inexpressiveness, then
> you should first deal with the expressiveness problem directly.

We did try. Every solution was just uglier, more restrictive (as in
you express one thing by restricting another), more verbose, etc.

> If the solution to the expressiveness problem involves the addition of
> unwieldy syntactic constructs in order to be able to express what we
> want, then sure, we should attack the problem of inferring those
> constructs. But we need to agree on the semantics of the library
> construct; I would prefer that we finish that job before attacking
> surface syntax issues, if possible.

What do you mean "we need to agree on the semantics of the library
construct"? My proposal is about the semantics as they are in the
current 5.91 draft.

> 3.) As for your third difficulty:
> "** Manual derivation of import phases is complex"
> we have direct evidence that it can be subtle, in the form of the
> mistake that you made in your first example.
>
> I do think that the semantics of phases are not specified in a
> sufficiently clear manner in R^{5.91}RS. I get a better idea of what
> phases are for when reading Flatt's "Composable and Compilable Macros"
> paper [1]. This as a sign that the text related to phases needs
> revision, independently of whether phase inference is added. (It
> might also be a sign that the semantics of phases needs revision,
> which is a related but distinct issue.)

I think the semantics in R5.91RS are sufficiently clear about what
needs to be performed when. If it does not follow the you-want-it-when
paper, then that's another issue. I was not proposing to change PLT's
module system.

Aziz,,,
Received on Fri Nov 17 2006 - 03:47:15 UTC