Re: Non-stack-copying call-with-current-continuation?

[Andy Wingo]

Hello,

On Sun 04 Mar 2012 14:59, David Kastrup <address@hidden> writes:

> Andy Wingo <address@hidden> writes:
>
>> This is not true in Guile, where symbols can be garbage collected.
>
> The symbol name is not garbage collected.  That is the difference
> between gensym and make-symbol.

Not sure I catch your meaning here...

>> But you ask about a specific point, here: an abort to a prompt is
>> basically boils down to a longjmp to the prompt's handler.  The
>> partial continuation is logically passed as an argument to the
>> handler.
>
> But where does the "partial continuation" start and where does it end?

It starts at the abort, and is delimited by the prompt.  Or you can see
it as the other way around.

> If I am doing a "longjmp to the prompt's handler", how can it be that
> the calling stack frame inside of the thunk that is supposed to be
> exited can finish a calculation?

You longjmp, yes: but after having reified (or not) the continuation.
It's the continuation that lets you continue.

> Where is the difference between
>
> (+ 34 (abort-to-prompt 'foo))
>
> and
>
> (let ((x (abort-to-prompt 'foo))) (+ 34 x)) ?

There is no semantic difference.

> Why is the first allowed to complete and return a result, and the second
> (presumably) not?  Or _if_ the second is allowed to complete, what does
> "abort" in "abort-to-prompt" even mean?

Whether it is allowed to complete or not depends on the prompt's
handler, as I mentioned before.

Here is an analogy.  Consider a prompt as creating a new process, in the
UNIX sense.  Consider "abort" as calling abort() and dumping core (or
not).  Consider calling the partial continuation as taking the core file
and running it as a program (as used to be possible in some UNIX
systems).

Sometimes you enable cores because you are interested in them.
Sometimes you just want to let a process quit and return a value.  The
analogy with reifying continuations or not is clear, I hope.

> All this does not really make discernible sense to me.  Whereas call/ec
> has rather clear semantics and usage.

Please do use call/ec, if you prefer its interface.

> The one thing that is not self-evident is its behavior in case of
> misuse, namely when it is asked to do a job only call/cc can.

For the implementation based on "throw", you would get an error that
would be caught by the nearest (catch #t ...).  For prompts, you would
get an error "abort to unknown prompt", which would also be caught by
the nearest (catch #t ...), or a catch of `misc-error'.  (Guile's error
handling is not very systematic right now; something to work on.)

Regards,

Andy
-- 
http://wingolog.org/