[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Eval, tail calls, (current-module), and backward compatibility
From: |
Mark H Weaver |
Subject: |
Re: Eval, tail calls, (current-module), and backward compatibility |
Date: |
Wed, 18 Jan 2012 14:58:49 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) |
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
- Eval, tail calls, (current-module), and backward compatibility, Mark H Weaver, 2012/01/16
- Re: Eval, tail calls, (current-module), and backward compatibility, David Kastrup, 2012/01/17
- Re: Eval, tail calls, (current-module), and backward compatibility, Mark H Weaver, 2012/01/17
- Re: Eval, tail calls, (current-module), and backward compatibility, Andy Wingo, 2012/01/18
- Re: Eval, tail calls, (current-module), and backward compatibility,
Mark H Weaver <=
- Re: Eval, tail calls, (current-module), and backward compatibility, Andy Wingo, 2012/01/18
Re: Eval, tail calls, (current-module), and backward compatibility, Ludovic Courtès, 2012/01/18
- Re: Eval, tail calls, (current-module), and backward compatibility, Andy Wingo, 2012/01/18
- Re: Eval, tail calls, (current-module), and backward compatibility, Ludovic Courtès, 2012/01/18
- Re: Eval, tail calls, (current-module), and backward compatibility, Andy Wingo, 2012/01/18
- Re: Eval, tail calls, (current-module), and backward compatibility, Ludovic Courtès, 2012/01/18
- Re: Eval, tail calls, (current-module), and backward compatibility, Andy Wingo, 2012/01/18
Re: Eval, tail calls, (current-module), and backward compatibility, David Kastrup, 2012/01/21
- Prev by Date:
Re: Eval, tail calls, (current-module), and backward compatibility
- Next by Date:
Re: Eval, tail calls, (current-module), and backward compatibility
- Previous by thread:
Re: Eval, tail calls, (current-module), and backward compatibility
- Next by thread:
Re: Eval, tail calls, (current-module), and backward compatibility
- Index(es):