Re: [PATCH] local-eval, local-compile, and the-environment (v3)

[David Kastrup <dak@gnu.org>]

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

> Here's the third version of my simple `local-eval' patch.
> Notable changes from last time:
>
> * Pattern variables are now captured properly.
> * `the-environment' now works as advertised within macro definitions.
> * Added doc strings for `local-eval' and `local-compile'.
>
> I am open to reimplementing this in a different way for 2.0.5, along the
> lines suggested by Andy.  I'd like to capture all bindings, not just the
> ones reachable by symbols.  I'd like to support _all_ lexical bindings,
> including local syntax transformers.  I'm also warming to the idea of
> standardizing on variable objects as a way to represent mutable
> lexicals.  However, there's no time to do this for 2.0.4.  That job
> depends on other big jobs, notably a major overhaul of the evaluator.
>
> Nonetheless, I think it is very important to include this simple
> implementation in 2.0.4.  This is a BUG FIX, the bug being that
> `local-eval' was removed from underneath Lilypond's feet.  A partial
> implementation (that almost certainly does everything they need) is
> _far_ better than none at all.  Lilypond can only depend on `local-eval'
> if installations of Guile without it are quite rare.  If we can get this
> in 2.0.4, there's hope that we can make Guile 2.0.[0-3] rare.
>
> Please consider it.  This implementation is quite robust.

I am not altogether comfortable with pushing a "temporary fix" for the
sake of LilyPond when we'll get another behavioral change with the next
version.  LilyPond would be mostly left in the rain for older versions
unless we made that implementation a fallback within our own sources.
However, there would be no point in adopting a fallback implementation
that would not also work with 2.0.0-2.0.3.

As far as I understand, this implementation could be pulled into a
separate file and used for bridging the 2.0.0-2.0.3 gap.  If it is solid
enough to be maintained as 2.0.4, it would likely be a reasonably good
bet.

Of course, a version that would be tighter integrated with the compiler
and optimizer would seem like a more powerful prospect, but it also
sounds that it would need more thorough maintenance to not fall into bit
rot.

I am not sure that the reasons for not permitting definition context in
local-eval are not of somewhat more theoretical than practical nature,
and in particular it sounds to me like "I'm also warming to the idea of
standardizing on variable objects as a way to represent mutable
lexicals" could suggest that the strength of even the theoretical
reasons might get eroded further.  Of course, _calling_ mutual recursive
functions in execution before the second part has been defined will
remain unfeasible.

-- 
David Kastrup