guile-devel
[Top][All Lists]
Advanced

[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 21:46:46 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Hey!

Andy Wingo <address@hidden> writes:

> 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.

OK, got it.

>>> 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.

Yes, right.

Thanks for taking the time to explain!

Ludo’.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]