[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CPS != call/cc
On Wednesday, August 6, 2003, at 08:01 PM, Dan Sugalski wrote:
> At 1:10 PM -0400 8/6/03, John Clements wrote:
>> On Wednesday, August 6, 2003, at 11:00 AM, Peter J. Wasilko, Esq.
>>>> Well... it can sort of help, but there are some limits. Multiple
>>>> stacks tend to solve other problems, and they're certainly useful,
>>>> but for a CPS scheme you really need more of a linked frame system
>>>> than a stack system, since the control information really builds up
>>>> tree (albeit one often with a single branch) rather than a stack.
>>> I see, so what would an optimal hardware architecture be for
>>> supporting CPS?
>> CPS, or continuation-passing-style, is not the same thing as a
>> language that includes primitives for continuations.
> While true, the threads are all in the context of Parrot, so its all
> semantics and no language. (Well, unless you consider assembly a
> language, but that's stretching things a bit) The continuations we use
> as part of the CPS scheme are all first class continuations--the only
> difference between them and first class continuations you make
> explicitly is that sometimes you don't have to explicitly make them.
... and that's a HUGE difference. A difference in expressiveness.
All I'm saying is this: don't give another meaning to the well-defined
term CPS by using it to refer to any program that captures
continuations with call/cc or other similar primitives. That's not
what it means.