Re: call/cc and recursive vm invocations

[Andy Wingo]

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/