RE: Dynamic loading progress

[Stephen J. Turnbull]

Herring, Davis writes:

 > > We still have to catch the longjmp.  The setjmp *is* the barrier
 > > as far as Fsignal and Fthrow are concerned.  See
 > > unwind_to_catch().
 > 
 > The "struct handler" is the barrier: it's a detail of the current
 > implementation that it contains a jmp_buf (that is always used).

 > where (according to my straw-man code) catch->hook was populated by
 > the call to env->error_handle.  It's still a non-local transfer, as
 > is necessary for the existing calls to unwind_to_catch to possibly
 > work.

So what's the advantage over unwind_to_catch as implemented?  You
still need to put the barrier in place, only now you're using mixed
idioms (Lisp for the pitcher, C++ for the catcher).  That kind of
thing always gives me hives.

 > > Which [...] is what I think is a horrible idea, akin to using
 > > `ignore-errors' in basic Lisp functions like `car'.
 > 
 > But it's not ignore-errors: in my example,

A-ah, that's *your* example.  I was referring to what I believe Daniel
and Philipp want, which was the idea you pretty much dismissed as
"[too] inflexible": a handler hidden behind the API.