Re: scm_c_catch question

[Neil Jerram]

On 2014-08-18 03:14, Ian Grant wrote:
> Hi Neil,
>
> Sorry, I am replying to my message because I'm not on guile-devel, it
> seems. I'll join later.
>
> Thanks for clarifying that. The misleading statement in the manual is
> just above the paragraph you quote: on
> https://www.gnu.org/software/guile/manual/html_node/Catch.html#Catch
> [2] it says
>
>     Handler is invoked outside the scope of its own catch. If
> handler
>     again throws to the same key, a new handler from further up the
>     call chain is invoked.
>
> It doesn't mention pre_unwind_handler, which implies that the
> statement does _not_ apply to pre_unwind_handler.

Yes, I believe it is correct that those statements do not apply to the 
pre-unwind handler.

> So this should be
> amended.
>
> But it would be more useful if there were a way to allow a throw to be
> aborted as I was expecting. How hard would that be to implement? If
> you think the semantics are in fact different, it could be given a new
> name, scm_c_catch_and_rethrow or something. What I want is something
> like BSD signals semantics, where the handler is not reset when the
> signal occurs.
>
> You ask "In your code, the pre-unwind handler calls failwith() and
> doesn't expect it to return - so where does it jump to?"
>
> I thought I had explained that, sorry. The call to failwith() does a C
> longjmp back into the CAML bytecode interpreter (i.e. back down below
> the call stack into caml_main). This is not a non-local exit, as far
> as Guile is concerned, because it is just a 'naked' C longjmp. So in
> that sense, the second time Guile throws an exception it is being
> thrown from within pre_unwind_handler.

OK, I think I see now.  From Guile's point of view, the dynamic context 
of the 'catch' remains in effect - as you want - but with a flag to say 
that the pre-unwind handler is already running (actually implemented by 
the %running-exception-handlers fluid in boot-9.scm).  That explains why 
the _next_ exception causes the catch's main handler to be called, 
instead of the pre-unwind handler again.

> Is there a way to implement what I want with fluids?

I don't think so, no.  Basically what you need is to make some call, 
from the pre-unwind handler code, just before calling failwith(), that 
says "this pre-unwind handler should now be reactivated" and is 
implemented by removing itself from %running-exception-handlers.  But 
%running-exception-handlers is hidden inside a lexical environment, so 
that isn't possible without hacking the boot-9 code.

You could try hacking the boot-9 code, though, to see if that idea 
works, and then propose a patch.

Regards,
     Neil