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

[David Kastrup]

Mark H Weaver <address@hidden> writes:

>> 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).

I don't think I would feel as strong about it if the argument was a
module, implicating top-level.  It is probably not all that easy to get
the-environment at top level.

>> 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.

It might come handy to have local-eval not balk upon getting a module,
but without letting it set the current module.  At times, this
functionality might come in handy.  It would also be clear then why eval
would have to balk on every non-module (== non-top-level) environment.

> 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.

I am not saying that the actual code would need to work.  It was more
intended as a show of equivalences.

-- 
David Kastrup