[plt-scheme] "identifier used out of context" after two local-expands

On 5/30/06, Matthias Felleisen <matthias at ccs.neu.edu> wrote:
> On May 29, 2006, at 8:44 PM, Kimberley Burchett wrote:
> >  This second
> > approach actually works *too* well -- I can no longer tell the
> > difference between an if that was inserted by the search-and-replace,
> > versus one that was inserted by the expansion of some other macro.
> > The two cases have very different semantics, so it is important to
> > distinguish between them.
>
> Why don't you replace the if with eff and assign some equivalent
> semantics with a second macro? -- Matthias

If you mean replacing if with eff in the original source code, I can't
do that since it would break the transparency of FrTime.  If on the
other hand you mean replacing the if with some other macro and *then*
doing an expand, that's basically what I've ended up doing, except I
did it by adding a syntax-property to the kernel if instead of using a
different macro (using a different macro wouldn't have worked anyway,
since I'm expanding all the way down to kernel syntax).  The approach
works well enough, subject to the two hacks I mentioned previously.

It still seems unfortunate, however, that there's no way to use
local-expand's stoplist to partially expand a form and then continue
that expansion later.

> P.S. If you are compiling, why don't you write a macro per form you
> wish to compile and keep compile-time information in a variable visible
> at expansion time? That's what the module system is for, no?

I think you're suggesting replacing the definition of each form in
FrTime with a different definition that does compilation instead.
Currently I'm transforming an entire syntax tree all at once rather
than transforming it one form at a time.  The main reason for this is
that I need to do things like maintain a symbol table.  It' seems
easier to maintain a symbol table as local state during a recursive
depth-first traversal of the AST, rather than having macros
communicate indirectly through an expand-time global variable.

Another reason for not replacing the definitions of standard FrTime
forms is that I'm still trying to validate my ideas, and I don't yet
want to take on the added task of integrating smoothly with
non-compiled FrTime.  Once I get further along, I will certainly
integrate with the FrTime language level.