GNU bug report logs -
#46009
(backtrace) crash, string->number: Wrong type argument in position 1 (expecting string): #f
Previous Next
Full log
Message #20 received at 46009 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> 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), and nothing later in the sentence adjusts the meaning of the verb fundamentally. and especially not a keyword arg at the end of the sentence that is not even mandatory, and defaults to one of the rather different possibilities.
in this case, it's a primitive to catch and handle exceptions. and it's possible to implement both #:unwind? #t and #f so that when the handler returns then the control flow continues at the guard, and never at the RAISE. it's just that one version would call the handler before unwinding.
> 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.
i didn't have anything on my mind, and that's the point. i'm simply new to scheme. now that i've learned it, i'll learn to live with it.
put another way, my learning curve would have been much steeper if the two, rather different behaviors were defined under two distinct names (or at least mentioned with bold in the documentation).
> That said, I would prefer it to be named something like [#:handler-context 'raise]/[#:handler-context 'guard]
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.
for reference, in CL they are called HANDLER-CASE and HANDLER-BIND, with completely different syntaxes.
> 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.
this has caused me layers of confusion, which is sadly reflected in my mails.
guile prints a backtrace without any prelude, which made me think that it's my own code that is printing this backtrace and exception in the logs (remember, i'm working on nested error handling and logging in shepherd). then 3.0.9 does something funny with the control flow, which further made me believe that i'm logging an exception coming from inside FALSE-IF-EXCEPTION and it's somehow flying past my error handler, and reaching fibers.
and i think i'm still confused about a possible continuation barrier being injected somewhere that probably/maybe causes the exception from inside FALSE-IF-EXCEPTION somehow ending up at fibers instead of my error handler. but at this point i'm reaching the frontier of my understanding of scheme, delimited continuations, fibers, etc.
so, one step at a time. once this test.scm is clear, and i'm able to run shepherd on guile-next, then i'll get back to investigate my original issue in its original context.
> It would be helpful to include in test.scm what the expected output
> would be and what unexpected output is encountered.
i've attached a new test.scm that contains the output of two runs, one with 3.0.9, and one with guile HEAD (more specifically, guile-next in guix, which is almost guile HEAD).
HTH,
--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Life becomes easier when you learn to accept the apology you never got.”
— Robert Brault
[test.scm (text/x-scheme, attachment)]
This bug report was last modified 1 year and 82 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.