Re: A plea for local-eval in 2.0.4

[David Kastrup]

Mark H Weaver <address@hidden> writes:

> I'd like to make one last plea to include my simple `local-eval'
> implementation in 2.0.4.  My hope is that if we can ship it soon enough,
> versions of Guile without `local-eval' will be rare enough to enable
> Lilypond to eliminate their ugly hacks and simply declare that Guile
> 2.0.0-2.0.3 are unsupported.

We won't be able to declare this anytime soon, but it would likely be
feasible to include a fallback implementation.  It would make little
sense to include a fallback that differs from 2.0.4 however.

I am still fuzzy on what local-eval will do when the current module at
the time of the-environment is different from that at the time of
local-eval.

Since the current module, even if nominally the same, can contain
different variables at the time of local-eval, my take on that would be
to not make it part of the environment at all.  That is, everything that
is not reachable through local scopes is not part of the environment.

While this would indeed be the most convenient option with regard to the
LilyPond case, I think that other options make less sense in general (or
cause semantics that do more harm than help).

Note that I have not actually checked what Guilev1 does here with regard
to the-environment.  If we reconstitute its use, I'll probably set the
module explicitly in the argument of the local-eval call if it turns out
to be necessary.

> I worked very hard to produce a simple and maintainable implementation
> of `local-eval' in time for 2.0.4, so that we might rectify this
> unfortunate Lilypond unhappiness.  It would be a shame if that work
> were wasted.

As I said, we won't get around catering for 2.0-2.0.3 manually for quite
a while.  But I would not want to be doing this with code different from
what shall end up in Guile eventually.

-- 
David Kastrup