help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The fundamental concept of continuations


From: George Neuner
Subject: Re: The fundamental concept of continuations
Date: Thu, 11 Oct 2007 03:18:34 -0400

On Wed, 10 Oct 2007 12:49:58 +0200, David Kastrup <dak@gnu.org> wrote:

>gnuist006@gmail.com writes:
>
>> Again I am depressed to encounter a fundamentally new concept that I
>> was all along unheard of. Its not even in paul graham's book where i
>> learnt part of Lisp. Its in Marc Feeley's video.
>>
>> Can anyone explain:
>>
>> (1) its origin
>> (2) its syntax and semantics in emacs lisp, common lisp, scheme
>> (3) Is it present in python and java ?
>> (4) Its implementation in assembly. for example in the manner that
>> pointer fundamentally arises from indirect addressing and nothing new.
>> So how do you juggle PC to do it.
>> (5) how does it compare to and superior to a function or subroutine
>> call. how does it differ.
>
>Basically, there is no difference to function/subroutine call.  The
>difference is just that there is no "call stack": the dynamic context
>for a call is created on the heap and is garbage-collected when it is
>no longer accessible.  A continuation is just a reference to the state
>of the current dynamic context.  As long as a continuation remains
>accessible, you can return to it as often as you like.

Yes and no.  General continuations, as you describe, are not the only
form continuations take.  Nor are they the most common form used.  The
most common continuations are function calls and returns.  Upward
one-shot continuations (exceptions or non-local returns) are the next
most common form used, even in Scheme.

Upward continuations can be stack implemented.  On many CPU's, using
the hardware stack (where possible) is faster than using heap
allocated structures.  For performance, some Scheme compilers go to
great lengths to identify upward continuations and nested functions
that can be stack implemented.

George
--
for email reply remove "/" from address


reply via email to

[Prev in Thread] Current Thread [Next in Thread]