On Feb 21, 2007, at 1:42 AM, John Cowan wrote:
> Felix Klock scripsit:
>
>> Am I right in thinking that in all of the sample implementations of
>> parameterize that have been presented so far, the body of the
>> parameterize expression is not in tail position with respect to the
>> entire expression?
>>
>> I do not know what Scheme implementations besides PLT Scheme support
>> this, but it is one of the potential properties of parameterize that
>> I think we should be discussing.
>
> Is this done using the Bacon/Baker technique?
>
> http://www.accesscom.com/~darius/writings/dynatail.html
> http://home.pipeline.com/~hbaker1/BuriedStale.html
The way PLT Scheme does it is via "continuation marks." Other people
on this list can do a better job than I explaining the details, but
the quick version of the idea is that the continuation structure is
extended to carry particular values (or more generally, key/value
pairs) and updates to these values are done in a fashion that
preserves tail recursion.
From my preliminary skimming of the links you gave, it seems like
continuation marks might be considered a useful generalization of the
ideas presented there:
1. Continuation marks allow different modules to install continuation
marks in a safe-for-space fashion without the two modules being aware
of each other. (Even when they each call each other tail recursively.)
2. Continuation marks provide a controlled interface to the sort of
stack inspection described by Bacon. There's no need to hack on the
interpreter: they're already there, and you get to install your own
marks in your code.
You can find examples illustrating these advantages in John Clements'
work (as well as motivating examples for providing continuation marks
in the first place.)
On the other hand, Clements' thesis does not cite Bacon or Baker. I
infer that either John was not aware of their work, or there is some
key distinction differentiating PLT's continuation marks from the
Bacon/Baker approach.
Anyway, I am not suggesting that we add continuation marks to R6RS.
I mainly wanted to point out that:
1. There are other approaches to implementing parameterize besides
using dynamic-wind
2. These other approaches may have positive characteristics (such as
improved asymptotic space efficiency)
3. If R6RS standardizes on an interface for parameters, it should
not rule out this sort of implementation for parameterize. (I do not
know if any of the proposed parameter interfaces would do so.)
-Felix
Received on Wed Feb 21 2007 - 03:01:02 UTC