Re: catch, throw, prompt, control, fluids, garbage collection

[Neil Jerram <neil@ossau.uklinux.net>]

Andy Wingo <wingo@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