David Kastrup <d...@gnu.org> writes: > guile> (let ((x 2)) (eval '(begin (define x 4) x) (current-module))) > 4 > guile> x > 4 > guile> > > Right through to the top. And we couldn't do that in local-eval. But > it also has no qualms just because previously evaluated forms would have > used a previous definition of x. But that's because of top-level. Eval > is always top-level, and define acts like set! there.
Yes, top-level is a very different animal than an internal body, despite the superficial syntactic similarities. > What if the-environment had been taken at top-level (basically just > carrying the information of (current-module))? Should local-eval then > behave accordingly? If so, could we not just fold eval and local-eval > into one function? This is a good question. Unfortunately, there is a non-trivial difference in the semantics of `eval' vs `local-eval'. `eval' temporarily sets the (current-module) to its second argument during evaluation of the expression. `local-eval' does not do this, and as I recall that was something you felt strongly about (and I agree). > And one could then define > (define current-module > (let ((top-level (the-environment))) > (lambda () (eval '(the-environment) top-level)))) > if the-environment just returns the current module when at top level? I see what you're getting at, but this would be a bad idea, because it still makes sense to have `module' be an independent type. Also, in the code above, `top-level' would not actually be a top-level environment, because (the-environment) is not a top-level form. If you put (define x 5) in place of (the-environment), it would not set a top-level variable; it would produce an error. Mark