[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Mark H Weaver
Subject: Re: summary: lilypond, lambda, and local-eval
Date: Fri, 16 Dec 2011 03:49:09 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

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

> 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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]