how does klisp implement continuations?

[Mariano Guerra]

does it do some kind of transformation on the input to continuation
passing style or does it implement it in the interpreter? [1]

[1] I'm new to this continuation implementation thing so this question
may make no sense :)

[Andres Navarro]

I think I already covered this in a previous klisp internals mail.

Continuations are implemented in klisp in the simplest way: by allocating frames in the heap instead
of a stack.
Continuation capturing just becomes pointer capturing. The price to pay for this is, of course, that frame
allocation is slower even in the case that continuations are not captured, because frames need to be
allocated from the heap and collected by the GC.

There are of course other alternatives to this.

As for transformating the input, you will find that it isn't as straightforward in  Kernel as it is in scheme
for a number of reasons. One of course is that analyzing Kernel source code is harder
(because of first order operatives and environments) the other is that unlike in scheme, Kernel
continuations are not procedures (applicatives). A lot of work could be done in this are thou.

Regards,
Andres Navarro

[Andrew Gwozdziewycz]

On Tue, Jul 3, 2012 at 11:36 AM, Andres Navarro <canav...@gmail.com> wrote:
> I think I already covered this in a previous klisp internals mail.
>
> Continuations are implemented in klisp in the simplest way: by allocating
> frames in the heap instead
> of a stack.
> Continuation capturing just becomes pointer capturing. The price to pay for
> this is, of course, that frame
> allocation is slower even in the case that continuations are not captured,
> because frames need to be
> allocated from the heap and collected by the GC.
>
> There are of course other alternatives to this.

It seems painful to pay for continuations when they aren't often
captured. Is the alternative allocating frames on the stack and then
copying the stack into the heap when captured better or worse in
practice? Seems like it could go either way depending on how often you
capture...

--
http://www.apgwoz.com

[Andres Navarro]

Yes, copying would be an alternative.  There are also mixed approachs. 

I valued simplicity over performance in implementing klisp, if only because
we still don't have any kind of significant ammount of kernel code to profile. 

I believe after having a usable implementation we can advance to bigger and more
useful Kernel programs and that better implementations will follow from there.

A case of avoiding premature optimization, if you will.

Regards

[Mariano Guerra]

On Tue, Jul 3, 2012 at 5:55 PM, Andres Navarro <canav...@gmail.com> wrote:
> Yes, copying would be an alternative. There are also mixed approachs.
>
> I valued simplicity over performance in implementing klisp, if only because
> we still don't have any kind of significant ammount of kernel code to
> profile.
>
> I believe after having a usable implementation we can advance to bigger and
> more
> useful Kernel programs and that better implementations will follow from
> there.
>
> A case of avoiding premature optimization, if you will.

+1 :)

just for information purposes, I think this may be useful in this case
(too long to read and too little time at the moment :)

http://www.cs.indiana.edu/~dyb/pubs/3imp.pdf