> 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 ERR
> 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
I don’t think we are going to agree on much here, but some new points of
agreement pop up occassionally. Continuing this …
>> What is lousy and expectation-violating about a keyword argument
>> doing what it name describes?
>well, this should have been discussed at the R6RS committee, but...
Thi
> What is lousy and expectation-violating about a keyword argument
> doing what it name describes?
well, this should have been discussed at the R6RS committee, but...
an API is facilitating efficient reading comprehension when the "verbs" are
closer to the beginning of the "sentence" (the sexp)
>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 ano
apparently this has been fixed between 3.0.9 and HEAD. i've wasted my time
chasing a ghost...
can we please have a new release? :)
as a sidenote, i also had some broken expectations in my test.scm.
it's a tangential, but namely, when #:unwind #t then the handler in a w-e-h
returns from the w-e
> >do i get this right? (with-exception-handler ... #:unwind? #f) installs a so
> >called pre-unwind-handler, which takes priority over a false-if-exception,
> >even if deeper in the stack, because f-i-e installs a post-unwind-handler?
>
> It’s not post-unwind? If anything, I would call it pre-u
i was once again hindered by this, so i digged deeper.
please find a test.scm attached.
looks like (R6RS) WITH-EXCEPTION-HANDLER has such a surprising semantics that i
didn't even consider that to be the case. some hours later i found this:
https://practical-scheme.net/gauche/man/gauche-refe/Ex
>do i get this right? (with-exception-handler ... #:unwind? #f) installs a so
>called pre-unwind-handler, which takes priority over a false-if-exception,
>even if deeper in the stack, because f-i-e installs a post-unwind-handler?
It’s not post-unwind? If anything, I would call it pre-unwind. If
> I think I've had similar problems in the past, I did fine this IRC
> conversation:
>
> https://logs.guix.gnu.org/guile/2021-01-19.log#204926
the very same bug was already discussed in 2021?!
from the log:
> you're using a pre-unwind handler here
> whereas false-if-exception only sets a post-u
Attila Lendvai writes:
> dear fellow Guilers,
>
> context:
>
>
> i'm working on shepherd (with several non-trivial local commits). its
> test suite runs clean from a shell, but fails when i try to
> `./pre-inst-env guix build -K shepherd@0.10.99-git`.
>
>
> the sympthom:
> -
[Adding Andy Wingo because of the stack shenanigans]
>Subject: exception from inside false-if-exception?
Duplicate of #46009 - (backtrace) crash, string->number: Wrong type argument in
position 1 (expecting string): #f - GNU bug report logs
>the expression pointed to by debug.scm,72:40 is this:
12 matches
Mail list logo
