From unknown Wed Sep 10 09:28:48 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#46009 <46009@debbugs.gnu.org> To: bug#46009 <46009@debbugs.gnu.org> Subject: Status: (backtrace) crash, string->number: Wrong type argument in position 1 (expecting string): #f Reply-To: bug#46009 <46009@debbugs.gnu.org> Date: Wed, 10 Sep 2025 16:28:48 +0000 retitle 46009 (backtrace) crash, string->number: Wrong type argument in pos= ition 1 (expecting string): #f reassign 46009 guile submitter 46009 Christopher Baines severity 46009 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 20 17:46:53 2021 Received: (at submit) by debbugs.gnu.org; 20 Jan 2021 22:46:53 +0000 Received: from localhost ([127.0.0.1]:56413 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l2MFZ-0004J5-D2 for submit@debbugs.gnu.org; Wed, 20 Jan 2021 17:46:53 -0500 Received: from lists.gnu.org ([209.51.188.17]:33918) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l2MFX-0004Ix-Je for submit@debbugs.gnu.org; Wed, 20 Jan 2021 17:46:51 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:56950) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l2MFV-0006F4-GY for bug-guile@gnu.org; Wed, 20 Jan 2021 17:46:51 -0500 Received: from mira.cbaines.net ([212.71.252.8]:37424) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l2MFS-0002Bc-Si for bug-guile@gnu.org; Wed, 20 Jan 2021 17:46:49 -0500 Received: from localhost (92.41.179.184.threembb.co.uk [92.41.179.184]) by mira.cbaines.net (Postfix) with ESMTPSA id 6C2BD27BC15 for ; Wed, 20 Jan 2021 22:46:44 +0000 (GMT) Received: from capella (localhost [127.0.0.1]) by localhost (OpenSMTPD) with ESMTP id 9c32c13b for ; Wed, 20 Jan 2021 22:46:41 +0000 (UTC) User-agent: mu4e 1.4.14; emacs 27.1 From: Christopher Baines To: bug-guile@gnu.org Subject: (backtrace) crash, string->number: Wrong type argument in position 1 (expecting string): #f Date: Wed, 20 Jan 2021 22:46:38 +0000 Message-ID: <878s8nteep.fsf@cbaines.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=212.71.252.8; envelope-from=mail@cbaines.net; helo=mira.cbaines.net X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable It seems that with-exception-handler might be breaking false-if-exception inside terminal-width from (system repl debug). I've come across this when trying to use with-exception-handler to print backtraces for exceptions. =E2=86=92 cat backtrace-crash.scm (peek "COLUMNS" (getenv "COLUMNS")) (with-exception-handler (lambda (exn) (backtrace)) (lambda () (+ 1 a))) =E2=86=92 echo $COLUMNS 84 =E2=86=92 guile --no-auto-compile backtrace-crash.scm ;;; ("COLUMNS" #f) Backtrace: Backtrace: 10 (primitive-load "/home/chris/Projects/Guix/guix-build-c=E2=80= =A6") In ice-9/boot-9.scm: 1736:10 9 (with-exception-handler _ _ #:unwind? _ # _) In ice-9/eval.scm: 159:9 8 (_ _) 223:20 7 (proc #(#(#))) In unknown file: 6 (%resolve-variable (7 . a) #) In ice-9/boot-9.scm: 1669:16 5 (raise-exception _ #:continuable? _) In unknown file: 4 (backtrace #) In system/repl/debug.scm: 148:36 3 (print-frames #(# # = =E2=80=A6) =E2=80=A6) 72:20 2 (_) In ice-9/boot-9.scm: 1731:15 1 (with-exception-handler # =E2=80=A6) In system/repl/debug.scm: 72:40 0 (_) system/repl/debug.scm:72:40: In procedure string->number: Wrong type argume= nt in position 1 (expecting string): #f --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmAIss5fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh aW5lcy5uZXQACgkQXiijOwuE9XdWFhAAqxvsghmt27UbzFig/e23zlobghAcvyp6 k/FFMSyCiEJdecYikqOY9aiiurDVH+YlEZ5gFmaE8HKgJQsL1PeBuocsQysK3Sl3 cPYoBIXa22GDQ/v+Xmu3hzLfqqdl5eMDchL6WK3Of9MGu7kRaCysWxeVIzRjWMdf U55ahTmCObhhaIx5KligyKQ5X0Ws9k/aLO6ULPUEL6aMD/urz/OFUFvGOfuko0N8 6xTB/VGCvRd8tvnDg53NB4qrHC02LvYpJfn05/JgvqwJnsPxNYHNLn+Ifgnwh/bO uYFvph1jTn+qIoShXjHl00ZP1tpf7hnUOMqmzq3yJmOkK/D+ThGJBVijWuQLAwNb bBLmXzfEhV/W/YGHzDJnSwTrLX6Yf8oGacIHrj3MTYcESF8YKxTwhvXQOok/xvZL YabueoBoUZYgWP3Hdcu9sbnfx2ZJX1sCalq6FVPnjlafi82vjGRt4oAuvxhKfOP/ k+MR2Z81j/VLKoWvPGcXX5w61b2G81CZzhQlETIznPa7GgV2VA3WGsrMMYzuMxYM wghZR829c3i8lzW0ir8gndjpWIsuDENs4MgIJKmDzc+9gWnWMFpGwXMsugoRek8z Z3ptwv3ZH8qx/Q1nLUr589q+c4+HXTlbwfuLyYIHYOsPcuU/0GnpRNgNGm6b9Ir3 PPzICdd1Ie8= =Ajxa -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 29 10:13:55 2024 Received: (at 46009) by debbugs.gnu.org; 29 Apr 2024 14:13:55 +0000 Received: from localhost ([127.0.0.1]:57476 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s1RlS-0003GN-3U for submit@debbugs.gnu.org; Mon, 29 Apr 2024 10:13:54 -0400 Received: from albert.telenet-ops.be ([2a02:1800:110:4::f00:1a]:45326) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s1RlN-0003GD-OU for 46009@debbugs.gnu.org; Mon, 29 Apr 2024 10:13:52 -0400 Received: from [IPv6:2a02:1808:5:be3e:851c:ca5:3af4:5afa] ([IPv6:2a02:1808:5:be3e:851c:ca5:3af4:5afa]) by albert.telenet-ops.be with bizsmtp id H2DN2C0020paNS3062DP7G; Mon, 29 Apr 2024 16:13:23 +0200 Message-ID: <20240429161324.H2DN2C0020paNS3062DP7G@albert.telenet-ops.be> MIME-Version: 1.0 To: Attila Lendvai , "guile-devel@gnu.org" , "46009@debbugs.gnu.org" <46009@debbugs.gnu.org>, Christopher Baines , Andy Wingo From: Maxime Devos Subject: RE: exception from inside false-if-exception? Date: Mon, 29 Apr 2024 16:13:22 +0200 Importance: normal X-Priority: 3 In-Reply-To: References: Content-Type: multipart/alternative; boundary="_F09A6C71-D3FB-45E1-B294-DA67E742796C_" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=telenet.be; s=r24; t=1714400004; bh=Oph4hNZizA2lcyOpNAaNkOurGke7Mss7zOTFqR0SYPo=; h=To:From:Subject:Date:In-Reply-To:References; b=PT04aOL3OdQOIAUYOiwKqIhG5dIKtl8pU+EVlzZTROjdt+OCjy35MGjLkNMr2m/hr 5TsD8QWbglN+u+ilvtO+kjaO2FzVpJhOFpGDTpqA+NG032PacIIvsP/ZslnocShKUj 2LBjacTMR8hDAuWy7VaNXy64Y9KAI6WbcPSPCGQoe8yrFerZo50ioDnojHsPE//gYn PTaFHLXg4L2knUcKMeLexks4fCXvcN/Wz55hx353rjV4fzqxGK1uzF8bFbSVjmSlb+ AQU85DyI4Y9XMUe9Wxpi9JhPKf1Io4Yc2+cMBfKVCIW4SYKO+vnkc1nTljGSf63u3p mvomEtxWuCkUg== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46009 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --_F09A6C71-D3FB-45E1-B294-DA67E742796C_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" [Adding Andy Wingo because of the stack shenanigans] >Subject: exception from inside false-if-exception? Duplicate of #46009 - (backtrace) crash, string->number: Wrong type argumen= t in position 1 (expecting string): #f - GNU bug report logs >the expression pointed to by debug.scm,72:40 is this: >(false-if-exception (string->number (getenv "COLUMNS"))) All uses of false-if-exception are wrong =E2=80=93 I haven=E2=80=99t found = a single exception (pun intended) to this rule so far. It shouldn=E2=80=99= t be treating stack overflows, out-of-memory, exceptions from asyncs, EPERM= , etc., as #false. =E2=80=93 false-if-exception delenda est [...] What I think is going on here, is that the exception catching API is a bit = of mess, and to a degree, non-composable, leading to bugs like this. 1. raise/raise-continuable + guard: perfectly composable, no problems. 2. throw + catch: that=E2=80=99s fine too, it=E2=80=99s just a historical G= uile API for (1), albeit slightly less general.=20 3. with-exception-handler =E2=80=93 a procedural variant of the =E2=80=98gu= ard=E2=80=99 macro =E2=80=93 sure ok. Also good for continuable exceptions,= IIUC. 4. Pre-unwind handlers / with-throw-handler. / ???. This is the non-composable stuff (or, difficult to understand and compose, = at least). If you are catching an exception to _handle_ it (say, in this ca= se, with false-if-exception), then any throw handler/pre-unwind handler/wha= tever has no business whatsoever to interfere, and neither to even know som= ething is happening in the first place. Yet, the documentation says it =E2=80=9Cis used to be able to intercept an = exception that is being thrown before the stack is unwound=E2=80=9D =E2=80= =93 which it has no business of doing in the first place (non-composable).= =20 Also the description of pre-unwind handlers / with-throw-handler is rather = low-level (it=E2=80=99s more described in terms of (un)winding rather than = nesting) and it appears to have been grown a bit .. organically, I think it= =E2=80=99s time for it to be replaced by a new design that=E2=80=99s (conce= ptually) closer to raise/guard/... I suspect the problem is that these throw handlers or whatever are messing = things up =E2=80=93 whether because they are hard to use, impossible to use= correctly or because they are incorrectly implemented in Guile and would p= ropose them to be replaced by something else. On this something else: according to the documentation, these throw handler= s can be used for: 1. Clean up some related state 2. Print a backtrace 3. Pass information about the exception to a debugger 1: IIUC, this is what (dynamic-wind #false thunk clean-up-stuff) is for =E2= =80=93 this is not entirely correct w.r.t. userspace threading implementati= on, but can be salvaged with something like >https://github.com/wingo/fibers/blob/7e29729db7c023c346bc88c859405c978131f= 27a/fibers/scheduler.scm#L278 to override =E2=80=98dynamic-wind=E2=80=99 (actually I think the API =E2=80= =98rewinding-for-scheduling?=E2=80=99 would need to be adjusted a bit to al= low for situations like implementing threads inside threads inside threads = inside ..., but it should give the basic idea.) 2. the rationale for this reason, is that when an exception is caught (thin= k =E2=80=98catch=E2=80=99 handler), we are not in the same dynamic environm= ent anymore, so by then it=E2=80=99s too late to generate a backtrace. But = we can have a cake(=3D have a backtrace) and eat it too(=3D post-unwind / i= n the catch handler), by using =E2=80=98with-exception-handler=E2=80=99 wit= h =E2=80=98#:unwind? #false=E2=80=99. That=E2=80=99s not entirely sufficient, because sometimes the exception was= already caught and =E2=80=98wapped=E2=80=99 to give some extra context in = the exception object (but losing some backtrace in the process). OTOH, this= =E2=80=98losing some backtrace=E2=80=99 already happens in the current imp= lementation IIUC, so it wouldn=E2=80=99t be worse than the current implemen= tation in this respect. I think there is a solution that isn=E2=80=99t just= =E2=80=9Calways record the backtrace and put it in the exception=E2=80=9D = (which would be terribly inefficient in situation you mentioned), but I hav= en=E2=80=99t found it yet. Perhaps the (full) current continuation (think call/cc) could be saved? And= then later, when ultimately a backtrace is to be printed, the stack of thi= s continuation can be investigated =E2=80=93 This might seem even more inef= ficient than saving a backtrace, but if you think about it, all those frame= s were already allocated, so you don=E2=80=99t need to allocate new memory = or do much CPU things beyond saving some pointers, you just need to start s= ome new memory branching of an earlier point in the dynamic environment/the= frames when/after rewinding. I=E2=80=99m thinking of spaghetti and cactus= stacks. (The benefit beyond =E2=80=98just include backtrace=E2=80=99 is:= (1) almost 0 time/memory cost when not used (2) if desired, you can print = _more_ information than just the backtrace, e.g. values of certain paramete= rs or whatever.) And after the backtrace or whatever has been printed, there is no reference= to the call/cc thing anymore so it can be garbage collected(*). (*) there is a bit of a caveat here with respect to user-level threading an= d pausing computations, where some stuff low(high?) on the stack might be s= aved for too long, so perhaps it would instead be better to save a delimite= d continuation =E2=80=93 the exception handler that does the backtracing co= uld then set some parameter with a tag that delimits where to stop the deli= mited continuation =E2=80=93 for a comparison: I think there is a procedure= with a name like =E2=80=9Ccall-with-stack=E2=80=9D or something close to t= hat which does something like that. (Also, the section =E2=80=9CExceptions=E2=80=9D isn=E2=80=99t mentioning = =E2=80=98raise + guard=E2=80=99, instead there is a separate R6RS section i= solated from the rest of the manual =E2=80=93 it treats historical Guile id= iosyncrasies as the norm and standard SRFI / RnRS as an aberration. But tha= t=E2=80=99s a different thing.) --_F09A6C71-D3FB-45E1-B294-DA67E742796C_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

[Adding Andy Wingo because of the stack shenanigans]

 

>Subject: exception from inside false-if-e= xception?

 

Dupl= icate of #46009 - (backtrace) crash, string->number: Wrong type argument i= n position 1 (expecting string): #f - GNU bug report logs

 

>the expression pointed to by debug.scm,72:40 is this:

 

>(false-if-exception (stri= ng->number (getenv "COLUMNS")))

 

All uses of false-if-exception are wrong =E2=80=93= I haven=E2=80=99t found a single exception (pun intended) to this rule so = far.=C2=A0 It shouldn=E2=80=99t be treating stack overflows, out-of-memory,= exceptions from asyncs, EPERM, etc., as #false.=C2=A0 =E2=80=93 false-if-e= xception delenda est

 

[...]

&= nbsp;

What I think = is going on here, is that the exception catching API is a bit of mess, and = to a degree, non-composable, leading to bugs like this.

 

  1. raise/rai= se-continuable + guard: perfectly composable, no problems.
  2. throw + catch: that=E2=80=99s fine too, it=E2= =80=99s just a historical Guile API for (1), albeit slightly less general. =
  3. with-exception-handler =E2=80= =93 a procedural variant of the =E2=80=98guard=E2=80=99 macro =E2=80=93 sur= e ok. Also good for continuable exceptions, IIUC.
    4. Pre-unwind handlers / with-throw-handler. / ???.

&n= bsp;

This is= the non-composable stuff (or, difficult to understand and compose, at leas= t). If you are catching an exception to _handle_ it (say, in this ca= se, with false-if-exception), then any throw handler/pre-unwind handler/wha= tever has no business whatsoever to interfere, and neither to even know som= ething is happening in the first place.

 

Yet, the documentation says it =E2=80=9Cis= used to be able to intercept an exception that is being thrown before the = stack is unwound=E2=80=9D =E2=80=93 which it has no business of doing in th= e first place (non-composable).

 

Also the description of pre-unwind handlers / wit= h-throw-handler is rather low-level (it=E2=80=99s more described in terms o= f (un)winding rather than nesting) and it appears to have been grown a bit = .. organically, I think it=E2=80=99s time for it to be replaced by a new de= sign that=E2=80=99s (conceptually) closer to raise/guard/...

 

=

I suspect the problem is that these= throw handlers or whatever are messing things up =E2=80=93 whether because= they are hard to use, impossible to use correctly or because they are inco= rrectly implemented in Guile and would propose them to be replaced by somet= hing else.

 

On this so= mething else: according to the documentation, these throw handlers can be u= sed for:

=  

  1. Clean up some related state
    2. Print a backtrace
  2. <= span lang=3Den-BE>Pass information about the exception to a debugger

 

1: IIUC, this is what (dynamic-wind #false thunk clean-up-stuff) i= s for =E2=80=93 this is not entirely correct w.r.t. userspace threading imp= lementation, but can be salvaged with something like

<= p class=3DMsoNormal> 

>https://github.com/wingo/fibers/blob/7e= 29729db7c023c346bc88c859405c978131f27a/fibers/scheduler.scm#L278=

 =

to override =E2=80=98dynamic-wi= nd=E2=80=99 (actually I think the API =E2=80=98rewinding-for-scheduling?=E2= =80=99 would need to be adjusted a bit to allow for situations like impleme= nting threads inside threads inside threads inside ..., but it should give = the basic idea.)

 

2. t= he rationale for this reason, is that when an exception is caught (think = =E2=80=98catch=E2=80=99 handler), we are not in the same dynamic environmen= t anymore, so by then it=E2=80=99s too late to generate a backtrace. But we= can have a cake(=3D have a backtrace) and eat it too(=3D post-unwind / in = the catch handler), by using =E2=80=98with-exception-handler=E2=80=99 with = =E2=80=98#:unwind? #false=E2=80=99.

 

That=E2=80=99s not entirely sufficient, because sometimes th= e exception was already caught and =E2=80=98wapped=E2=80=99 to give some ex= tra context in the exception object (but losing some backtrace in the proce= ss). OTOH, this =E2=80=98losing some backtrace=E2=80=99 already happens in = the current implementation IIUC, so it wouldn=E2=80=99t be worse than the c= urrent implementation in this respect. I think there is a solution that isn= =E2=80=99t just =E2=80=9Calways record the backtrace and put it in the exce= ption=E2=80=9D (which would be terribly inefficient in situation you mentio= ned), but I haven=E2=80=99t found it yet.

 

Perhaps the (full) current continuation (think call/cc= ) could be saved? And then later, when ultimately a backtrace is to be prin= ted, the stack of this continuation can be investigated =E2=80=93 This migh= t seem even more inefficient than saving a backtrace, but if you think abou= t it, all those frames were already allocated, so you don=E2=80=99t need to= allocate new memory or do much CPU things beyond saving some pointers, you= just need to start some new memory branching of an earlier point in the dy= namic environment/the frames when/after rewinding.=C2=A0 I=E2=80=99m thinki= ng of spaghetti and cactus stacks.=C2=A0=C2=A0 (The benefit beyond =E2=80= =98just include backtrace=E2=80=99 is: (1) almost 0 time/memory cost when n= ot used (2) if desired, you can print _more_ information than just t= he backtrace, e.g. values of certain parameters or whatever.)

 

And after the backtrace or whateve= r has been printed, there is no reference to the call/cc thing anymore so i= t can be garbage collected(*).

 

(*) there is a bit of a caveat here with respect to user-level th= reading and pausing computations, where some stuff low(high?) on the stack = might be saved for too long, so perhaps it would instead be better to save = a delimited continuation =E2=80=93 the exception handler that does the back= tracing could then set some parameter with a tag that delimits where to sto= p the delimited continuation =E2=80=93 for a comparison: I think there is a= procedure with a name like =E2=80=9Ccall-with-stack=E2=80=9D or something = close to that which does something like that.

 

(Also, the section =E2=80=9CExceptions=E2=80=9D is= n=E2=80=99t mentioning =E2=80=98raise + guard=E2=80=99, instead there is a = separate R6RS section isolated from the rest of the manual =E2=80=93 it tre= ats historical Guile idiosyncrasies as the norm and standard SRFI / RnRS as= an aberration. But that=E2=80=99s a different thing.)

 

= = --_F09A6C71-D3FB-45E1-B294-DA67E742796C_-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 12 12:32:18 2024 Received: (at 46009) by debbugs.gnu.org; 12 Jun 2024 16:32:18 +0000 Received: from localhost ([127.0.0.1]:40029 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sHQtV-0000om-Ku for submit@debbugs.gnu.org; Wed, 12 Jun 2024 12:32:18 -0400 Received: from mail-43166.protonmail.ch ([185.70.43.166]:22295) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sHQtT-0000oT-6Y for 46009@debbugs.gnu.org; Wed, 12 Jun 2024 12:32:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lendvai.name; s=protonmail2; t=1718209929; x=1718469129; bh=45/uezXzYL15/NRzLJjH+4DNaTuzDWMp3tcAsycWur8=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=YCFfKww74+Vt/Sm3oWTmybVS6H86uQMBDyKAYMBE1tfOwXm8R2cxXyZ6cZ0Ex0oIO a4m9sMXXJzghsuPO1kLk6IIxnBek/G9ENEjYR2dV8VP4fQdgzvLC5X+tspDAf2uueA q5crdo97pJnhu2qvQR/QKvlzltjzb7waQEhZ68n1euywNrnqsLRrPj+9FVrVjpFVqT ePGi0gN9SWYrQysEBb9SeagGQVPHHnY92ckJZWiwhiqN8DTuE7VwiQVnuEXX5Hs5JZ hJ055KwKxCelZQ6T3l3Pz09Ht0+XNxTsnWbaAjoitYztoWDzMUn5ediXIuaRR0/JqV av55WcipTGbXA== Date: Wed, 12 Jun 2024 16:32:03 +0000 To: Maxime Devos From: Attila Lendvai Subject: RE: exception from inside false-if-exception? Message-ID: In-Reply-To: <20240506205840.Kuyd2C00E17cfcj01uygoD@xavier.telenet-ops.be> References: <87le4wz1s9.fsf@cbaines.net> <20240506205840.Kuyd2C00E17cfcj01uygoD@xavier.telenet-ops.be> Feedback-ID: 28384833:user:proton X-Pm-Message-ID: 5bb6de62a22bce9e824aafc4fe201ce6b221c287 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_0MZa0gcJ3ja0yVTwxWJpHX8oDeZuY9JlZ49VM1hNN4" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46009 Cc: "46009@debbugs.gnu.org" <46009@debbugs.gnu.org>, Christopher Baines , "guile-devel@gnu.org" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) This is a multi-part message in MIME format. --b1_0MZa0gcJ3ja0yVTwxWJpHX8oDeZuY9JlZ49VM1hNN4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 th= at i didn't even consider that to be the case. some hours later i found thi= s: https://practical-scheme.net/gauche/man/gauche-refe/Exceptions.html#index-w= ith_002dexception_002dhandler "Note: SRFI-18 specifies the exception handler installed with with-exceptio= n-handler will be called with exactly the same dynamic environment, includi= ng the exception handler settings. It means if an exception is raised withi= n the handler, it will be caught with the same handler." "However, the bare SRFI-18 semantics turned out to be error prone=E2=80= =93users tended to assume errors from a handler would be handled by outer h= andler, and were perplexed when they ran into infinite recursion of handler= s" now, as surprising as the above was to me, guile behaves in a yet more surp= rising way, because seeing a stack overflow would have hinted the above sem= antics to me. instead, what seems to be happening (?) is that there's some short-circuit = somewhere in the guile codebase that aborts this infinite recursion by prin= ting a backtrace and the exception... and then continues who knows where, a= nd with what return value? unfortunately, it doesn't print anything else to= explain the situation, or to grep for in the codebase. context: -------- in the original context of shepherd, it doesn't seem to just entirely exit = the process, because shepherd continues to run, and IIRC it even functions = to some extent. and it doesn't seem to just exit the current thread either,= because IIUC shepherd is a single-threaded app (using fibers). for reference, i'm including the output at the end of this mail that i'm se= eing in my shepherd branch. note that it says "Uncaught exception in task:"= which suggests that this exception seems to have left a fiber and reached = fiber's RUN-SCHEDULER/ERROR-HANDLING. and finally, my ultimate use-case is a CALL-WITH-ERROR-HANDLING function th= at does not unwind, and has three layers of nested error handlers to log an= y errors with a backtrace, including errors in the user supplied error hand= lers, or in the logging subsystem. i see two actionables: ---------------------- if i'm not wrong in the above, then: please add some message -- any message -- to this short-circuit code. please extend the doc of WITH-EXCEPTION-HANDLER with a warning that explain= s the dynamic extent of the binding of the handler at the time the handler = is called, and any possible short circuits installed in guile against that. --=20 =E2=80=A2 attila lendvai =E2=80=A2 PGP: 963F 5D5F 45C7 DFCD 0A39 -- =E2=80=9CThe strength of a person's spirit would then be measured by how mu= ch 'truth' he could tolerate, or more precisely, to what extent he needs to= have it diluted, disguised, sweetened, muted, falsified.=E2=80=9D =09=E2=80=94 Friedrich Nietzsche (1844=E2=80=931900), 'Beyond Good and Evil= ' (1886) Uncaught exception in task: In fibers.scm: 172:8 13 (_) In shepherd/service.scm: 425:9 12 (_) In ice-9/boot-9.scm: 1752:10 11 (with-exception-handler _ _ #:unwind? _ # _) In shepherd/service.scm: 570:31 10 (service-controller # #< getq: ?>) In /gnu/store/0zd8bv4hmrfqhzb5qv6flslah0a7bplb-shepherd-bee-1.scm: 1:3579 9 (_ _ . _) In ice-9/boot-9.scm: 1685:16 8 (raise-exception _ #:continuable? _) 1752:10 7 (with-exception-handler _ _ #:unwind? _ # _) In shepherd/support.scm: 644:4 6 (log-with-backtrace _ #<&compound-exception componen?> . #) In unknown file: 5 (display-backtrace # # ?) In system/repl/debug.scm: 148:36 4 (print-frames #(# # ?) ?) In ice-9/boot-9.scm: 2137:6 3 (_) 1747:15 2 (with-exception-handler # ?) In system/repl/debug.scm: 72:40 1 (_) In ice-9/boot-9.scm: 1685:16 0 (raise-exception _ #:continuable? _) ice-9/boot-9.scm:1685:16: In procedure raise-exception: In procedure string->number: Wrong type argument in position 1 (expecting s= tring): #f --b1_0MZa0gcJ3ja0yVTwxWJpHX8oDeZuY9JlZ49VM1hNN4 Content-Type: text/x-scheme; name=test.scm Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=test.scm IyEvdXNyL2Jpbi9lbnYgLVMgZ3VpbGUgLS1uby1hdXRvLWNvbXBpbGUgLWUgbWFpbiAtcwohIwoK KHVzZS1tb2R1bGVzIChzcmZpIHNyZmktMzQpKQoKKGRlZmluZSogKHRlc3QgIzprZXkgKHVud2lu ZD8gI2YpKQogICh3aXRoLWV4Y2VwdGlvbi1oYW5kbGVyCiAgICAgIChsZXQgKChuZXN0ZWQgI2Yp KQogICAgICAgIChsYW1iZGEgKGMtbGV2ZWwtMSkKICAgICAgICAgIChpZiBuZXN0ZWQKICAgICAg ICAgICAgICAoYmVnaW4KICAgICAgICAgICAgICAgIChmb3JtYXQgI3QgImxldmVsIDEgaGFuZGxl ciBnb3QgY2FsbGVkIHJlY3Vyc2l2ZWx5fiUiKQogICAgICAgICAgICAgICAgJ2xldmVsLTEtaGFu ZGxlci1uZXN0ZWQpCiAgICAgICAgICAgICAgKGJlZ2luCiAgICAgICAgICAgICAgICAoc2V0ISBu ZXN0ZWQgI3QpCiAgICAgICAgICAgICAgICAod2l0aC1leGNlcHRpb24taGFuZGxlcgogICAgICAg ICAgICAgICAgICAgIChsYW1iZGEgKGMtbGV2ZWwtMikKICAgICAgICAgICAgICAgICAgICAgIChi ZWdpbgogICAgICAgICAgICAgICAgICAgICAgICAoZm9ybWF0ICN0ICJsZXZlbCAyIGhhbmRsZXIg Z290IGVycm9yIH5BfiUiIGMtbGV2ZWwtMikKICAgICAgICAgICAgICAgICAgICAgICAgJ2xldmVs LTItaGFuZGxlcikpCiAgICAgICAgICAgICAgICAgIChsYW1iZGEgKCkKICAgICAgICAgICAgICAg ICAgICAoZm9ybWF0ICN0ICJsZXZlbCAxIGhhbmRsZXJ+JSIpCiAgICAgICAgICAgICAgICAgICAg KGVycm9yICJsZXQncyBzaWduYWwgYSBuZXN0ZWQgZXJyb3IuLi4iKQogICAgICAgICAgICAgICAg ICAgIChmb3JtYXQgI3QgImxldmVsIDEgaGFuZGxlciBpcyByZXR1cm5pbmd+JSIpCiAgICAgICAg ICAgICAgICAgICAgJ2xldmVsLTEtaGFuZGxlcikKICAgICAgICAgICAgICAgICAgIzp1bndpbmQ/ IHVud2luZD8pKSkpKQogICAgKGxhbWJkYSAoKQogICAgICAoZXJyb3IgImxldCdzIHNpZ25hbCBh biBlcnJvci4uLiIpCiAgICAgICd0aHVuaykKICAgICM6dW53aW5kPyB1bndpbmQ/KSkKCihkZWZp bmUgKG1haW4gY21kKQogICh1bnNldGVudiAiQ09MVU1OUyIpCiAgKGZvcm1hdCAjdCAifiV+JSoq KiBjYWxsaW5nIHdpdGggdW53aW5kfiUiKQogIChmb3JtYXQgI3QgInJldHVybiB2YWx1ZSBpczog fkF+JSIgKHRlc3QgIzp1bndpbmQ/ICN0KSkKICAoZm9ybWF0ICN0ICJ+JX4lKioqIGNhbGxpbmcg d2l0aG91dCB1bndpbmR+JSIpCiAgKGZvcm1hdCAjdCAicmV0dXJuIHZhbHVlIGlzOiB+QX4lIiAo dGVzdCAjOnVud2luZD8gI2YpKQogICh0ZXN0ICM6dW53aW5kPyAjZikpCg== --b1_0MZa0gcJ3ja0yVTwxWJpHX8oDeZuY9JlZ49VM1hNN4-- From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 17 15:58:13 2024 Received: (at 46009) by debbugs.gnu.org; 17 Jun 2024 19:58:14 +0000 Received: from localhost ([127.0.0.1]:36444 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sJIUX-0002PA-FE for submit@debbugs.gnu.org; Mon, 17 Jun 2024 15:58:13 -0400 Received: from mail-40136.proton.ch ([185.70.40.136]:15073) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sJIUW-0002Ov-C3 for 46009@debbugs.gnu.org; Mon, 17 Jun 2024 15:58:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lendvai.name; s=protonmail2; t=1718654283; x=1718913483; bh=owQt9nscIJNrYqud75i5OUWKNSWckRhFyRBva0KRadQ=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=lZvSRB4ScpgjiaWvDt04xBBrykizBOU5SITrzy2cJ6ECMEiDTci9UXu/wLBMZ1KTz S+S+AxH5UBWM9b0zmymaAAMCqZuxAoWRtOl5IPl5PWQzMqv6aeUayivm+l2fSbRVT9 x4MakHKeDYAQYwNp3olvQAQ89cy8/sK56RzOI5P5jM0+GaNAqmFZ82CiMkaws4Mhn/ VL/JCEiSL8WoOP56EgtQQQIyOiYfkrGSQ5ETMrpO1S/jlocKu1OxVGThCHx61akzeV LFmYeOZLelLXzxZ741D/xtijjYxuDUqg1HcJ/1CLIYBOg0nUfaLSmsTpS86lnM+pmc A2kRwlYMHh2Uw== Date: Mon, 17 Jun 2024 19:57:58 +0000 To: Maxime Devos From: Attila Lendvai Subject: RE: exception from inside false-if-exception? Message-ID: In-Reply-To: References: <87le4wz1s9.fsf@cbaines.net> <20240506205840.Kuyd2C00E17cfcj01uygoD@xavier.telenet-ops.be> Feedback-ID: 28384833:user:proton X-Pm-Message-ID: 2c08454723d75ec8ee716474a1068f14308c244f MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_TGS6MIfLZks9nBXtGtAzqNPJlq63rwGs7FtJMC0k1oQ" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46009 Cc: "46009@debbugs.gnu.org" <46009@debbugs.gnu.org>, Christopher Baines , "guile-devel@gnu.org" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) This is a multi-part message in MIME format. --b1_TGS6MIfLZks9nBXtGtAzqNPJlq63rwGs7FtJMC0k1oQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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-h block, but with #:unwind #f it tries to return to t= he RAISE that raised the condition. i.e. a lousy little keyword arg (usuall= y a page down) fundamentally changes the behavior of w-e-h. yet another sur= prise that violated my expectations regarding APIs. anyway, i've attached a patch that clarifies what's happening for anyone wh= o stumbles upon this; i.e. be clearer that (?) a backtrace is printed due t= o reaching a continuation barrier. this makes it grep'able, and if the user also prints a backtrace, then it m= akes it clear that it's something printed by guile. if someone wants to investigate further, then i'm also attaching a new vers= ion of my test.scm that behaves in an unexpected way on 3.0.9, but not on H= EAD (more specifically on guile-next in guix, which is a rather recent comm= it). HTH, --=20 =E2=80=A2 attila lendvai =E2=80=A2 PGP: 963F 5D5F 45C7 DFCD 0A39 -- All men dream, but not equally. Those who dream by night in the dusty reces= ses of their minds wake in the day to find that it was vanity. But the drea= mers of the day are dangerous men, for they may act their dream with open e= yes to make it possible. --b1_TGS6MIfLZks9nBXtGtAzqNPJlq63rwGs7FtJMC0k1oQ Content-Type: text/x-patch; name=0001-More-specific-error-message-for-exceptions-at-contin.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=0001-More-specific-error-message-for-exceptions-at-contin.patch RnJvbSBkNDU4MTcwOTcxODFkNGE1ODEyNDA1NDc0YWM3YjI0YWYzNTMxZjdhIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBBdHRpbGEgTGVuZHZhaSA8YXR0aWxhQGxlbmR2YWkubmFtZT4K RGF0ZTogTW9uLCAxNyBKdW4gMjAyNCAxOTo0Njo0NSArMDIwMApTdWJqZWN0OiBbUEFUQ0hdIE1v cmUgc3BlY2lmaWMgZXJyb3IgbWVzc2FnZSBmb3IgZXhjZXB0aW9ucyBhdCBjb250aW51YXRpb24K IGJhcnJpZXJzCgotLS0KIGxpYmd1aWxlL2NvbnRpbnVhdGlvbnMuYyB8IDIgKy0KIDEgZmlsZSBj aGFuZ2VkLCAxIGluc2VydGlvbigrKSwgMSBkZWxldGlvbigtKQoKZGlmZiAtLWdpdCBhL2xpYmd1 aWxlL2NvbnRpbnVhdGlvbnMuYyBiL2xpYmd1aWxlL2NvbnRpbnVhdGlvbnMuYwppbmRleCBiOGI2 ZTFkY2EuLjQ5ZjgyNjZkZCAxMDA2NDQKLS0tIGEvbGliZ3VpbGUvY29udGludWF0aW9ucy5jCisr KyBiL2xpYmd1aWxlL2NvbnRpbnVhdGlvbnMuYwpAQCAtNDA1LDcgKzQwNSw3IEBAIHByaW50X2V4 Y2VwdGlvbl9hbmRfYmFja3RyYWNlIChTQ00gcG9ydCwgU0NNIHRhZywgU0NNIGFyZ3MpCiAKICAg aWYgKHNob3VsZF9wcmludF9iYWNrdHJhY2UgKHRhZywgc3RhY2spKQogICAgIHsKLSAgICAgIHNj bV9wdXRzICgiQmFja3RyYWNlOlxuIiwgcG9ydCk7CisgICAgICBzY21fcHV0cyAoIkFuIGV4Y2Vw dGlvbiBoYXMgcmVhY2hlZCBhIGNvbnRpbnVhdGlvbiBiYXJyaWVyOlxuIiwgcG9ydCk7CiAgICAg ICBzY21fZGlzcGxheV9iYWNrdHJhY2Vfd2l0aF9oaWdobGlnaHRzIChzdGFjaywgcG9ydCwKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNDTV9CT09MX0YsIFND TV9CT09MX0YsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBT Q01fRU9MKTsKLS0gCjIuNDUuMQoK --b1_TGS6MIfLZks9nBXtGtAzqNPJlq63rwGs7FtJMC0k1oQ Content-Type: text/x-scheme; name=test.scm Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=test.scm IyEvdXNyL2Jpbi9lbnYgLVMgZ3VpbGUgLS1uby1hdXRvLWNvbXBpbGUgLWUgbWFpbiAtcwohIwoK KHVzZS1tb2R1bGVzIChpY2UtOSBjb250cm9sKSkKCihkZWZpbmUqICh0ZXN0ICM6a2V5ICh1bndp bmQ/ICNmKSkKICAobGV0L2VjIHJldHVybgogICAgKHdpdGgtZXhjZXB0aW9uLWhhbmRsZXIKICAg ICAgICAobGV0ICgobmVzdGVkICNmKSkKICAgICAgICAgIChsYW1iZGEgKGMtbGV2ZWwtMSkKICAg ICAgICAgICAgKGlmIG5lc3RlZAogICAgICAgICAgICAgICAgKGJlZ2luCiAgICAgICAgICAgICAg ICAgIChmb3JtYXQgI3QgImxldmVsIDEgaGFuZGxlciBnb3QgY2FsbGVkIHJlY3Vyc2l2ZWx5fiUi KQogICAgICAgICAgICAgICAgICAnbGV2ZWwtMS1oYW5kbGVyLW5lc3RlZCkKICAgICAgICAgICAg ICAgIChiZWdpbgogICAgICAgICAgICAgICAgICAoc2V0ISBuZXN0ZWQgI3QpCiAgICAgICAgICAg ICAgICAgICh3aXRoLWV4Y2VwdGlvbi1oYW5kbGVyCiAgICAgICAgICAgICAgICAgICAgICAobGFt YmRhIChjLWxldmVsLTIpCiAgICAgICAgICAgICAgICAgICAgICAgIChiZWdpbgogICAgICAgICAg ICAgICAgICAgICAgICAgIChmb3JtYXQgI3QgImxldmVsIDIgaGFuZGxlciBnb3QgZXJyb3IgfkF+ JSIgYy1sZXZlbC0yKQogICAgICAgICAgICAgICAgICAgICAgICAgIChmb3JtYXQgI3QgImxldmVs IDIgaGFuZGxlciBpcyByZXR1cm5pbmd+JSIpCiAgICAgICAgICAgICAgICAgICAgICAgICAgKHJl dHVybiAnbGV2ZWwtMi1oYW5kbGVyKSkpCiAgICAgICAgICAgICAgICAgICAgKGxhbWJkYSAoKQog ICAgICAgICAgICAgICAgICAgICAgKGZvcm1hdCAjdCAibGV2ZWwgMSBoYW5kbGVyfiUiKQogICAg ICAgICAgICAgICAgICAgICAgKGVycm9yICJsZXQncyBzaWduYWwgYSBuZXN0ZWQgZXJyb3IuLi4i KQogICAgICAgICAgICAgICAgICAgICAgKGZvcm1hdCAjdCAibGV2ZWwgMSBoYW5kbGVyIGlzIHJl dHVybmluZ34lIikKICAgICAgICAgICAgICAgICAgICAgIChyZXR1cm4gJ2xldmVsLTEtaGFuZGxl cikpCiAgICAgICAgICAgICAgICAgICAgIzp1bndpbmQ/IHVud2luZD8pKSkpKQogICAgICAobGFt YmRhICgpCiAgICAgICAgKGVycm9yICJsZXQncyBzaWduYWwgYW4gZXJyb3IuLi4iKQogICAgICAg ICd0aHVuaykKICAgICAgIzp1bndpbmQ/IHVud2luZD8pKSkKCihkZWZpbmUgKG1haW4gY21kKQog ICh1bnNldGVudiAiQ09MVU1OUyIpCiAgKGZvcm1hdCAjdCAifiV+JSoqKiBjYWxsaW5nIHdpdGgg dW53aW5kfiUiKQogIChmb3JtYXQgI3QgInJldHVybiB2YWx1ZSBpczogfkF+JSIgKHRlc3QgIzp1 bndpbmQ/ICN0KSkKICAoZm9ybWF0ICN0ICJ+JX4lKioqIGNhbGxpbmcgd2l0aG91dCB1bndpbmR+ JSIpCiAgKGZvcm1hdCAjdCAicmV0dXJuIHZhbHVlIGlzOiB+QX4lIiAodGVzdCAjOnVud2luZD8g I2YpKSkK --b1_TGS6MIfLZks9nBXtGtAzqNPJlq63rwGs7FtJMC0k1oQ-- From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 17 16:52:32 2024 Received: (at 46009) by debbugs.gnu.org; 17 Jun 2024 20:52:32 +0000 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 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 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) 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 Message-ID: <20240617225055.ckqu2C0045M5ED401kquFP@laurent.telenet-ops.be> MIME-Version: 1.0 To: Attila Lendvai From: Maxime Devos Subject: RE: exception from inside false-if-exception? Date: Mon, 17 Jun 2024 22:50:54 +0200 Importance: normal X-Priority: 3 In-Reply-To: References: <87le4wz1s9.fsf@cbaines.net> <20240506205840.Kuyd2C00E17cfcj01uygoD@xavier.telenet-ops.be> Content-Type: multipart/alternative; boundary="_85EC6980-4DBD-44BD-87F5-C76A9166FE40_" 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-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46009 Cc: "46009@debbugs.gnu.org" <46009@debbugs.gnu.org>, Christopher Baines , "guile-devel@gnu.org" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --_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_-- From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 17 17:45:58 2024 Received: (at 46009) by debbugs.gnu.org; 17 Jun 2024 21:45:58 +0000 Received: from localhost ([127.0.0.1]:37988 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sJKAn-0005hx-Ef for submit@debbugs.gnu.org; Mon, 17 Jun 2024 17:45:58 -0400 Received: from mail-4317.proton.ch ([185.70.43.17]:14049) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sJKAl-0005hh-Gs for 46009@debbugs.gnu.org; Mon, 17 Jun 2024 17:45:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lendvai.name; s=protonmail2; t=1718660746; x=1718919946; bh=xswrqBRL8kkgoPHDQ2xAKUPqzeG+unCI4PzXMP/GnUc=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=D+TZh6GchWkVA5WZ957t5iG4YL57IGL0lvthzsCa/xKpLeUSz/Tk7nvXYjMHFieut UNxXKWXwd7KycmHNxtFHpNXXxwULOa7WYq29Q8pULizEh4tFMs6+ADf/zqBa/nNmN0 fLG77MNnMq+9f2ibrEiI1TC9RNsUg6vFu5AqZDwOdhh/ZoPW+/zJIzMxP8aabGC8B0 5H54qWitPgJwbvL+92Zgp3CkumlvvtrvhnziwmzlDI7lzJUonW+PLU8HIFFBlNSlTe vXWrXi0i4yBM0f6VgA4YEdnwPgsXE15xnephVs/ElVGOZ76sO9AgS2VxF8YAShMvsH BUzFG4tUQsHvw== Date: Mon, 17 Jun 2024 21:45:42 +0000 To: Maxime Devos From: Attila Lendvai Subject: RE: exception from inside false-if-exception? Message-ID: In-Reply-To: <20240617225055.ckqu2C0045M5ED401kquFP@laurent.telenet-ops.be> References: <87le4wz1s9.fsf@cbaines.net> <20240506205840.Kuyd2C00E17cfcj01uygoD@xavier.telenet-ops.be> <20240617225055.ckqu2C0045M5ED401kquFP@laurent.telenet-ops.be> Feedback-ID: 28384833:user:proton X-Pm-Message-ID: edd4844a74f2213d5b57348caf5dbfd4604e9197 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_6bkQt1af2rUfvynIDD3CjlNDVKkWSBQq8Sng7yEQWE" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46009 Cc: "46009@debbugs.gnu.org" <46009@debbugs.gnu.org>, Christopher Baines , "guile-devel@gnu.org" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) This is a multi-part message in MIME format. --b1_6bkQt1af2rUfvynIDD3CjlNDVKkWSBQq8Sng7yEQWE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > 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, a= nd defaults to one of the rather different possibilities. in this case, it's a primitive to catch and handle exceptions. and it's pos= sible to implement both #:unwind? #t and #f so that when the handler return= s 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=E2=80=99s too late to return return from the rai= se > (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 le= ast mentioned with bold in the documentation). > That said, I would prefer it to be named something like [#:handler-contex= t '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 co= ntrol. for reference, in CL they are called HANDLER-CASE and HANDLER-BIND, with co= mpletely different syntaxes. > 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. this has caused me layers of confusion, which is sadly reflected in my mail= s. 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 (rem= ember, 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 bel= ieve that i'm logging an exception coming from inside FALSE-IF-EXCEPTION an= d 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 FAL= SE-IF-EXCEPTION somehow ending up at fibers instead of my error handler. bu= t at this point i'm reaching the frontier of my understanding of scheme, de= limited continuations, fibers, etc. so, one step at a time. once this test.scm is clear, and i'm able to run sh= epherd on guile-next, then i'll get back to investigate my original issue i= n 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, whi= ch is almost guile HEAD). HTH, -- =E2=80=A2 attila lendvai =E2=80=A2 PGP: 963F 5D5F 45C7 DFCD 0A39 -- =E2=80=9CLife becomes easier when you learn to accept the apology you never= got.=E2=80=9D =09=E2=80=94 Robert Brault --b1_6bkQt1af2rUfvynIDD3CjlNDVKkWSBQq8Sng7yEQWE Content-Type: text/x-scheme; name=test.scm Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=test.scm IyEvdXNyL2Jpbi9lbnYgLVMgZ3VpbGUgLS1uby1hdXRvLWNvbXBpbGUgLWUgbWFpbiAtcwohIwoK KHVzZS1tb2R1bGVzIChpY2UtOSBjb250cm9sKSkKCihkZWZpbmUqICh0ZXN0ICM6a2V5ICh1bndp bmQ/ICNmKSkKICAobGV0L2VjIHJldHVybgogICAgKHdpdGgtZXhjZXB0aW9uLWhhbmRsZXIKICAg ICAgICAobGV0ICgobmVzdGVkICNmKSkKICAgICAgICAgIChsYW1iZGEgKGMtbGV2ZWwtMSkKICAg ICAgICAgICAgKGlmIG5lc3RlZAogICAgICAgICAgICAgICAgKGJlZ2luCiAgICAgICAgICAgICAg ICAgIChmb3JtYXQgI3QgImxldmVsIDEgaGFuZGxlciBnb3QgY2FsbGVkIHJlY3Vyc2l2ZWx5fiUi KQogICAgICAgICAgICAgICAgICAnbGV2ZWwtMS1oYW5kbGVyLW5lc3RlZCkKICAgICAgICAgICAg ICAgIChiZWdpbgogICAgICAgICAgICAgICAgICAoc2V0ISBuZXN0ZWQgI3QpCiAgICAgICAgICAg ICAgICAgICh3aXRoLWV4Y2VwdGlvbi1oYW5kbGVyCiAgICAgICAgICAgICAgICAgICAgICAobGFt YmRhIChjLWxldmVsLTIpCiAgICAgICAgICAgICAgICAgICAgICAgIChiZWdpbgogICAgICAgICAg ICAgICAgICAgICAgICAgIChmb3JtYXQgI3QgImxldmVsIDIgaGFuZGxlciBnb3QgZXJyb3IgfkF+ JSIgYy1sZXZlbC0yKQogICAgICAgICAgICAgICAgICAgICAgICAgIChmb3JtYXQgI3QgImxldmVs IDIgaGFuZGxlciBpcyByZXR1cm5pbmd+JSIpCiAgICAgICAgICAgICAgICAgICAgICAgICAgKHJl dHVybiAnbGV2ZWwtMi1oYW5kbGVyKSkpCiAgICAgICAgICAgICAgICAgICAgKGxhbWJkYSAoKQog ICAgICAgICAgICAgICAgICAgICAgKGZvcm1hdCAjdCAibGV2ZWwgMSBoYW5kbGVyfiUiKQogICAg ICAgICAgICAgICAgICAgICAgKGVycm9yICJsZXQncyBzaWduYWwgYSBuZXN0ZWQgZXJyb3IuLi4i KQogICAgICAgICAgICAgICAgICAgICAgKGZvcm1hdCAjdCAibGV2ZWwgMSBoYW5kbGVyIGlzIHJl dHVybmluZ34lIikKICAgICAgICAgICAgICAgICAgICAgIChyZXR1cm4gJ2xldmVsLTEtaGFuZGxl cikpCiAgICAgICAgICAgICAgICAgICAgIzp1bndpbmQ/IHVud2luZD8pKSkpKQogICAgICAobGFt YmRhICgpCiAgICAgICAgKGVycm9yICJsZXQncyBzaWduYWwgYW4gZXJyb3IuLi4iKQogICAgICAg ICd0aHVuaykKICAgICAgIzp1bndpbmQ/IHVud2luZD8pKSkKCihkZWZpbmUgKG1haW4gY21kKQog ICh1bnNldGVudiAiQ09MVU1OUyIpCiAgKGZvcm1hdCAjdCAifiV+JSoqKiBjYWxsaW5nIHdpdGgg dW53aW5kfiUiKQogIChmb3JtYXQgI3QgInJldHVybiB2YWx1ZSBpczogfkF+JSIgKHRlc3QgIzp1 bndpbmQ/ICN0KSkKICAoZm9ybWF0ICN0ICJ+JX4lKioqIGNhbGxpbmcgd2l0aG91dCB1bndpbmR+ JSIpCiAgKGZvcm1hdCAjdCAicmV0dXJuIHZhbHVlIGlzOiB+QX4lIiAodGVzdCAjOnVud2luZD8g I2YpKSkKCiN8CiQgZ3VpbGUgLS12ZXJzaW9uCmd1aWxlIChHTlUgR3VpbGUpIDMuMC45CiQgZ3Vp bGUgLS1uby1hdXRvLWNvbXBpbGUgLWUgbWFpbiAtcyB+L3dvcmtzcGFjZS9ndWlsZS90ZXN0LnNj bQoKCioqKiBjYWxsaW5nIHdpdGggdW53aW5kCmxldmVsIDEgaGFuZGxlcgpsZXZlbCAyIGhhbmRs ZXIgZ290IGVycm9yICM8JmNvbXBvdW5kLWV4Y2VwdGlvbiBjb21wb25lbnRzOiAoIzwmZXJyb3I+ ICM8Jm9yaWdpbiBvcmlnaW46ICNmPiAjPCZtZXNzYWdlIG1lc3NhZ2U6ICJ+QSI+ICM8Jmlycml0 YW50cyBpcnJpdGFudHM6ICgibGV0J3Mgc2lnbmFsIGEgbmVzdGVkIGVycm9yLi4uIik+ICM8JmV4 Y2VwdGlvbi13aXRoLWtpbmQtYW5kLWFyZ3Mga2luZDogbWlzYy1lcnJvciBhcmdzOiAoI2YgIn5B IiAoImxldCdzIHNpZ25hbCBhIG5lc3RlZCBlcnJvci4uLiIpICNmKT4pPgpsZXZlbCAyIGhhbmRs ZXIgaXMgcmV0dXJuaW5nCnJldHVybiB2YWx1ZSBpczogbGV2ZWwtMi1oYW5kbGVyCgoKKioqIGNh bGxpbmcgd2l0aG91dCB1bndpbmQKbGV2ZWwgMSBoYW5kbGVyCkJhY2t0cmFjZToKSW4gaWNlLTkv Ym9vdC05LnNjbToKICAxNzUyOjEwIDEyICh3aXRoLWV4Y2VwdGlvbi1oYW5kbGVyIF8gXyAjOnVu d2luZD8gXyAjIF8pCkluIHVua25vd24gZmlsZToKICAgICAgICAgIDExIChhcHBseS1zbW9iLzAg Izx0aHVuayA3ZjhkNzMzMTMzMDA+KQpJbiBpY2UtOS9ib290LTkuc2NtOgogICAgNzI0OjIgMTAg KGNhbGwtd2l0aC1wcm9tcHQgKCJwcm9tcHQiKSAjPHByb2NlZHVyZSA3ZjhkNzMzMjRmODAg4oCm PiDigKYpCkluIGljZS05L2V2YWwuc2NtOgogICAgNjE5OjggIDkgKF8gIygjKCM8ZGlyZWN0b3J5 IChndWlsZS11c2VyKSA3ZjhkNzMzMTZjODA+KSkpCiAgICAxNjM6OSAgOCAoXyAjKCMoIzxkaXJl Y3RvcnkgKGd1aWxlLXVzZXIpIDdmOGQ3MzMxNmM4MD4pICgiL2hv4oCmIikpKQpJbiBpY2UtOS9i b290LTkuc2NtOgogICAgNzI0OjIgIDcgKGNhbGwtd2l0aC1wcm9tcHQgKGxldC9lYykgIzxwcm9j ZWR1cmUgN2Y4ZDczMzUyOTAwIGF04oCmPiDigKYpCiAgMTc1MjoxMCAgNiAod2l0aC1leGNlcHRp b24taGFuZGxlciBfIF8gIzp1bndpbmQ/IF8gIyBfKQpJbiBpY2UtOS9ldmFsLnNjbToKICAgIDYx OTo4ICA1IChfICMoIygjPGRpcmVjdG9yeSAoZ3VpbGUtdXNlcikgN2Y4ZDczMzE2YzgwPikpKQpJ biBpY2UtOS9ib290LTkuc2NtOgogICAyMDA3OjcgIDQgKGVycm9yIF8gLiBfKQogIDE2ODU6MTYg IDMgKHJhaXNlLWV4Y2VwdGlvbiBfICM6Y29udGludWFibGU/IF8pCiAgMTc1MjoxMCAgMiAod2l0 aC1leGNlcHRpb24taGFuZGxlciBfIF8gIzp1bndpbmQ/IF8gIyBfKQpJbiBpY2UtOS9ldmFsLnNj bToKICAgIDYxOTo4ICAxIChfICMoIygjPGRpcmVjdG9yeSAoZ3VpbGUtdXNlcikgN2Y4ZDczMzE2 YzgwPiAjPHByb2PigKY+KSkpCkluIGljZS05L2Jvb3QtOS5zY206CiAgIDIwMDc6NyAgMCAoZXJy b3IgXyAuIF8pCgppY2UtOS9ib290LTkuc2NtOjIwMDc6NzogSW4gcHJvY2VkdXJlIGVycm9yOgps ZXQncyBzaWduYWwgYSBuZXN0ZWQgZXJyb3IuLi4KJAp8IwoKCgoKI3wKJCAvZ251L3N0b3JlL3ht MDhjcDNmejNqeHEzemRkZzljdmo1OWlkeTNyaThiLWd1aWxlLTMuMC45OS1naXQvYmluL2d1aWxl IC0tbm8tYXV0by1jb21waWxlIC1lIG1haW4gLXMgfi93b3Jrc3BhY2UvZ3VpbGUvdGVzdC5zY20K CgoqKiogY2FsbGluZyB3aXRoIHVud2luZApsZXZlbCAxIGhhbmRsZXIKbGV2ZWwgMiBoYW5kbGVy IGdvdCBlcnJvciAjPCZjb21wb3VuZC1leGNlcHRpb24gY29tcG9uZW50czogKCM8JmVycm9yPiAj PCZvcmlnaW4gb3JpZ2luOiAjZj4gIzwmbWVzc2FnZSBtZXNzYWdlOiAifkEiPiAjPCZpcnJpdGFu dHMgaXJyaXRhbnRzOiAoImxldCdzIHNpZ25hbCBhIG5lc3RlZCBlcnJvci4uLiIpPiAjPCZleGNl cHRpb24td2l0aC1raW5kLWFuZC1hcmdzIGtpbmQ6IG1pc2MtZXJyb3IgYXJnczogKCNmICJ+QSIg KCJsZXQncyBzaWduYWwgYSBuZXN0ZWQgZXJyb3IuLi4iKSAjZik+KT4KbGV2ZWwgMiBoYW5kbGVy IGlzIHJldHVybmluZwpyZXR1cm4gdmFsdWUgaXM6IGxldmVsLTItaGFuZGxlcgoKCioqKiBjYWxs aW5nIHdpdGhvdXQgdW53aW5kCmxldmVsIDEgaGFuZGxlcgpsZXZlbCAyIGhhbmRsZXIgZ290IGVy cm9yICM8JmNvbXBvdW5kLWV4Y2VwdGlvbiBjb21wb25lbnRzOiAoIzwmZXJyb3I+ICM8Jm9yaWdp biBvcmlnaW46ICNmPiAjPCZtZXNzYWdlIG1lc3NhZ2U6ICJ+QSI+ICM8Jmlycml0YW50cyBpcnJp dGFudHM6ICgibGV0J3Mgc2lnbmFsIGEgbmVzdGVkIGVycm9yLi4uIik+ICM8JmV4Y2VwdGlvbi13 aXRoLWtpbmQtYW5kLWFyZ3Mga2luZDogbWlzYy1lcnJvciBhcmdzOiAoI2YgIn5BIiAoImxldCdz IHNpZ25hbCBhIG5lc3RlZCBlcnJvci4uLiIpICNmKT4pPgpsZXZlbCAyIGhhbmRsZXIgaXMgcmV0 dXJuaW5nCnJldHVybiB2YWx1ZSBpczogbGV2ZWwtMi1oYW5kbGVyCiQKfCMK --b1_6bkQt1af2rUfvynIDD3CjlNDVKkWSBQq8Sng7yEQWE-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 19 12:52:10 2024 Received: (at 46009) by debbugs.gnu.org; 19 Jun 2024 16:52:10 +0000 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 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 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) 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 Message-ID: <20240619185059.dUqy2C00M0K6dk406UqzfD@michel.telenet-ops.be> MIME-Version: 1.0 To: Attila Lendvai From: Maxime Devos Subject: RE: exception from inside false-if-exception? Date: Wed, 19 Jun 2024 18:51:00 +0200 Importance: normal X-Priority: 3 In-Reply-To: References: <87le4wz1s9.fsf@cbaines.net> <20240506205840.Kuyd2C00E17cfcj01uygoD@xavier.telenet-ops.be> <20240617225055.ckqu2C0045M5ED401kquFP@laurent.telenet-ops.be> Content-Type: multipart/alternative; boundary="_7D710A1D-7A49-4C9A-98C3-BF6C499ACEB4_" 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-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46009 Cc: "46009@debbugs.gnu.org" <46009@debbugs.gnu.org>, Christopher Baines , "guile-devel@gnu.org" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --_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_-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 19 14:59:11 2024 Received: (at 46009) by debbugs.gnu.org; 19 Jun 2024 18:59:11 +0000 Received: from localhost ([127.0.0.1]:55312 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sK0WU-0003r2-Ua for submit@debbugs.gnu.org; Wed, 19 Jun 2024 14:59:11 -0400 Received: from mail-4018.proton.ch ([185.70.40.18]:18927) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sK0WS-0003qe-Am for 46009@debbugs.gnu.org; Wed, 19 Jun 2024 14:59:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lendvai.name; s=protonmail2; t=1718823538; x=1719082738; bh=ZTLWwxO2bgwIeB0L2q2lrLq65cVeuEJDOnBcDw4dJY4=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=eTra21FQB9KHa5nzOVNJw7fAD14YXv0dijNBDg227vLsg3kKw5qg9/j4q5cU9z00c rtd1YV0IdKImcata4Fh7FVNEFysHJe3xOH0lKSOeY7X73fqku2N5F28zd9NZ2v49cW R7OFHsNQjMnthBZ7cwZ/vxQPI9DRrI1ZYjzsNfYGVZNkR2F+kXrUd7h6pHNrXeh7hX J9l6xPJYoJUxbJY/UfYqRNwcn8ZvTQ+yEifOhnwkFfu7hWLasmQaxzBqW6VGD0me8T lyiRXUvQhZroG5Q66SaAMjl4yH0TaGBHRfx6VxNTpwNne66RKcjGOK5OP8gj/YOQtE V9+q+cpF8f3WA== Date: Wed, 19 Jun 2024 18:58:53 +0000 To: Maxime Devos From: Attila Lendvai Subject: RE: exception from inside false-if-exception? Message-ID: In-Reply-To: <20240619185059.dUqy2C00M0K6dk406UqzfD@michel.telenet-ops.be> References: <87le4wz1s9.fsf@cbaines.net> <20240506205840.Kuyd2C00E17cfcj01uygoD@xavier.telenet-ops.be> <20240617225055.ckqu2C0045M5ED401kquFP@laurent.telenet-ops.be> <20240619185059.dUqy2C00M0K6dk406UqzfD@michel.telenet-ops.be> Feedback-ID: 28384833:user:proton X-Pm-Message-ID: e8f316cb6805ab727e859220ebe40c1a422d9dcf MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46009 Cc: "46009@debbugs.gnu.org" <46009@debbugs.gnu.org>, Christopher Baines , "guile-devel@gnu.org" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > Also, I don=E2=80=99t 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 in fact a RAISE-CO= NTINUABLE, then it wouldn't even lead to a &NON-CONTINUABLE error in the #:= unwind? #f case, only to a different return value (different flow of contro= l). in my vocabulary, a different flow of control when using a control-flow pri= mitive is a fundamental change to its meaning. but your miliage may wary of= course. > If we are talking about reading comprehension, I would like to point > out that (Guile) Scheme is case-sensitive. for effective communication we need a syntax to designate when a word is to= be interpreted in the scheme/lisp domain (as opposed to plain english). us= ing all-caps in english prose is a somewhat well-spread syntax for that, ev= en in non-CL lisp contexts in my experience. > Someone coming from case-insensitive languages and someone > unfamiliar with the upcasing practice might get confused for a > moment. for a moment. and that is key. > >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. >=20 > I don=E2=80=99t get the distinction. These are two sides of the same coin= ? not really, because there are two, orthogonal dimensions here: 1) whether to unwind the stack, 2) where to return the control flow when the handler returns. (even if one combination is impossible) > >for reference, in CL they are called HANDLER-CASE and HANDLER-BIND, with= completely different syntaxes. > > Can=E2=80=99t honestly say I like those names (those suffixes -CASE / -BI= ND > don=E2=80=99t really provide information, you have to go into the spec of > HANDLER-CASE / HANDLER-BIND itself to get the differences). my point is not whether it's deducible, or whether the names are good. my p= oint is that one API is misleading (i.e. wastes human time), while the othe= r forces the reader to, at worst, look up the documentation. but certainly = not conflate the two, thinking that they are doing the same thing -- plus s= ome implementation detail regarding unwinding that he can postpone learning= about. here's a caricature of this situation: imagine a hypothetical (raise [a potentially larger sexp] #:enabled? #t/#f)= control flow primitive that simply returns when #:enabled? is #f. one can argue that "well, it's disabled, dummy!" (turing tarpit), or try to= walk in the shoes of the reader or a newcomer. yes, you're right when you say something is possible, or deducible. but no,= with all due respect, you're wrong when you imply that it doesn't make a d= ifference (in human-brain efficiency). > Going by this and some earlier text, it seems we are in agreement > that with-exception-handler should be split (albeit for different > reasons). yes. > Maybe you can install a breakpoint on > scm_c_with_continuation_barrier or something it assumes that it's already known that the curlpit is w-c-b, but that was = already well into the debugging effort. see my attached patch that intends = to greatly shorten the debugging time for anyone else walking down this pat= h after me. and it's been decades i've done any serious C coding, and i'm not looking f= orward to learning the ins and outs of gdb when i'm debugging an issue in s= cheme. > I don=E2=80=99t think Shepherd has much use of with-continuation-barrier. IIUC, any time the posix thread enters C code is an implicit continuation b= arrier. if a fiber in shepherd uses any primitive in guile that is implemen= ted in C, then it's a continuation barrier (and breaks when an attempt is m= ade to suspend that fiber). changing shepherd not to unconditionally unwind (so that meaningful backtra= ces can be logged) can lead to subtle issues due to now having some extra C= frames on the stack that were previously unwound prior to handling the err= or. i even suspect that a continuation barrier may somehow hide, or neutralize = my w-e-h higher up on the stack, and the exception from DISPLAY-BACKTRACE e= nds up at the fibers scheduler instead of my w-e-h due to the above. but with that i'm again at the frontier of my understanding. to say anythin= g more useful i'll need to test my shepherd branch using the latest guile. --=20 =E2=80=A2 attila lendvai =E2=80=A2 PGP: 963F 5D5F 45C7 DFCD 0A39 -- =E2=80=9CYour head is for having ideas not for holding them.=E2=80=9D =09=E2=80=94 David Allen (1945=E2=80=93), http://youtu.be/D-3nTl8M44o?t=3D6= m12s From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 19 18:04:42 2024 Received: (at 46009) by debbugs.gnu.org; 19 Jun 2024 22:04:42 +0000 Received: from localhost ([127.0.0.1]:32768 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sK3Q0-0004Mr-NN for submit@debbugs.gnu.org; Wed, 19 Jun 2024 18:04:42 -0400 Received: from cantor.telenet-ops.be ([195.130.132.48]:40842) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sK3Pw-0004Mf-PB for 46009@debbugs.gnu.org; Wed, 19 Jun 2024 18:04:38 -0400 Received: from xavier.telenet-ops.be (xavier.telenet-ops.be [IPv6:2a02:1800:120:4::f00:14]) by cantor.telenet-ops.be (Postfix) with ESMTPS id 4W4Hhw03sRz4yQGv for <46009@debbugs.gnu.org>; Thu, 20 Jun 2024 00:04:32 +0200 (CEST) Received: from [IPv6:2a02:1811:8c0e:ef00:ad11:ee0:137f:2aa4] ([IPv6:2a02:1811:8c0e:ef00:ad11:ee0:137f:2aa4]) by xavier.telenet-ops.be with bizsmtp id da3V2C0080K6dk401a3VaK; Thu, 20 Jun 2024 00:03:29 +0200 Message-ID: <20240620000329.da3V2C0080K6dk401a3VaK@xavier.telenet-ops.be> MIME-Version: 1.0 To: Attila Lendvai From: Maxime Devos Subject: RE: exception from inside false-if-exception? Date: Thu, 20 Jun 2024 00:03:30 +0200 Importance: normal X-Priority: 3 In-Reply-To: References: <87le4wz1s9.fsf@cbaines.net> <20240506205840.Kuyd2C00E17cfcj01uygoD@xavier.telenet-ops.be> <20240617225055.ckqu2C0045M5ED401kquFP@laurent.telenet-ops.be> <20240619185059.dUqy2C00M0K6dk406UqzfD@michel.telenet-ops.be> Content-Type: multipart/alternative; boundary="_2FA69448-0431-492C-8A8C-6B8D9BCE68CB_" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=telenet.be; s=r24; t=1718834609; bh=ELYe5i63eSJcyw1kyEZYhUtxSeLqJuUmePM0Skkafcs=; h=To:Cc:From:Subject:Date:In-Reply-To:References; b=GaGdRQnP+5FdmVe9jFiW/gLgBnsxXt69CutxN/Nogi2bwHZoNEErS5g0AYKemZ3iN 8CF+aRxHXBWIp2d36N2cUEaktXITiWwNMR0YRBKbfVbTZDSkxq57wrwP5YYJDelisR BlQmH7sepQh7YX44QE2UWqnxeGvnUxU5Rr60yMiW5jXnFZyqdXXbalcUQRQANNOXne yDM7DiOdh2Yt3HO3bNdKGN4ycPjdz1WwYcHQ6Hh55K5icyxtLFh2GdJJXulh3vpzj7 48d/CroDPNk7ejPPoarVVF0h9WV9T3pLTSVA2qT7Ls+Fz3G4JD+WKAWzloag4hAc9b 1ZHSlG+PMogjw== X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46009 Cc: "46009@debbugs.gnu.org" <46009@debbugs.gnu.org>, Christopher Baines , "guile-devel@gnu.org" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --_2FA69448-0431-492C-8A8C-6B8D9BCE68CB_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" > Also, I don=E2=80=99t 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 o= f control. >>It's icing on the cake that if the underlying ERROR were in fact a RAISE-= CONTINUABLE, then >it wouldn't even lead to a &NON-CONTINUABLE error in the= #:unwind? #f case, only to a >different return value (different flow of co= ntrol). =E2=80=98error=E2=80=99 is a procedure, not something that would be raise-c= ontinuable (I guess you could pass it to =E2=80=98raise-continuable=E2=80= =99, but seems rather unlikely). I propose replacing ERROR by condition (la= ck of quotes and capitals intentional, since I=E2=80=99m referring to the c= oncept here, not a Scheme object or macro and in particular not the macro = =E2=80=98condition=E2=80=99 from SRFI-35 Now I look at the output (somehow when I previously read it I thought it wa= s testing control flow with dynamic-wind, but it turns out it is testing se= mantics instead (without dynamic-wind) =E2=80=93 reading comprehension fail= ure on my part?), the observed behaviour (for v3.0.9) is indeed a significa= nt change. I don=E2=80=99t think test.scm is a good example though =E2=80=93 the outpu= t is, AFAICT, just a bug =E2=80=93 for the nested error, AFAICT neither of = the exception handlers receive the exception, which is plain nonsense. >>In my vocabulary, a different flow of control when using a control-flow p= rimitive is a >>fundamental change to its meaning. but your miliage may war= y of course. It=E2=80=99s not in mine. What matters to me is (denotational) semantics (i= n a broad sense, including things like complexity, whether something is con= stant-time (important for cryptography), etc.). Control-flow is more a oper= ational semantics thing. Often a convenient way of defining the semantics o= f control structures, but ultimately, if with a different control flow you = achieve the same semantics (and aren=E2=80=99t compiling with the equivalen= t of -Og), that=E2=80=99s fine too. >> If we are talking about reading comprehension, I would like to point >> out that (Guile) Scheme is case-sensitive. >for effective communication we need a syntax to designate when a word is t= o be > interpreted in the scheme/lisp domain (as opposed to plain english). usin= g all-caps > in english prose is a somewhat well-spread syntax for that, even in non-C= L lisp > contexts in my experience. A simple syntax is to use quotes, e.g. =E2=80=98call-with-current-continuat= ion=E2=80=99, which is well-spread (even outside programming to some degree= ), and does not require mangling the casing. Depending on the medium, there= are other options like monotype, putting a small box around it or coloring= . For texts (but not e-mail or terminal things), I recommend monotype (and = depending on capabilities of the writing software and aesthetic preferences= , maybe try out things like coloring and boxes). So =E2=80=A6 >> Someone coming from case-insensitive languages and someone > unfamiliar with the upcasing practice might get confused for a > moment. >for a moment. and that is key. =E2=80=A6 why not both eliminate the moment of confusion _and_ use a syntax= that avoids the ambiguity? >> >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. >>=20 > I don=E2=80=99t get the distinction. These are two sides of the same coin= ? > >not really, because there are two, orthogonal dimensions here: > >1) whether to unwind the stack, > >2) where to return the control flow when the handler returns. > >(even if one combination is impossible) Err, all four combinations are possible with sufficient application of deli= mited continuations. If you have unwinded you can just rewind (if you have = captured continuation things and accept the change in visible behaviour to = =E2=80=98dynamic-wind=E2=80=99, the first is not a given because of perform= ance consid=C3=A9rations and the latter isn=E2=80=99t a given because, well= , different behaviour). There are two components to (1): (1)(a): what does dynamic-wind see? (1)(b): how does unwinding affect the dynamic environment of the handler= . For (2): first, there is no =E2=80=98return the control flow=E2=80=99 happe= ning! The returning is all in tail position (albeit with some extra layers = in the dynamic environment, so don=E2=80=99t do tail loops with with-except= ion-handler or you will use lots of memory) =E2=80=93 according to the docs= , once the handler is invoked, with-exception-handler stops doing things. As mentioned in the documentation: > https://www.gnu.org/software/guile/manual/html_node/Raising-and-Handling-= Exceptions.html >Unless=C2=A0with-exception-handler=C2=A0was invoked with=C2=A0#:unwind? #t= , exception handlers are invoked __within the continuation of the error__, = without unwinding the stack. The dynamic environment of the handler call wi= ll be that of the=C2=A0raise-exception=C2=A0call, with the difference that = the current exception handler will be =E2=80=9Cunwound=E2=80=9D to the \"ou= ter\" handler (the one that was in place when the corresponding=C2=A0with-e= xception-handler=C2=A0was called). > [=E2=80=A6] >=C2=A0if=C2=A0with-exception-handler=C2=A0was invoked with=C2=A0#:unwind? = #t=C2=A0is true,=C2=A0raise-exception=C2=A0will first unwind the stack by i= nvoking an=C2=A0escape continuation=C2=A0(see=C2=A0call/ec), and then invok= e the handler __with the continuation of the=C2=A0with-exception-handler=C2= =A0call__. (emphasis added with __) Now, while =E2=80=98return the control flow=E2=80=99 is not accurate, there= is definitely some control flow manipulation going on (see: =E2=80=98call/= ec=E2=80=99). But consider this: whether you are in tail-position w.r.t. so= mething, is a property of the dynamic environment! I mean, it definitely is= visible in backtraces (which you can make with =E2=80=98(backtrace)=E2=80= =99, doesn=E2=80=99t need exceptions). Let=E2=80=99s look at some R6RS definitions=C2=A0: >For a procedure call, the time between when it is initiated and when it re= turns is called its dynamic extent. [currently irrelevant things about call= /cc] >Some operations described in the report acquire information in addition to= their explicit arguments from the dynamic environment. (Technically it doesn=E2=80=99t state that the concept of =E2=80=98dynamic = environment=E2=80=99 includes the =E2=80=98dynamic extent=E2=80=99, but it = seems quite natural to consider all the dynamicness together, and =E2=80=98= environment=E2=80=99 seems a sufficiently generic word to also include the = =E2=80=98extent=E2=80=99.) (dynamic extent <-> a region of stack, without focus on what the dynamic bi= ndings in that stack are, dynamic environment <-> the full stack upto a poi= nt, with a focus at what=E2=80=99s visible at the point] Summarised: stack stuff is part of the dynamic environment, control flow is= stack stuff, so control flow is dynamic environment stuff. >> >for reference, in CL they are called HANDLER-CASE and HANDLER-BIND, wit= h >completely different syntaxes. >> >> Can=E2=80=99t honestly say I like those names (those suffixes -CASE / -B= IND >> don=E2=80=99t really provide information, you have to go into the spec o= f >> HANDLER-CASE / HANDLER-BIND itself to get the differences). >my point is not whether it's deducible, or whether the names are good. my = point is that one API is misleading (i.e. wastes human time), while the oth= er forces the reader to, at worst, look up the documentation. but certainly= not conflate the two, thinking that they are doing the same thing -- plus = some implementation detail regarding unwinding that he can postpone learnin= g about. It wasn=E2=80=99t my point either, I didn=E2=80=99t think you liked them ei= ther, I didn=E2=80=99t think your point was whether it=E2=80=99s deducible,= I just interpreted it as an example of splitting stuff up and wanted to ma= ke clear those don=E2=80=99t seem good names. >here's a caricature of this situation: > >imagine a hypothetical (raise [a potentially larger sexp] #:enabled? #t/#f= ) control flow primitive that simply returns when #:enabled? is #f. > >one can argue that "well, it's disabled, dummy!" (turing tarpit), or try t= o walk in the shoes of the reader or a newcomer. > >yes, you're right when you say something is possible, or deducible. but no= , with all due respect, you're wrong when you imply that it doesn't make a = difference (in human-brain efficiency). With all due respect, that=E2=80=99s a strawman (as expected by a caricatur= e). I never claimed #:unwind? is a great name, that keyword #:enabled? is terri= bly named and even worse than #:disable, both you and I previously made cle= ar that naming is important, I proposed renamings of #:unwind? to other thi= ngs (that you even agreed to were better) or proposals for names for splitt= ing up the procedure (not great names, but still more descriptive than #:en= abled? Of all things). Also, let=E2=80=99s do this walking into the shoes of the newcomer. As a ne= wcomer, one of the things I do is _reading the documentation_ (I have heard= this is a rare thing, but I actually do this, and did this). As a newcomer, I find these references to delimited continuations, dynamic = environment and tail call thingies, really interesting and cool, so I read = a lot about it (more than I actually use them, even!) and try it out a bit.= I also see these mentions of virtual machines and stack frames. I read tho= se too of course, how stack frames are done is really cool and interesting = (VM a bit less so, but still ok to skim through). As a reader, I also think that sometimes the descriptions aren=E2=80=99t do= ne well =E2=80=93 it=E2=80=99s not a verbosity thing despite what some woul= d say, but more a structure thing (both local or global). But that=E2=80=99= s a property of the documentation, not the API. I also thing that occassionally the APIs aren=E2=80=99t quite right, making= it difficult to understand when to, say, use #:unwind? #false/#true. But a= s a newcomer, I don=E2=80=99t _need_ to know those distinctions, I can just= assume the default is fine and avoid doing fancy dynamic environment stuff= inside the exception handler. So, I can just avoid the complicated unwindi= ng-or-not stuff until I=E2=80=99m not a newcomer anymore, and once that=E2= =80=99s the case, I can start thinking about how to improve API stuff and u= tilise the fancy stuff. Going back to the strawman: > you're wrong when you imply that it doesn't make a difference (in human-b= rain efficiency). I didn=E2=80=99t imply this! Just because I said you need to _read the docu= mentation_ doesn=E2=80=99t mean that naming and the like can=E2=80=99t be i= mproved, the existence of a =E2=80=98problem between monitor and chair=E2= =80=99 does not exclude the existence of a problem in the software as well.= Also that the status quo is ok doesn=E2=80=99t mean it can=E2=80=99t be be= improved. (I think the _name_ itself is fine, rather, I think that the _concept_ that= it represents would preferably be changed to something different (and natu= rally this change in concept induces a change in name and perhaps semantics= as well).) >> Maybe you can install a breakpoint on >> scm_c_with_continuation_barrier or something > >it assumes that it's already known that the curlpit is w-c-b, but that was= already well >into the debugging effort. see my attached patch that intend= s to greatly shorten the >debugging time for anyone else walking down this = path after me. > >and it's been decades i've done any serious C coding, and i'm not looking = forward to >learning the ins and outs of gdb when i'm debugging an issue in= scheme. Of course it assumes that the culprit is =E2=80=98with-continuation-barrier= =E2=80=99. You provided the information that =E2=80=98with-continuation-bar= rier=E2=80=99 might have something to do with the issue to me. Also, I didn= =E2=80=99t mention gdb anywhere. It=E2=80=99s a common debugger, but not th= e only one. And neither did I mention learning the ins and outs =E2=80=93 s= etting up a breakpoint and asking gdb to print a backtrace is hardly =E2=80= =98the ins and outs=E2=80=99. (Whether the information of the backtrace wil= l prove useful is another matter.) Also, difficulty with C debugging is your problem, not mine =E2=80=93 this = thread isn=E2=80=99t named =E2=80=9Chow to simplify debugging from C=E2=80= =9D, as a volunteer I=E2=80=99m just mentioning some options to consider an= d I=E2=80=99m not your boss. Besides, given that the existence of FFI and t= he like, and that Guile it partially implemented in C instead of Scheme, it= isn=E2=80=99t a given that the issue you are debugging is, in fact, fully = in Scheme. (Also maybe look if Shepherd is doing REPL stuff. The REPL implementation i= n Guile installs (in Scheme!) a continuation barrier.) > I don=E2=80=99t think Shepherd has much use of with-continuation-barrier. > > IIUC, any time the posix thread enters C code is an implicit continuation= barrier. if a > fiber in shepherd uses any primitive in guile that is implemented in C, t= hen it's a > continuation barrier (and breaks when an attempt is made to suspend that = fiber). Not in the sense of with-continuation-barrier. C code can throw Scheme exce= ptions and those exception can in turn be caught by normal Scheme exception= (but no raise-continuable stuff from C). On a related note, there is also some (non-Scheme) dynwind-rewind stuff in = Guile=E2=80=99s C code. I don=E2=80=99t have a clue on how that works and i= f it even works at all. > changing shepherd not to unconditionally unwind (so that meaningful backt= races > can be logged) can lead to subtle issues due to now having some extra C f= rames on > the stack that were previously unwound prior to handling the error. That=E2=80=99s not unwinding, that=E2=80=99s rewinding. Unwinding can=E2=80= =99t lead to leaving extra C frames on the stack, because removing those C = frames is part of the unwinding process and C frames are only generated by = C code. (Except perhaps for that dynwind-rewind stuff, but if it does that= stuff, presumably it is prepared to deal with rewinding.) Hypothetically a Scheme implementation could put C frames back onto the sta= ck, but Guile doesn=E2=80=99t do this =E2=80=93 whenever this would happen,= it simply refuses(*). (IIRC it does so by throwing an exception.). From th= e documentation: (*) besides perhaps that dynwind-rewind stuff. >Scheme Procedure: suspendable-continuation? tag >Return #t if a call to abort-to-prompt with the prompt tag tag would produ= ce a >delimited continuation that could be resumed later. > >Almost all continuations have this property. The exception is where some c= ode between the call-with-prompt and the abort-to-prompt recursed through C= for some reason, the abort-to-prompt will succeed but any attempt to resum= e the continuation (by calling it) would fail. This is because composing a = saved continuation with the current continuation involves relocating the st= ack frames that were saved from the old stack onto a (possibly) new positio= n on the new stack, and Guile can only do this for stack frames that it cre= ated for Scheme code, not stack frames created by the C compiler. It=E2=80= =99s a bit gnarly but if you stick with Scheme, you won=E2=80=99t have any = problem. > >If no prompt is found with the given tag, this procedure just returns #f. Best regards, Maxime Devos. --_2FA69448-0431-492C-8A8C-6B8D9BCE68CB_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

= > Also, I don=E2=80=99t see a fundamental change in m= eaning

>>= ;just look at my test.scm:

 

>>without the explicit (let/ec return ...) wrapper, and the exp= licit use of (return ...) in the handlers, the two invocations lead to diff= erent flow of control.

>>It's icing on the cake that if the underlying ERROR were i= n fact a RAISE-CONTINUABLE, then >it wouldn't even lead to a &NON-CO= NTINUABLE error in the #:unwind? #f case, only to a >different return va= lue (different flow of control).

=  

=E2=80=98error=E2=80=99 is a procedure, not something that woul= d be raise-continuable (I guess you could pass it to =E2=80=98raise-continu= able=E2=80=99, but seems rather unlikely). I propose replacing ERROR by con= dition (lack of quotes and capitals intentional, since I=E2=80=99m referrin= g to the concept here, not a Scheme object or macro and in particular not t= he macro =E2=80=98condition=E2=80=99 from SRFI-35

 

Now I look at the output (somehow when I previ= ously read it I thought it was testing control flow with dynamic-wind, but = it turns out it is testing semantics instead (without dynamic-wind) =E2=80= =93 reading comprehension failure on my part?), the observed behaviour (for= v3.0.9) is indeed a significant change.

 

I don=E2=80=99t think test.scm is a good example though= =E2=80=93 the output is, AFAICT, just a bug =E2=80=93 for the nested error= , AFAICT neither of the exception handlers receive the exception, which is = plain nonsense.

 

>&= gt;In my vocabulary, a different flow of control when using a control-flow = primitive is a >>fundamental change to its meaning. but your miliage = may wary of course.

 

I= t=E2=80=99s not in mine. What matters to me is (denotational) semantics (in= a broad sense, including things like complexity, whether something is cons= tant-time (important for cryptography), etc.). Control-flow is more a opera= tional semantics thing. Often a convenient way of defining the semantics of= control structures, but ultimately, if with a different control flow you a= chieve the same semantics (and aren=E2=80=99t compiling with the equivalent= of -Og), that=E2=80=99s fine too.

 

>> If we are talking about reading comprehension, I wou= ld like to point

>> out that (Guile) Scheme is case-sensitive.

>for effective communication we= need a syntax to designate when a word is to be

> interpreted in the scheme/lisp doma= in (as opposed to plain english). using all-caps

> in english prose is a somewhat well= -spread syntax for that, even in non-CL lisp

> contexts in my experience.<= /span>

 <= /p>

A simple syntax is to use quotes= , e.g. =E2=80=98call-with-current-continuation=E2=80=99, which is well-spre= ad (even outside programming to some degree), and does not require mangling= the casing. Depending on the medium, there are other options like monotype= , putting a small box around it or coloring. For texts (but not e-mail or t= erminal things), I recommend monotype (and depending on capabilities of the= writing software and aesthetic preferences, maybe try out things like colo= ring and boxes).

 

So = =E2=80=A6

 

>= > Someone coming from case-insensitive languages and someone<= /p>

> unfamiliar with the upcasing practice might ge= t confused for a

> moment.=

>for a moment. and that is key.

<= p class=3DMsoNormal> 

=E2=80=A6 why not both eliminate the moment= of confusion _and_ use a syntax that avoids the ambiguity?

 

>> >that would be be= tter, but i still wouldn't like the fact that it's

>> >focusing on the dynamic c= ontext of the handler, instead of the

>> >different flow of control.<= /span>

>>

> I don=E2=80=99t get the = distinction. These are two sides of the same coin?

> 

>not really, because there are two, or= thogonal dimensions here:

> 

>1) whether to unwind the stack,

> 

>2) where to return the control flow when t= he handler returns.

> 

>(even if one combination is impossible)

 

Err, all four combinations are possible with suff= icient application of delimited continuations. If you have unwinded you can= just rewind (if you have captured continuation things and accept the chang= e in visible behaviour to =E2=80=98dynamic-wind=E2=80=99, the first is not = a given because of performance consid=C3=A9rations and the latter isn=E2=80= =99t a given because, well, different behaviour).

 

There are two components to (1):

 

=C2=A0=C2=A0 (1)(a): what does dyn= amic-wind see?

=C2=A0=C2=A0 (1)(b): how does unwinding affect the dynamic environment of = the handler.

<= o:p> 

For (2):= first, there is no =E2=80=98return the control flow=E2=80=99 happening! Th= e returning is all in tail position (albeit with some extra layers in the d= ynamic environment, so don=E2=80=99t do tail loops with with-exception-hand= ler or you will use lots of memory) =E2=80=93 according to the docs, once t= he handler is invoked, with-exception-handler stops doing things.

 

As mentioned in the documentat= ion:

&nbs= p;

> https://www.gnu.org/software/guile/manual/html_node/Raising-= and-Handling-Exceptions.html

= >Unless with-excep= tion-handler was inv= oked with #:unwind? #t, exception handlers are invoked __within the continuation o= f the error__, without unwinding the stack. The dynamic environment of the = handler call will be that of the raise-exception call, with the difference th= at the current exception handler will be =E2=80=9Cunwound=E2=80=9D to the \= "outer\" handler (the one that was in place when the correspondin= g with-exception-handler was called).

> [=E2=80=A6]=

> if with-exception-handler was invoked with = ;#:unwind? #t is true, raise-exception will first unwind the stack by invoking an&= nbsp;escape continuation (see = call/ec), and then invoke the handler __with the continuation= of the with-exception-handler call__.

 

(emphasis added with __)

 

Now, while =E2=80=98return th= e control flow=E2=80=99 is not accurate, there is definitely some control f= low manipulation going on (see: =E2=80=98call/ec=E2=80=99). But consider th= is: whether you are in tail-position w.r.t. something, is a property of the= dynamic environment! I mean, it definitely is visible in backtraces (which= you can make with =E2=80=98(backtrace)=E2=80=99, doesn=E2=80=99t need exce= ptions).

=  

Let=E2=80=99= s look at some R6RS definitions :

 

<= span lang=3DFR-BE>>For a procedure call, the time between when it is ini= tiated and when it returns is called its dynamic extent. [currently irrelev= ant things about call/cc]

>Some operations described in the report acquire information= in addition to their explicit arguments from the dynamic environment.=

 <= /span>

(Technically it doesn=E2= =80=99t state that the concept of =E2=80=98dynamic environment=E2=80=99 inc= ludes the =E2=80=98dynamic extent=E2=80=99, but it seems quite natural to c= onsider all the dynamicness together, and =E2=80=98environment=E2=80=99 see= ms a sufficiently generic word to also include the =E2=80=98extent=E2=80=99= .)

 =

(dynamic extent &l= t;-> a region of stack, without focus on what the dynamic bindings in th= at stack are, dynamic environment <-> the full stack upto a point, wi= th a focus at what=E2=80=99s visible at the point]

 

Summarised: stack stuff is part of the dyna= mic environment, control flow is stack stuff, so control flow is dynamic en= vironment stuff.

 

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

>> 

>> Can=E2=80=99t honestly say I like tho= se 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 d= ifferences).

<= o:p> 

>my p= oint is not whether it's deducible, or whether the names are good. my point= is that one API is misleading (i.e. wastes human time), while the other fo= rces the reader to, at worst, look up the documentation. but certainly not = conflate the two, thinking that they are doing the same thing -- plus some = implementation detail regarding unwinding that he can postpone learning abo= ut.

 = ;

It wasn=E2=80=99t= my point either, I didn=E2=80=99t think you liked them either, I didn=E2= =80=99t think your point was whether it=E2=80=99s deducible, I just interpr= eted it as an example of splitting stuff up and wanted to make clear those = don=E2=80=99t seem good names.

 

>here's a caricature of this situation:

<= p class=3DMsoNormal>> 

>imagine a hypothetical (raise [a po= tentially larger sexp] #:enabled? #t/#f) control flow primitive that simply= returns when #:enabled? is #f.

<= span lang=3DFR-BE>> 

>one can argue that "well, it's disabled, dummy!&quo= t; (turing tarpit), or try to walk in the shoes of the reader or a newcomer= .

>&nb= sp;

>yes, you're= right when you say something is possible, or deducible. but no, with all d= ue respect, you're wrong when you imply that it doesn't make a difference (= in human-brain efficiency).

 

With all due respect, that=E2=80=99s a strawman (as expected by a = caricature).

<= o:p> 

I never = claimed #:unwind? is a great name, that keyword #:enabled? is terribly name= d and even worse than #:disable, both you and I previously made clear that = naming is important, I proposed renamings of #:unwind? to other things (tha= t you even agreed to were better) or proposals for names for splitting up t= he procedure (not great names, but still more descriptive than #:enabled? O= f all things).

 

Also, = let=E2=80=99s do this walking into the shoes of the newcomer. As a newcomer= , one of the things I do is _reading the documentation_ (I have hear= d this is a rare thing, but I actually do this, and did this).

 

As a newcomer, I find these refer= ences to delimited continuations, dynamic environment and tail call thingie= s, really interesting and cool, so I read a lot about it (more than I actua= lly use them, even!) and try it out a bit. I also see these mentions of vir= tual machines and stack frames. I read those too of course, how stack frame= s are done is really cool and interesting (VM a bit less so, but still ok t= o skim through).

 

As a= reader, I also think that sometimes the descriptions aren=E2=80=99t done w= ell =E2=80=93 it=E2=80=99s not a verbosity thing despite what some would sa= y, but more a structure thing (both local or global). But that=E2=80=99s a = property of the documentation, not the API.

 

I also thing that occassionally the APIs aren=E2= =80=99t quite right, making it difficult to understand when to, say, use #:= unwind? #false/#true. But as a newcomer, I don=E2=80=99t _need_ to k= now those distinctions, I can just assume the default is fine and avoid doi= ng fancy dynamic environment stuff inside the exception handler. So, I can = just avoid the complicated unwinding-or-not stuff until I=E2=80=99m not a n= ewcomer anymore, and once that=E2=80=99s the case, I can start thinking abo= ut how to improve API stuff and utilise the fancy stuff.<= /p>

 

Going back to the strawman:<= /span>

 <= /p>

> you're wrong when you imply= that it doesn't make a difference (in human-brain efficiency).<= /span>

 <= /p>

I didn=E2=80=99t imply this! Jus= t because I said you need to _read the documentation_ doesn=E2=80=99= t mean that naming and the like can=E2=80=99t be improved, the existence of= a =E2=80=98problem between monitor and chair=E2=80=99 does not exclude the= existence of a problem in the software as well. Also that the status quo i= s ok doesn=E2=80=99t mean it can=E2=80=99t be be improved.

 

(I think the _name_ itself is = fine, rather, I think that the _concept_ that it represents would pr= eferably be changed to something different (and naturally this change in co= ncept induces a change in name and perhaps semantics as well).)<= /span>

 <= /p>

>> Maybe you can install a= breakpoint on

>> scm_c_with_continuation_barrier or something

> 

>it assumes that it's already know= n that the curlpit is w-c-b, but that was already well >into the debuggi= ng effort. see my attached patch that intends to greatly shorten the >de= bugging time for anyone else walking down this path after me.

> 

>and it's been decades i've= done any serious C coding, and i'm not looking forward to >learning the= ins and outs of gdb when i'm debugging an issue in scheme.

 

<= p class=3DMsoNormal>Of course it assumes that the culpri= t is =E2=80=98with-continuation-barrier=E2=80=99. You provided the informat= ion that =E2=80=98with-continuation-barrier=E2=80=99 might have something t= o do with the issue to me. Also, I didn=E2=80=99t mention gdb anywhere. It= =E2=80=99s a common debugger, but not the only one. And neither did I menti= on learning the ins and outs =E2=80=93 setting up a breakpoint and asking g= db to print a backtrace is hardly =E2=80=98the ins and outs=E2=80=99. (Whet= her the information of the backtrace will prove useful is another matter.)<= o:p>

 

Also, difficulty with= C debugging is your problem, not mine =E2=80=93 this thread isn=E2=80=99t = named =E2=80=9Chow to simplify debugging from C=E2=80=9D, as a volunteer I= =E2=80=99m just mentioning some options to consider and I=E2=80=99m not you= r boss. Besides, given that the existence of FFI and the like, and that Gui= le it partially implemented in C instead of Scheme, it isn=E2=80=99t a give= n that the issue you are debugging is, in fact, fully in Scheme.=

 =

(Also maybe look if Shepherd is= doing REPL stuff. The REPL implementation in Guile installs (in Scheme!) a= continuation barrier.)

 

> I don=E2=80=99t think Shepherd has much use of with-continuation-ba= rrier.

> 

> IIUC,= any time the posix thread enters C code is an implicit continuation barrie= r. if a

> f= iber in shepherd uses any primitive in guile that is implemented in C, then= it's a

> c= ontinuation barrier (and breaks when an attempt is made to suspend that fib= er).

&nbs= p;

Not in the sense= of with-continuation-barrier. C code can throw Scheme exceptions and those= exception can in turn be caught by normal Scheme exception (but no raise-c= ontinuable stuff from C).

 

On a related note, there is also some (non-Scheme) dynwind-rewind stuf= f in Guile=E2=80=99s C code. I don=E2=80=99t have a clue on how that works = and if it even works at all.

 

> changing shepherd not to unconditionally unwind (so that mean= ingful backtraces

> can be logged) can lead to subtle issues due to now having some ex= tra C frames on

> the stack that were previously unwound prior to handling the error.<= o:p>

 

That=E2=80=99s not un= winding, that=E2=80=99s rewinding. Unwinding can=E2=80=99t lead to leaving = extra C frames on the stack, because removing those C frames is part of the= unwinding process and C frames are only generated by C code.=C2=A0 (Except= perhaps for that dynwind-rewind stuff, but if it does that stuff, presumab= ly it is prepared to deal with rewinding.)

 

Hypothetically a Scheme implementation could put C fr= ames back onto the stack, but Guile doesn=E2=80=99t do this =E2=80=93 whene= ver this would happen, it simply refuses(*). (IIRC it does so by throwing a= n exception.). From the documentation:

 

<= span lang=3Den-BE>(*) besides perhaps that dynwind-rewind stuff.=

 =

>Scheme Procedure: suspendab= le-continuation? tag

>Return #t if a call to abort-to-prompt with the prompt tag tag= would produce a >delimited continuation that could be resumed later.

> <= /o:p>

>Almost all cont= inuations have this property. The exception is where some code between the = call-with-prompt and the abort-to-prompt recursed through C for some reason= , the abort-to-prompt will succeed but any attempt to resume the continuati= on (by calling it) would fail. This is because composing a saved continuati= on with the current continuation involves relocating the stack frames that = were saved from the old stack onto a (possibly) new position on the new sta= ck, and Guile can only do this for stack frames that it created for Scheme = code, not stack frames created by the C compiler. It=E2=80=99s a bit gnarly= but if you stick with Scheme, you won=E2=80=99t have any problem.

> <= /span>

>If no prompt is found= with the given tag, this procedure just returns #f.

<= p class=3DMsoNormal> 

Best regards,

Maxime Devos.

= --_2FA69448-0431-492C-8A8C-6B8D9BCE68CB_--