From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Ludovic_Court=C3=A8s?= Newsgroups: gmane.lisp.guile.devel Subject: Re: guile 3 update, halloween edition Date: Sat, 16 Nov 2019 16:26:30 +0100 Message-ID: <87bltbyh95.fsf@gnu.org> References: <87o8xyhtz6.fsf@pobox.com> <87sgmp1pfu.fsf@gnu.org> <87zhgxmo9d.fsf@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="225337"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cc: Guile Devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Nov 16 16:27:06 2019 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iVzyb-000wOE-7I for guile-devel@m.gmane.org; Sat, 16 Nov 2019 16:27:05 +0100 Original-Received: from localhost ([::1]:48628 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iVzyU-0007lL-UG for guile-devel@m.gmane.org; Sat, 16 Nov 2019 10:26:58 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52513) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iVzy8-0007jx-EU for guile-devel@gnu.org; Sat, 16 Nov 2019 10:26:37 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:50435) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iVzy7-0006I7-7E; Sat, 16 Nov 2019 10:26:35 -0500 Original-Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=46772 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iVzy5-0000OO-F1; Sat, 16 Nov 2019 10:26:33 -0500 X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 26 Brumaire an 228 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu In-Reply-To: <87zhgxmo9d.fsf@pobox.com> (Andy Wingo's message of "Fri, 15 Nov 2019 11:23:42 +0100") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:20147 Archived-At: Hi Andy! Andy Wingo skribis: > On Fri 15 Nov 2019 10:03, Ludovic Court=C3=A8s writes: > >> 0. Do I get it right that =E2=80=98throw=E2=80=99 and =E2=80=98catch=E2= =80=99 are not =E2=80=9Cdeprecated=E2=80=9D in >> the sense of (ice-9 deprecated) and are instead simply not the >> =E2=80=9Cpreferred=E2=80=9D exception mechanism? > > Correct. I think we could envision deprecating them in some future but > not within the next couple years at least. Alright, sounds good. >> I guess we could add a specific =E2=80=98&type-exception=E2=80=99 except= ion or similar, >> which would allow us to improve error reporting (that can come later, of >> course.) What I meant is that type errors are =E2=80=9Cspecial=E2=80=9D enough to de= serve their own type more specific than the catch-all =E2=80=98&assertion-failure=E2=80= =99 (just like there=E2=80=99s already a separate =E2=80=98&undefined-variable=E2=80= =99, for instance.) > Yes. So right now Guile is in a bit of a transitional state -- it still > signals 99.9% of errors via `throw'. Probably we want to change to have > structured exceptions for almost all of these. To preserve > compatibility we would probably need to mix in an > &exception-with-kind-and-args to all of these exceptions, or otherwise > augment `exception-kind' and `exception-args' to synthesize these values > when appropriate. Yes, I agree. Speaking of which, it seems that =E2=80=98set-guile-exception-converter!=E2= =80=99 is currently private, but I wonder if the goal was to make it public (it seems to be unused)? If it were public, I imagine that users could take advantage of it to support both exception styles, just like Guile does. For instance, C bindings that currently call =E2=80=98throw=E2=80=99 could provide addition= al =E2=80=9Cexception converters=E2=80=9D for the benefit of Scheme users who=E2=80=99d rather us= e structured exceptions. (That would also give less of an incentive to provide a C API for all of this.) WDYT? >> Guix has =E2=80=98&location=E2=80=99 error conditions, which I=E2=80=99v= e found useful when >> combined with other error conditions in cases where location info from >> the stack isn=E2=80=99t useful: >> >> https://git.savannah.gnu.org/cgit/guix.git/tree/guix/utils.scm#n832 >> >> I wonder if (ice-9 exceptions) should provide something like that. > > Neat :) Yes sure. I think, any exception type can be added to (ice-9 > exceptions) -- there's little "name cost" like there is in boot-9. > Which reminds me, I want to make boot-9 do a (resolve-module '(ice-9 > exceptions)) so that the more capable make-exception-from-throw always > gets installed. > >> 2. What are you thoughts regarding exposing structured exceptions to C? >> I=E2=80=99ve always been frustrated by =E2=80=98system-error=E2=80=99 :-= ). Guix has a hack to >> augment =E2=80=98system-error=E2=80=99 with information about the offend= ing file name: >> >> https://git.savannah.gnu.org/cgit/guix.git/tree/guix/ui.scm#n520 >> >> If the POSIX bindings would emit a structured =E2=80=98&system-error=E2= =80=99 record, >> that=E2=80=99d be pretty cool. > > I don't know :) Right now raise-exception is marked SCM_INTERNAL. > Probably it should be public. There is no public C API for any of this > new functionality, as it stands; a TODO. > > Regarding exception objects, there are two questions: one, how to create > exceptions of specific kinds; I suspect scm_make_system_error () would > be fine, and probably you want scm_make_exception to be able to mix > various exceptions. Second question, do we want to expose accessors > too? It can be a lot of API surface and I am a bit wary of it. But, > perhaps it is the right thing. I do not know. Yeah, it might be that having C stick to =E2=80=98throw=E2=80=99 + allowing= for user-defined exception converters would be enough. >> 4. Is =E2=80=98&warning=E2=80=99 actually used? Is the goal to make it = continuable? >> That sounds great. > > Any exception can be raised in a continuable way. Whether a raise is > continuable or not depends on the value of the #:continuable? keyword to > raise-exception. I think that's the intention of &warning but I don't > really have instincts about how it might be used. Guile defines it > because it's in R6RS, but how it will be used is an open question :) I suppose the intent is to effectively allow users to implement the UI stuff as a sort of co-routine to support separation of concerns: you just raise a =E2=80=98&warning=E2=80=99 that some other code displays in it= s preferred way (console message, popup window, whatever) and eventually calls your continuation. That=E2=80=99s something I=E2=80=99ve been wanting for some time, because r= ight now we=E2=80=99re able to separate out the UI concern for exception display, bu= t not for warnings. However, it seems that the handler passed to =E2=80=98with-exception-handle= r=E2=80=99 does not receive the continuation, so is it the case that currently handlers cannot resume exceptions? (Again not a showstopper IMO but rather another wishlist item :-)). Thank you! Ludo=E2=80=99.