[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: catch, throw, prompt, control, fluids, garbage collection
From: |
Neil Jerram |
Subject: |
Re: catch, throw, prompt, control, fluids, garbage collection |
Date: |
Sun, 28 Feb 2010 22:16:24 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
Andy Wingo <address@hidden> writes:
>>> Efficient with-fluids: check! So on to figuring out the prompt and
>>> abort implementations...
>>
>> Prompt and abort: check! Now to finally implement catch, throw, and
>> all that in terms of delimited continuations... (Do I foresee a future
>> reply from myself?)
>
> Catch and throw in terms of prompt and abort: check! And passing the
> test suites, of course. Give master a pull!
Sorry for breaking the reply pattern... :-)
This all sounds like great stuff to me. I haven't understood every
detail, but it all feels very right.
One particular application that I don't think you've mentioned: it was
recently suggested to me that when a Guile program is running under a
debugger, and hits some kind of error, the debugger could offer a menu
of places in the program to jump back to. I think that would align
exactly with the set of prompt tags.
Two specific questions:
1. Right at the start of the yak, you introduced the need for the
"running" flag to be a fluid, because of the possibility of multiple
threads simultaneously using the same set of handlers. I haven't
checked how dynwinds may have changed in 1.9, but in 1.8 I'm fairly sure
that your suggestion is impossible, because each new thread would be
created with a clean dynamic context (including dynwinds), and not
inherit the context of its creator thread. And, it feels to me like
this is quite natural, not just a limitation of the 1.8 implementation.
So, are you sure that elements of the wind list can be shared across
thread, and hence that "running" really needs to be a fluid?
2. Does SRFI-34 (and the R6RS equivalent) fit into your plan at all? I
appreciated the discussion about only being able to implement catch and
throw using call/cc, if the application doesn't also use call/cc -
because I think the problems with implementing SRFI-34 in terms of
catch/throw, or vice versa, are very similar.
Neil
- catch, throw, prompt, control, fluids, garbage collection, Andy Wingo, 2010/02/14
- Fluids, Ludovic Courtès, 2010/02/14
- Plan for the next release, Ludovic Courtès, 2010/02/14
- Re: catch, throw, prompt, control, fluids, garbage collection, Andy Wingo, 2010/02/15
- Re: catch, throw, prompt, control, fluids, garbage collection, Andy Wingo, 2010/02/18
- Re: catch, throw, prompt, control, fluids, garbage collection, Andy Wingo, 2010/02/24
- Re: catch, throw, prompt, control, fluids, garbage collection, Andy Wingo, 2010/02/26
- Re: catch, throw, prompt, control, fluids, garbage collection,
Neil Jerram <=