[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: call/cc and recursive vm invocations
From: |
Andy Wingo |
Subject: |
Re: call/cc and recursive vm invocations |
Date: |
Sun, 07 Mar 2010 20:34:36 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) |
Greetings!
On Sun 07 Mar 2010 17:55, address@hidden (Ludovic Courtès) writes:
> 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?
That's correct, and the reason was that there were no delimiters
produced by start-stack, because start-stack was stubbed out.
>>> 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.
Point taken; I had assumed this expression was at the repl (which
presumably would wrap each expression in a prompt). What I mean to say
is that your case #2 will generally work but sometimes not.
Incidentally, this unfortunate situation of "generally working but
sometimes not" seems endemic to prompts, as they rely on a dynamically
bound prompt, which might not be there, and whose presence cannot be
statically checked for, AFAIK.
>> 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.
Of course. Of course it is also unlikely that said library could handle
multiple returns, unless it were specifically designed for it.
FWIW, Guile-GNOME almost always has to do the with/without dance.
Ciao,
Andy
--
http://wingolog.org/