[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: call/cc and recursive vm invocations
From: |
Ludovic Courtès |
Subject: |
Re: call/cc and recursive vm invocations |
Date: |
Sun, 07 Mar 2010 17:55:32 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
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’.