From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Maxime Devos via "Bug reports for GUILE, GNU's Ubiquitous Extension Language" Newsgroups: gmane.lisp.guile.bugs Subject: bug#46009: exception from inside false-if-exception? Date: Wed, 19 Jun 2024 18:51:00 +0200 Message-ID: <20240619185059.dUqy2C00M0K6dk406UqzfD__3323.02028998441$1718816033$gmane$org@michel.telenet-ops.be> References: <87le4wz1s9.fsf@cbaines.net> <20240506205840.Kuyd2C00E17cfcj01uygoD@xavier.telenet-ops.be> <20240617225055.ckqu2C0045M5ED401kquFP@laurent.telenet-ops.be> Reply-To: Maxime Devos Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_7D710A1D-7A49-4C9A-98C3-BF6C499ACEB4_" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24848"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "46009@debbugs.gnu.org" <46009@debbugs.gnu.org>, Christopher Baines , "guile-devel@gnu.org" To: Attila Lendvai Original-X-From: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Wed Jun 19 18:53:45 2024 Return-path: Envelope-to: guile-bugs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sJyZ7-0006Go-D0 for guile-bugs@m.gmane-mx.org; Wed, 19 Jun 2024 18:53:45 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sJyYO-00067t-Ut; Wed, 19 Jun 2024 12:53:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sJyYN-00067Q-2S for bug-guile@gnu.org; Wed, 19 Jun 2024 12:52:59 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sJyYM-0005cM-PT for bug-guile@gnu.org; Wed, 19 Jun 2024 12:52:58 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sJyYP-0007jz-So for bug-guile@gnu.org; Wed, 19 Jun 2024 12:53:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Maxime Devos Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Wed, 19 Jun 2024 16:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46009 X-GNU-PR-Package: guile Original-Received: via spool by 46009-submit@debbugs.gnu.org id=B46009.171881593029679 (code B ref 46009); Wed, 19 Jun 2024 16:53:01 +0000 Original-Received: (at 46009) by debbugs.gnu.org; 19 Jun 2024 16:52:10 +0000 Original-Received: from localhost ([127.0.0.1]:51191 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sJyXY-0007ic-VF for submit@debbugs.gnu.org; Wed, 19 Jun 2024 12:52:10 -0400 Original-Received: from weierstrass.telenet-ops.be ([195.130.137.81]:36720) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sJyXW-0007iS-Ek for 46009@debbugs.gnu.org; Wed, 19 Jun 2024 12:52:07 -0400 Original-Received: from michel.telenet-ops.be (michel.telenet-ops.be [IPv6:2a02:1800:110:4::f00:18]) by weierstrass.telenet-ops.be (Postfix) with ESMTPS id 4W48mL00yHz4x59d for <46009@debbugs.gnu.org>; Wed, 19 Jun 2024 18:52:02 +0200 (CEST) Original-Received: from [IPv6:2a02:1811:8c0e:ef00:ad11:ee0:137f:2aa4] ([IPv6:2a02:1811:8c0e:ef00:ad11:ee0:137f:2aa4]) by michel.telenet-ops.be with bizsmtp id dUqy2C00M0K6dk406UqzfD; Wed, 19 Jun 2024 18:50:59 +0200 Importance: normal X-Priority: 3 In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=telenet.be; s=r24; t=1718815859; bh=FEVG66ZavquyLf+ZjpAVDji3o97Rt/ZVGmZgHeiB7IA=; h=To:Cc:From:Subject:Date:In-Reply-To:References; b=FdZ9CWXB5dYS/oAYMBH7pfWa/zBLKWKvN9Ni7pxSB4JXeR3+flKy5CvXZI2pEddPT 90lRwy8hnKL2/t/Vs9KUcBaYm5uE/0JwTrIGuIR/qjwbbjrQuXPhbYqu+f603dAE3c Kqzv7sBjIA+Y/xF3EHVKJrf16HihYCJYCIzOeK8LJCmWbKYmAHCIb+mTFZsPxGzv0Y zE3t8Nx4IZKx3or4DDbjsVqQCw/47GqrVyJAD0Blw6uH1L2H1Xwg+smh1ip32dU0Pz X8RBof0ePN0l2xEUjmw70n+d1Ip8h6ha/dNw3CMu7UiE0bJGSqSE6D834M4zeKjxfX GbHPHvguNVj4Q== X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Original-Sender: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.bugs:10862 Archived-At: --_7D710A1D-7A49-4C9A-98C3-BF6C499ACEB4_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" I don=E2=80=99t think we are going to agree on much here, but some new poin= ts of agreement pop up occassionally. Continuing this =E2=80=A6 >> 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... This is not something to be discussed at the R6RS committee, because #:unwi= nd? is a Guile extension, not part of R6RS. Unless the idea is to (in an al= ternate past) have introduced keyword arguments to R6RS and this is about k= eyword argument stuff. >an API is facilitating efficient reading comprehension when the "verbs" ar= e closer to the beginning of the "sentence" (the sexp), and nothing later i= n the sentence adjusts the meaning of the verb fundamentally. Do you have evidence for this? I mean, beyond your own experience, anecdota= l evidence doesn=E2=80=99t generalise well. (Not that I don=E2=80=99t use a= necdotal evidence or the like myself, but it would be better if at least on= e of us has something better.) Also, I don=E2=80=99t see a fundamental change in meaning, except in the se= nse that anything could be considered fundamental, just like every two topi= cs are related however distantly, etc.. #:unwind? #true/#false is too smal= l a change for me to consider =E2=80=98fundamental=E2=80=99 =E2=80=93 both = #true?/#false result in exception handling, just slightly different excepti= on handling. Neither do I really have an argument to consider it un-fundame= ntal, size isn=E2=80=99t everything. In this context, it=E2=80=99s too mean= ingless a label to base things on or me. Also, I disagree =E2=80=93 this is not a garden path sentence situation (wh= ere, and OV (object-verb) languages exist. If you want to understand a sent= ence just read the entire sentence? Now, I did some quick searches for differences in reading comprehension for= OV/VO languages, and unfortunately found nothing relevant (neither positiv= e nor negative nor neutral). If we are talking about reading comprehension, I would like to point out th= at (Guile) Scheme is case-sensitive. I=E2=80=99d consider it beneficial to = reading comprehension if the procedure names that are written in documentat= ion correspond to what=E2=80=99s recognised by the implementation. Someone = coming from case-insensitive languages and someone unfamiliar with the upca= sing practice might get confused for a moment. > and especially not a keyword arg at the end of the sentence that is not e= ven mandatory, and defaults to one of the rather different possibilities. Also, I would rather not have the keyword argument at the front. Usually ke= yword arguments aren=E2=80=99t verbs and better fit for the end of the proc= edure call, and even if they were sometimes better suited for the beginning= , you now have a situation where sometimes keyword arguments are at the fro= nt and other times are at the end, which creates ambiguity when interpretin= g the arguments. Another interpretation of this would be to replace the keyword argument by = an optional argument, but optional arguments are at the end, so same thing. A potential way to avoid this is to split things off into a new procedure, = say with-exception-handler/unwinding or with-exception-handler/winding (wel= l not these precise name because of issues mentioned earlier). While both p= rovide a similar function (to the point that often you can swap between the= two without trouble), if you were to precisely document them or implement = them, the documentation and implementation would be rather different, so I = think this would be better than an argument (whether (non-)keyword or optio= nal or required) (it=E2=80=99s not like the unwinding-ness varies dynamical= ly in practice, so not really a point in sharing a procedure name). (I don=E2=80=99t think this really is an improvement in readability though,= just a neatness thing.) >in this case, it's a primitive to catch and handle exceptions. and it's po= ssible to implement both #:unwind? #t and #f so that when the handler retur= ns 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. AFAICT this paragraph as-written is technically true, but rather misleading= =E2=80=93 there is also raise-continuable, where the control flow needs to= continue at raise-continuable. >> If you have unwinded, it=E2=80=99s too late to return return from the ra= ise >> (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. [no replies to this part, I just don=E2=80=99t want to trim context / disru= pt flow here] >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). At first, I was going to write that you probably meant to write the opposit= e that if the different behaviour were more clearly different (e.g. with di= stinct names), then the learning would be _less_ steep, but now I read (Wik= ipedia article on learning curves): >The common expression "a steep learning curve" is a misnomer suggesting th= at an > activity is difficult to learn and that expending much effort does not in= crease > proficiency by much, although a learning curve with a steep start actuall= y represents > rapid progress.[2][3] (reading comprehension failure). >> That said, I would prefer it to be named something like [#:handler-conte= xt 'raise]/[#:handler-context 'guard] >that would be better, but i still wouldn't like the fact that it's focusin= g on the dynamic context of the handler, instead of the different flow of c= ontrol. I don=E2=80=99t get the distinction. These are two sides of the same coin? = Almost equivalent, though I suppose that flow of control is a bit more gene= ral since if you only have info on the dynamic context then multiple flow o= f controls remain possible (but I don=E2=80=99t know any important change o= f flow that=E2=80=99s still correct exception handling). Also, for a hypothetical #: [something flowy], I don=E2=80=99t like the fac= t that it=E2=80=99s focusing on the flow of control instead of the dynamic = context of the handler. Whenever I do #:unwind? #false/#:true (#:handler-context =E2=80=98raise=E2= =80=99), it=E2=80=99s to get the dynamic environment/context (I forgot stan= dard terminology) right (think call stack and parameter bindings (either at= raise or guard, depending on what you are implementing)). I don=E2=80=99t = really care about Guile does the control flow is implemented, as long as th= e dynamic environment is correct and raise-continuable functions (though TB= H I almost never use raise-continuable, and when I do, I always think somet= hing along the lines of =E2=80=9Cneat that this is possible, but there are = other methods that are simpler both to implement (whether caller/callee) an= d to understand=E2=80=9D). >for reference, in CL they are called HANDLER-CASE and HANDLER-BIND, with c= ompletely different syntaxes. Can=E2=80=99t honestly say I like those names (those suffixes -CASE / -BIND= don=E2=80=99t really provide information, you have to go into the spec of = HANDLER-CASE / HANDLER-BIND itself to get the differences). Going by this and some earlier text, it seems we are in agreement that with= -exception-handler should be split (albeit for different reasons). >> Wait where did this happen? You say what=E2=80=99s happening, but you do= n=E2=80=99t >> seem to be referring to false-if-exception stuff, and you didn=E2=80=99t >> mention continuation barriers earlier. >this has caused me layers of confusion, which is sadly reflected in my mai= ls. >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 (re= member, 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 be= lieve that i'm logging an exception coming from inside FALSE-IF-EXCEPTION a= nd 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 FA= LSE-IF-EXCEPTION somehow ending up at fibers instead of my error handler. b= ut at this point i'm reaching the frontier of my understanding of scheme, d= elimited continuations, fibers, etc. > >so, one step at a time. once this test.scm is clear, and i'm able to run s= hepherd on guile-next, then i'll get back to investigate my original issue = in its original context. Maybe you can install a breakpoint on scm_c_with_continuation_barrier or so= mething, and see when this happens. Or search for with-continuation-barror = in Scheme code. I don=E2=80=99t think Shepherd has much use of with-continu= ation-barrier. If it does, it=E2=80=99s a rather crude tool and can probabl= y be replaced by something else that doesn=E2=80=99t replace the exception = handler. I don=E2=80=99t know what you are investigating precisely, but maybe it is >https://sources.debian.org/src/guix/1.4.0-6/gnu/build/shepherd.scm/?hl=3D1= 12#L109 If it is this, surely (@ (fibers) sleep) could be adjusted to _not_ suspend= (and instead just, well, sleep) when there is no Fibers task scheduler (si= milar stuff exists for the (Fibers) channels and conditions implementation)= . Best regards, Maxime Devos. --_7D710A1D-7A49-4C9A-98C3-BF6C499ACEB4_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

I don=E2=80=99t think we are going to agree on much here, but= some new points of agreement pop up occassionally. Continuing this =E2=80= =A6

 

>> What is lousy and expectation-violating about a keyword argument=

>> doing what it name describes?

>well, this should have been discussed at the R6RS committe= e, but...

 

This is not something to be discussed at the R6RS committee, because #:unw= ind? is a Guile extension, not part of R6RS. Unless the idea is to (in an a= lternate past) have introduced keyword arguments to R6RS and this is about = keyword argument stuff.

 

>an API is facilitating efficient reading comp= rehension when the "verbs" are closer to the beginning of the &qu= ot;sentence" (the sexp), and nothing later in the sentence adjusts the= meaning of the verb fundamentally.

 

Do you have evidence for this? I mean, beyond yo= ur own experience, anecdotal evidence doesn=E2=80=99t generalise well. (Not= that I don=E2=80=99t use anecdotal evidence or the like myself, but it wou= ld be better if at least one of us has something better.)

 

Also, I don=E2=80=99t see = a fundamental change in meaning, except in the sense that anything could be= considered fundamental, just like every two topics are related however dis= tantly, etc..=C2=A0 #:unwind? #true/#false is too small a change for me to = consider =E2=80=98fundamental=E2=80=99 =E2=80=93 both #true?/#false result = in exception handling, just slightly different exception handling. Neither = do I really have an argument to consider it un-fundamental, size isn=E2=80= =99t everything. In this context, it=E2=80=99s too meaningless a label to b= ase things on or me.

 

Also, I disagree =E2=80=93 this is not a garden path sentence = situation (where, and OV (object-verb) languages exist. If you want to unde= rstand a sentence just read the entire sentence?

 

Now, I did some quick searches for = differences in reading comprehension for OV/VO languages, and unfortunately= found nothing relevant (neither positive nor negative nor neutral).

 

If we are talki= ng about reading comprehension, I would like to point out that (Guile) Sche= me is case-sensitive. I=E2=80=99d consider it beneficial to reading compreh= ension if the procedure names that are written in documentation correspond = to what=E2=80=99s recognised by the implementation. Someone coming from cas= e-insensitive languages and someone unfamiliar with the upcasing practice m= ight get confused for a moment.

 

> 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.

 

Also, I would rather not have the keyword argument at the f= ront. Usually keyword arguments aren=E2=80=99t verbs and better fit for the= end of the procedure call, and even if they were sometimes better suited f= or the beginning, you now have a situation where sometimes keyword argument= s are at the front and other times are at the end, which creates ambiguity = when interpreting the arguments.

 <= /p>

Another interpretation of this would be to replace = the keyword argument by an optional argument, but optional arguments are at= the end, so same thing.

 

A potential way to avoid this is to split things off into a= new procedure, say with-exception-handler/unwinding or with-exception-hand= ler/winding (well not these precise name because of issues mentioned earlie= r). While both provide a similar function (to the point that often you can = swap between the two without trouble), if you were to precisely document th= em or implement them, the documentation and implementation would be rather = different, so I think this would be better than an argument (whether (non-)= keyword or optional or required) (it=E2=80=99s not like the unwinding-ness = varies dynamically in practice, so not really a point in sharing a procedur= e name).

 

= (I don=E2=80=99t think this really is an improvement in readability though,= just a neatness thing.)

 

>in this case, it's a primitive to catch and handle exce= ptions. and it's possible to implement both #:unwind? #t and #f so that whe= n the handler returns then the control flow continues at the guard, and nev= er at the RAISE. it's just that one version would call the handler before u= nwinding.

 

AFAICT this paragraph as-written is technically true, but rather misleadin= g =E2=80=93 there is also raise-continuable, where the control flow needs t= o continue at raise-continuable.

 <= /p>

>> If you have unwinded, it=E2=80=99s too lat= e 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 a= nything 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.

=  

[no replies to this part, I just = don=E2=80=99t want to trim context / disrupt flow here]

 

>put another way, my lear= ning curve would have been much steeper if the two, >rather different be= haviors were defined under two distinct names (or at least >mentioned wi= th bold in the documentation).

 

At first, I was going to write that you probably mean= t to write the opposite that if the different behaviour were more clearly d= ifferent (e.g. with distinct names), then the learning would be _less_ steep, but now I read (Wikipedia article on learning curves):

 

>The common expr= ession "a steep learning curve" is a misnomer suggesting that an<= /p>

> activity is difficult to learn and that expend= ing much effort does not increase

> proficiency = by much, although a learning curve with a steep start actually represents

> rapid progress.[2][3]

<= o:p> 

(reading comprehension failure).

 

>> T= hat 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 lik= e the fact that it's focusing on the dynamic context of the handler, instea= d of the different flow of control.

 

I don=E2=80=99t get the distinction. These are t= wo sides of the same coin? Almost equivalent, though I suppose that flow of= control is a bit more general since if you only have info on the dynamic c= ontext then multiple flow of controls remain possible (but I don=E2=80=99t = know any important change of flow that=E2=80=99s still correct exception ha= ndling).

 

= Also, for a hypothetical #: [something flowy], I don=E2=80=99t like the fac= t that it=E2=80=99s focusing on the flow of control instead of the dynamic = context of the handler.

 

Whenever I do #:unwind? #false/#:true (#:handler-context =E2= =80=98raise=E2=80=99), it=E2=80=99s to get the dynamic environment/context = (I forgot standard terminology) right (think call stack and parameter bindi= ngs (either at raise or guard, depending on what you are implementing)). I = don=E2=80=99t really care about Guile does the control flow is implemented,= as long as the dynamic environment is correct and raise-continuable functi= ons (though TBH I almost never use raise-continuable, and when I do, I alwa= ys think something along the lines of =E2=80=9Cneat that this is possible, = but there are other methods that are simpler both to implement (whether cal= ler/callee) and to understand=E2=80=9D).

 = ;

>for reference, in CL they are called HA= NDLER-CASE and HANDLER-BIND, with completely different syntaxes.

 

Can=E2=80=99t hones= tly say I like those names (those suffixes -CASE / -BIND don=E2=80=99t real= ly provide information, you have to go into the spec of HANDLER-CASE / HAND= LER-BIND itself to get the differences).

 = ;

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

 

>> Wait where did this happen? You say what=E2=80=99s = happening, but you don=E2=80=99t

>> seem to b= e referring to false-if-exception stuff, and you didn=E2=80=99t

>> mention continuation barriers earlier.

 

>this has caused me = layers of confusion, which is sadly reflected in my mails.

 

>guile prints a backtr= ace 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 probabl= y/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 th= e 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 ru= n shepherd on guile-next, then i'll get back to investigate my original iss= ue in its original context.

 

Maybe you can install a breakpoint on scm_c_with_continu= ation_barrier or something, and see when this happens. Or search for with-c= ontinuation-barror in Scheme code. I don=E2=80=99t think Shepherd has much = use of with-continuation-barrier. If it does, it=E2=80=99s a rather crude t= ool and can probably be replaced by something else that doesn=E2=80=99t rep= lace the exception handler.

 

I don=E2=80=99t know what you are investigating precisel= y, but maybe it is

 

>https://sources.debian.org/src/guix/1.4.0-6/gnu/build/shepher= d.scm/?hl=3D112#L109

 

If it is this, surely (@ (fibers) sleep) could be adjusted to = _not_ suspend (and instead just, well, sleep) when there is no Fiber= s task scheduler (similar stuff exists for the (Fibers) channels and condit= ions implementation).

 

Best regards,

Maxime Devos.

<= /body>= --_7D710A1D-7A49-4C9A-98C3-BF6C499ACEB4_--