RE: exception from inside false-if-exception?

[Attila Lendvai <attila@lendvai.name>]

> 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