RE: exception from inside false-if-exception?

[Attila Lendvai]

> Also, I don’t see a fundamental change in meaning


just look at my test.scm:

without the explicit (let/ec return ...) wrapper, and the explicit use of 
(return ...) in the handlers, the two invocations lead to different flow of 
control.

it's icing on the cake that if the underlying ERROR were in fact a 
RAISE-CONTINUABLE, then it wouldn't even lead to a &NON-CONTINUABLE error in 
the #:unwind? #f case, only to a different return value (different flow of 
control).

in my vocabulary, a different flow of control when using a control-flow 
primitive is a fundamental change to its meaning. but your miliage may wary of 
course.


> If we are talking about reading comprehension, I would like to point
> out that (Guile) Scheme is case-sensitive.


for effective communication we need a syntax to designate when a word is to be 
interpreted in the scheme/lisp domain (as opposed to plain english). using 
all-caps in english prose is a somewhat well-spread syntax for that, even in 
non-CL lisp contexts in my experience.


> Someone coming from case-insensitive languages and someone
> unfamiliar with the upcasing practice might get confused for a
> moment.


for a moment. and that is key.


> >that would be better, but i still wouldn't like the fact that it's
> >focusing on the dynamic context of the handler, instead of the
> >different flow of control.
> 
> I don’t get the distinction. These are two sides of the same coin?


not really, because there are two, orthogonal dimensions here:

1) whether to unwind the stack,

2) where to return the control flow when the handler returns.

(even if one combination is impossible)


> >for reference, in CL they are called HANDLER-CASE and HANDLER-BIND, with 
> >completely different syntaxes.
>
> Can’t honestly say I like those names (those suffixes -CASE / -BIND
> don’t really provide information, you have to go into the spec of
> HANDLER-CASE / HANDLER-BIND itself to get the differences).


my point is not whether it's deducible, or whether the names are good. my point 
is that one API is misleading (i.e. wastes human time), while the other forces 
the reader to, at worst, look up the documentation. but certainly not conflate 
the two, thinking that they are doing the same thing -- plus some 
implementation detail regarding unwinding that he can postpone learning about.

here's a caricature of this situation:

imagine a hypothetical (raise [a potentially larger sexp] #:enabled? #t/#f) 
control flow primitive that simply returns when #:enabled? is #f.

one can argue that "well, it's disabled, dummy!" (turing tarpit), or try to 
walk in the shoes of the reader or a newcomer.

yes, you're right when you say something is possible, or deducible. but no, 
with all due respect, you're wrong when you imply that it doesn't make a 
difference (in human-brain efficiency).


> Going by this and some earlier text, it seems we are in agreement
> that with-exception-handler should be split (albeit for different
> reasons).


yes.


> Maybe you can install a breakpoint on
> scm_c_with_continuation_barrier or something


it assumes that it's already known that the curlpit is w-c-b, but that was 
already well into the debugging effort. see my attached patch that intends to 
greatly shorten the debugging time for anyone else walking down this path after 
me.

and it's been decades i've done any serious C coding, and i'm not looking 
forward to learning the ins and outs of gdb when i'm debugging an issue in 
scheme.


> I don’t think Shepherd has much use of with-continuation-barrier.


IIUC, any time the posix thread enters C code is an implicit continuation 
barrier. if a fiber in shepherd uses any primitive in guile that is implemented 
in C, then it's a continuation barrier (and breaks when an attempt is made to 
suspend that fiber).

changing shepherd not to unconditionally unwind (so that meaningful backtraces 
can be logged) can lead to subtle issues due to now having some extra C frames 
on the stack that were previously unwound prior to handling the error.

i even suspect that a continuation barrier may somehow hide, or neutralize my 
w-e-h higher up on the stack, and the exception from DISPLAY-BACKTRACE ends up 
at the fibers scheduler instead of my w-e-h due to the above.

but with that i'm again at the frontier of my understanding. to say anything 
more useful i'll need to test my shepherd branch using the latest guile.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Your head is for having ideas not for holding them.”
        — David Allen (1945–), http://youtu.be/D-3nTl8M44o?t=6m12s