Mark H Weaver <m...@netris.org> 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
