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

[David Kastrup <dak@gnu.org>]

Mark H Weaver <mhw@netris.org> writes:

> 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 :)

And I consider this _very_ exciting work in progress.  One of the things
that the current development line of GCC markets is "compiler plugins".
Here GUILE has an opportunity to offer similar functionality in a
natural, Scheme-like manner with little complexity exposed to the user
of this feature, and apparently not all that much complexity needed to
get added to the compiler: it is more a matter of factoring the
complexity that has to be there anyway in a proper way.  Which actually
might make the compiler code easier to understand und modify even if you
don't end up using local-eval.

Being able to employ this in Lilypond to simplify things would certainly
be a nice side benefit, but this has the potential to simplify and
facilitate quite more complex scenarios with simple tools.

It would be _much_ _much_ simpler to use than GCC plugins.  And the
better it integrates with the compiler as a whole, the less reason would
be there _not_ to use it whenever it might be useful.

-- 
David Kastrup