Re: Eval, tail calls, (current-module), and backward compatibility

[Mark H Weaver]

David Kastrup <address@hidden> writes:

> Mark H Weaver <address@hidden> writes:
>
>> (current-module) should be relevant only at the beginning of
>> macro-expansion: before any program transformations are performed,
>> (current-module) is "baked" into every symbol of the top-level form.
>> (psyntax actually does this lazily, but the effect is the same).
>>
>> After that, (current-module) should be completely irrelevant to the rest
>> of compilation and evaluation.
>
> It isn't if you call it in the code.

Indeed, and that's potentially a problem.

> Personally, I am not sure that it
> should reflect the second argument of eval if that is different from the
> current module in which eval has been called.
>
> Does R5RS have an opinion on modules and eval?

The R5RS has no module system, but it does mandate that `eval' requires
a second parameter: the "environment-specifier".  It says almost nothing
about these environment-specifiers other than to mandate a few standard
procedures that must return them: (scheme-report-environment <version>),
(null-environment <version>), and optionally (interactive-environment).
<version> is the exact integer <n> in R<n>RS, e.g. 5 means the R5RS.

The R5RS has no notion of a user-specified "current environment".
Indeed, there is no need for such a concept if it must always be passed
as an explicit parameter to `eval'.  Therefore, there's no need to
save/restore the current environment (or anything like it) in the R5RS.

The fact that the R5RS requires `eval' to be properly tail-recursive
implies that it cannot do _anything_ after evaluation of the provided
expression, because the continuation of the expression must be
semantically equivalent to the continuation of `eval' itself.

Therefore, the R5RS leaves no possible way for a complaint `eval' to
restore the previous value of (current-module) after evaluation.
Indeed, this is prohibited at a semantic level.

      Mark