Re: summary: lilypond, lambda, and local-eval

[Mark H Weaver <mhw@netris.org>]

I wrote:
> For now, I will describe a method that I suspect would do the right
> thing without any new compiler interfaces, though not as efficiently or
> robustly: Simply compile the same general-purpose dispatcher as before,
> except replace the #f (from the first case-lambda clause) with the
> expanded local expression:

Although this should result in the same set of captured lexicals, it
does not necessarily guarantee that the closure slots will be in the
same order.  This could be perhaps be solved by always sorting the
captured lexicals by name, but that would slow down the compiler.
Depending on how the compiler works, it might be sufficient to move the
<expanded-local-expression> case to end of the case-lambda, but that's
definitely fragile.

So, I guess this all shows that `local-eval' really shouldn't be
implemented this way, but rather by creating a new internal interface to
the compiler that ensures that the closure slots are exactly the same as
before.

> Most passes of the compiler will pretend that (the-environment) is
> replaced by tree-il code corresponding to the following standard scheme
> code:

I should also mention that perhaps, instead of simply "pretending", it
might make sense to actually replace (the-environment) with the standard
scheme code I gave as early as possible, so that later passes will never
even see `the-environment' tree-il nodes.  It need only be late enough
so that the list of visible lexical variable names is known at that
point.

Apologies for sending multiple messages so quickly.
Obviously this is a work-in-progress :)

      Mark