Re: call/cc and recursive vm invocations

[Ludovic Courtès]

Happy septidi!

Andy Wingo <address@hidden> writes:

> On Sun 07 Mar 2010 00:23, address@hidden (Ludovic Courtès) writes:
>
>> Andy Wingo <address@hidden> writes:
>>
>>> In case you haven't noticed yet, if you get an error at the REPL and ask
>>> for a backtrace from the debugger, you get not only the frames that
>>> pertain to your own computation, but also frames from the REPL
>>> implementation itself. That's not good, and it's a regression.
>>
>> It’s a regression in ‘make-stack’, right?  Can you remind me what caused
>> it?
>
> It's more that start-stack didn't work, see:
>
>     d79d908ef0c421798b79bd72403b2a8fd196173c
>     373d251b4dd5153c6909898dc225d37d4948e3d6
>     107139eaadab946e9713748cdeacd07b22a181db

That was in Sept. 2008, but now ‘(make-stack #t)’, at least, works,
right?  (See, e.g., ‘stack->frames’ in ‘eval.test’.)

What doesn’t work is ‘make-stack’ with an argument other than #t, right?

>        (filter (lambda (x)
>                  (call-with-continuation-prompt (lambda () (call/cc ...))))
>                lst)

(For those wondering:
<http://docs.plt-scheme.org/reference/cont.html#%28def._%28%28quote._~23~25kernel%29._call-with-continuation-prompt%29%29>.)

>>   2. Failure at the time the continuation is invoked, because it’s
>>      invoked in the context of a different VM invocation than
>>      ‘call/cc’.  For example:
>>
>>        (call/cc (lambda (k)
>>                   (filter (lambda (x)
>>                             (k ...))
>>                           lst)))
>>
>> You were referring to case #2.  Is this correct?
>
> No, actually this would usually work. The problem comes when the call/cc
> is not in the same VM invocation as the prompt;

Sure, but this example doesn’t use any prompt; IOW, the default prompt
is at the beginning of the program.

[...]

>> That’s for a REPL startup, but we have lots of primitives written in C.
>> I’d expect a ‘call/cc’ failure to be likely in an arbitrary program.
>> What do you think?
>
> Yeah it looks like in libguile there are about 200 instances of
> scm_call_*, but most of them probably aren't sensibly rewindable.
>
> Given that call/cc is not exposed to C programs,

I’m also assuming that ‘call/cc’ is only ever used from Scheme.

> except via the now-internal scm_make_continuation, I don't expect
> breakage on the C front;

The examples of possible breakage above are written entirely in Scheme.

> and on the Scheme front, Guile 1.8 regularized a lot of that code by
> making scm_with_guile/scm_without_guile almost mandatory,

One is only supposed to leave guile mode when doing something that may
block, like I/O.  So you could have a C library that calls back to
Scheme without ever leaving guile mode.

> We're just left with people capturing continuations in filter functions
> &c, possible but not likely :)

I feel that this is more likely than you think.  :-)  There are all the
cases inside libguile (we can eliminate some of them but perhaps not
all, notably because it’d be a bit of work), and bindings to C library
that callback to Scheme (Guile-Avahi, Guile-GNOME I guess, etc.).

>>> Practically speaking... I think I can delimit call/cc with not much work
>>> (perhaps tomorrow). But it is a visible change (if you're looking), so I
>>> wanted to put this mail out there to get comments. I had thought this
>>> was a 2.2 feature, but given the make-stack implications, I'm thinking
>>> it's a 1.9.9 feature. Reactions?
>>
>> I’d be rather inclined to wait until 2.2.  While I agree that the
>> usability of ‘call/cc’ is currently limited for the reasons you gave, I
>> fear that doing away with the C stack capture may render ‘call/cc’ even
>> less usable for code that exists, mixes C and Scheme, and has been able
>> to work around the limitations.
>>
>> I also think that we should be stabilizing things if we want to release
>> Real Soon Now, and that 2.2 doesn’t have to wait until 2020 anyway.  :-)
>
> Hm, OK :) I will finish my patch today then and push it to a branch. But
> let me know if you have a change of heart :)

Sure, thanks!  :-)

Ludo’.