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: Mon, 17 Jun 2024 22:50:54 +0200 Message-ID: <20240617225055.ckqu2C0045M5ED401kquFP__25361.5466224559$1718657619$gmane$org@laurent.telenet-ops.be> References: <87le4wz1s9.fsf@cbaines.net> <20240506205840.Kuyd2C00E17cfcj01uygoD@xavier.telenet-ops.be> Reply-To: Maxime Devos Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_85EC6980-4DBD-44BD-87F5-C76A9166FE40_" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1626"; 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 Mon Jun 17 22:53:30 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 1sJJM1-0000EE-K6 for guile-bugs@m.gmane-mx.org; Mon, 17 Jun 2024 22:53:29 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sJJLa-0004BY-79; Mon, 17 Jun 2024 16:53:02 -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 1sJJLY-0004B9-7m for bug-guile@gnu.org; Mon, 17 Jun 2024 16:53:00 -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 1sJJLX-00085w-VR for bug-guile@gnu.org; Mon, 17 Jun 2024 16:52:59 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sJJLa-00048U-2g for bug-guile@gnu.org; Mon, 17 Jun 2024 16:53:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Maxime Devos Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Mon, 17 Jun 2024 20:53:02 +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.171865755215828 (code B ref 46009); Mon, 17 Jun 2024 20:53:02 +0000 Original-Received: (at 46009) by debbugs.gnu.org; 17 Jun 2024 20:52:32 +0000 Original-Received: from localhost ([127.0.0.1]:37399 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sJJL5-00047C-Na for submit@debbugs.gnu.org; Mon, 17 Jun 2024 16:52:32 -0400 Original-Received: from cantor.telenet-ops.be ([195.130.132.48]:39060) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sJJL3-00046x-PK for 46009@debbugs.gnu.org; Mon, 17 Jun 2024 16:52:30 -0400 Original-Received: from laurent.telenet-ops.be (laurent.telenet-ops.be [IPv6:2a02:1800:110:4::f00:19]) by cantor.telenet-ops.be (Postfix) with ESMTPS id 4W32B406Z5z4wxsW for <46009@debbugs.gnu.org>; Mon, 17 Jun 2024 22:51:56 +0200 (CEST) Original-Received: from [IPv6:2a02:1811:8c0e:ef00:449a:e937:69a4:6072] ([IPv6:2a02:1811:8c0e:ef00:449a:e937:69a4:6072]) by laurent.telenet-ops.be with bizsmtp id ckqu2C0045M5ED401kquFP; Mon, 17 Jun 2024 22:50:55 +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=1718657455; bh=8oFiaFcddvvSAy488k68PI5J+ORB8J8ZWMtzoVFEDfY=; h=To:Cc:From:Subject:Date:In-Reply-To:References; b=dTzIwqPuVkYWtOI47PsjEeMnT0FCSvmt4ABxvrF8ao8znY9g4Bd58PYgjfAWgmqpp kC5Ub/KjlbQZ3+LqpYTPPOc0Fmj6HtnCiK1u9EsZMDIDfgyajUqOFehQHqhTowKpLN /POP7l7LlTWOJckemAp2XVSr3OUYadS11J3cWlaOoq/0ZKRvzLGef0amtVYCCGYVRn PD0HO9v44ttoa/WHJ8CvbgFaih9gEQupGWOeXqDPhugkWIszYTYQKwSUGRm1ywXrLc /By+fcntJ0kwxpe2udY+Oaui7ZnZE+JkGWBJduPoJ5xVTw/CQh7PIVK1Rc97ystx2w xXakVcppPKoBw== 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:10859 Archived-At: --_85EC6980-4DBD-44BD-87F5-C76A9166FE40_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" >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 (usual= ly a page down) fundamentally changes the behavior of w-e-h. yet another su= rprise 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=E2=80=99s too late to return return from the raise= (unless the implementation is doing delimited continuations shenanigans, w= hich maybe you had in mind?), which explains the behaviour for #:unwind #tr= ue. If you are _not_ unwinding, then the handler can=E2=80=99t be run less deep= in the call stack (i.e. =E2=80=9Cfrom the w-e-h block=E2=80=9D), because t= o get less deep in the call stack, you need to unwind. So, there is a direct relation between unwinding/no unwinding, and returnin= g from =E2=80=9Cthe w-e-h block=E2=80=9D/=E2=80=9Draise(-continuable)=E2=80= =9D. If you don=E2=80=99t want Guile to unwind, then maybe don=E2=80=99t ask it = to unwind. (Previous sentence N/A if you had above-mentioned delimited cont= inuation 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= =E2=80=98unwind=E2=80=99 refers to the implementation instead of the seman= tics(*). That would reduce the need of roughly knowing how it is implemente= d (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 = =E2=80=98guard/with-exception-handler=E2=80=99 instead of the =E2=80=98rais= e=E2=80=99(*), and if raise-continuable is used and the handler returns som= ething, then _re_winding happens via delimited continuations.). (*)I think this is how it=E2=80=99s supposed to work (?) (including in R6RS= ), but Guile doesn=E2=80=99t do this. (Except for interactions with dynamic= -wind, which might now be incorrect in the case of raise-continuable, but r= eally you shouldn=E2=80=99t be using dynamic-wind in the first place.) >anyway, i've attached a patch that clarifies what's happening for anyone w= ho 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=E2=80=99s happening, but you don= =E2=80=99t seem to be referring to false-if-exception stuff, and you didn= =E2=80=99t mention continuation barriers earlier. >if someone wants to investigate further, then i'm also attaching a new ver= sion 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 com= mit). It would be helpful to include in test.scm what the expected output would b= e and what unexpected output is encountered. Best regards, Maxime Devos. --_85EC6980-4DBD-44BD-87F5-C76A9166FE40_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

>it's a tange= ntial, but namely, when #:unwind #t then the handler in a w-e-h returns fro= m the w-e-h block, but with #:unwind #f it tries to return to the RAISE tha= t raised the condition. i.e. a lousy little keyword arg (usually a page dow= n) fundamentally changes the behavior of w-e-h. yet another surprise that v= iolated my expectations regarding APIs.

 

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

 

<= span lang=3Den-BE>If you have unwinded, it=E2=80=99s too late to return ret= urn from the raise (unless the implementation is doing delimited continuati= ons shenanigans, which maybe you had in mind?), which explains the behaviou= r for #:unwind #true.

 

If you are _not_ unwinding, then the handler can=E2=80=99t be run = less deep in the call stack (i.e. =E2=80=9Cfrom the w-e-h block=E2=80=9D), = because to get less deep in the call stack, you need to unwind.<= /span>

 <= /p>

So, there is a direct relation b= etween unwinding/no unwinding, and returning from =E2=80=9Cthe w-e-h block= =E2=80=9D/=E2=80=9Draise(-continuable)=E2=80=9D.

 

If you don=E2=80=99t want Guile to unwind, then= maybe don=E2=80=99t ask it to unwind. (Previous sentence N/A if you had ab= ove-mentioned delimited continuation shenanigans in mind.)

 

That said, I would prefer it to be na= med something like [#:handler-context 'raise]/[#:handler-context 'guard] in= stead of #:unwind? #false/#true, since =E2=80=98unwind=E2=80=99 refers to t= he implementation instead of the semantics(*). That would reduce the need o= f roughly knowing how it is implemented (I have a rough idea for an alterna= te implementation where some unwinding always happens, and the handler is r= un in the dynamic environment of the =E2=80=98guard/with-exception-handler= =E2=80=99 instead of the =E2=80=98raise=E2=80=99(*), and if raise-continuab= le is used and the handler returns something, then _re_winding happe= ns via delimited continuations.).

 

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

=  

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

 

Wait where did this happen? You say what=E2=80=99s happening, but you= don=E2=80=99t seem to be referring to false-if-exception stuff, and you di= dn=E2=80=99t 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 u= nexpected 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 exp= ected output would be and what unexpected output is encountered.=

 =

Best regards,=

Maxime Devos.=

 

= --_85EC6980-4DBD-44BD-87F5-C76A9166FE40_--