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

[Mark H Weaver]

Andy Wingo <address@hidden> writes:

> On Tue 17 Jan 2012 22:02, Mark H Weaver <address@hidden> writes:
>
>> 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.
>
> FWIW, Racket circumvents this problem nicely, with what they call
> "continuation marks".  We might be able to reuse their strategy in our
> with-fluids implementation.

I don't see how continuation marks could solve this problem.  They avoid
adding more frames to the stack, but that's not enough.  The R5RS says:

  A Scheme implementation is properly tail-recursive if it supports an
  unbounded number of active tail calls.  A call is _active_ if the
  called procedure may still return.

Therefore, even if you save the old value of (current-module) cleverly
somewhere other than the stack, these old values would still in general
use O(n) space, where N is the number of active calls to `eval'.

On the other hand, if `eval' stores the saved (current-module) within
the continuation outside of `eval', overwriting whatever value might
already be stored there (thus avoiding the O(n) problem), this would be
incorrect, because that outer continuation might have been stored
somewhere, and it should _not_ restore (current-module).

Fundamentally, if `eval' wishes to restore the former (current-module)
after evaluation of the expression, then the inner continuation of the
expression _must_ be semantically different than `eval's outer
continuation: the inner one _must_ restore (current-module), and the
outer one _must_ _not_ modify (current-module).

Or am I missing something?

    Thanks,
      Mark