>it's a tangential, but namely, when #:unwind #t then the handler in a w-e-h 
>returns from the w-e-h block, but with #:unwind #f it tries to return to the 
>RAISE that raised the condition. i.e. a lousy little keyword arg (usually a 
>page down) fundamentally changes the behavior of w-e-h. yet another surprise 
>that violated my expectations regarding APIs.

What is lousy and expectation-violating about a keyword argument doing what it 
name describes?

If you have unwinded, it’s too late to return return from the raise (unless the 
implementation is doing delimited continuations shenanigans, which maybe you 
had in mind?), which explains the behaviour for #:unwind #true.

If you are _not_ unwinding, then the handler can’t be run less deep in the call 
stack (i.e. “from the w-e-h block”), because to get less deep in the call 
stack, you need to unwind.

So, there is a direct relation between unwinding/no unwinding, and returning 
from “the w-e-h block”/”raise(-continuable)”.

If you don’t want Guile to unwind, then maybe don’t ask it to unwind. (Previous 
sentence N/A if you had above-mentioned delimited continuation shenanigans in 
mind.)

That said, I would prefer it to be named something like [#:handler-context 
'raise]/[#:handler-context 'guard] instead of #:unwind? #false/#true, since 
‘unwind’ refers to the implementation instead of the semantics(*). That would 
reduce the need of roughly knowing how it is implemented (I have a rough idea 
for an alternate implementation where some unwinding always happens, and the 
handler is run in the dynamic environment of the ‘guard/with-exception-handler’ 
instead of the ‘raise’(*), and if raise-continuable is used and the handler 
returns something, then _re_winding happens via delimited continuations.).

(*)I think this is how it’s supposed to work (?) (including in R6RS), but Guile 
doesn’t do this. (Except for interactions with dynamic-wind, which might now be 
incorrect in the case of raise-continuable, but really you shouldn’t be using 
dynamic-wind in the first place.)

>anyway, i've attached a patch that clarifies what's happening for anyone who 
>stumbles upon this; i.e. be clearer that (?) a backtrace is printed due to 
>reaching a continuation barrier.

Wait where did this happen? You say what’s happening, but you don’t seem to be 
referring to false-if-exception stuff, and you didn’t mention continuation 
barriers earlier.

>if someone wants to investigate further, then i'm also attaching a new version 
>of my test.scm that behaves in an unexpected way on 3.0.9, but not on HEAD 
>(more specifically on guile-next in guix, which is a rather recent commit).

It would be helpful to include in test.scm what the expected output would be 
and what unexpected output is encountered.

Best regards,
Maxime Devos.

  • bug#46009: exce... Maxime Devos
    • bug#46009:... Attila Lendvai
      • bug#46... Attila Lendvai
        • bu... Bug reports for GUILE, GNU's Ubiquitous Extension Language
          • ... Attila Lendvai
            • ... Bug reports for GUILE, GNU's Ubiquitous Extension Language
              • ... Attila Lendvai
                • ... Bug reports for GUILE, GNU's Ubiquitous Extension Language

Reply via email to