Andy Wingo <wi...@pobox.com> 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
