[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: summary: lilypond, lambda, and local-eval
From: |
David Kastrup |
Subject: |
Re: summary: lilypond, lambda, and local-eval |
Date: |
Fri, 16 Dec 2011 10:16:43 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) |
Mark H Weaver <address@hidden> 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
- summary: lilypond, lambda, and local-eval, Andy Wingo, 2011/12/15
- Re: summary: lilypond, lambda, and local-eval, David Kastrup, 2011/12/15
- Re: summary: lilypond, lambda, and local-eval, Hans Aberg, 2011/12/15
- Re: summary: lilypond, lambda, and local-eval, Mark H Weaver, 2011/12/16
- Re: summary: lilypond, lambda, and local-eval, Mark H Weaver, 2011/12/16
- Re: summary: lilypond, lambda, and local-eval, Mark H Weaver, 2011/12/16
- Re: summary: lilypond, lambda, and local-eval,
David Kastrup <=
- Re: summary: lilypond, lambda, and local-eval, Mark H Weaver, 2011/12/18
- Re: summary: lilypond, lambda, and local-eval, Andy Wingo, 2011/12/18
- Re: summary: lilypond, lambda, and local-eval, Noah Lavine, 2011/12/18
- Re: summary: lilypond, lambda, and local-eval, David Kastrup, 2011/12/18
- Re: summary: lilypond, lambda, and local-eval, Noah Lavine, 2011/12/18
- Re: summary: lilypond, lambda, and local-eval, Mark H Weaver, 2011/12/19
Re: summary: lilypond, lambda, and local-eval, Andy Wingo, 2011/12/16
- Re: summary: lilypond, lambda, and local-eval, David Kastrup, 2011/12/16
- Re: summary: lilypond, lambda, and local-eval, Mark H Weaver, 2011/12/16
- Re: summary: lilypond, lambda, and local-eval, Hans Aberg, 2011/12/16