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

[Mark H Weaver <mhw@netris.org>]

David Kastrup <dak@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