David Kastrup <d...@gnu.org> writes:
> Mark H Weaver <m...@netris.org> 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
