From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: guile 3 update, halloween edition Date: Sun, 17 Nov 2019 20:33:32 +0100 Message-ID: <87wobyl2lv.fsf@pobox.com> References: <87o8xyhtz6.fsf@pobox.com> <87sgmp1pfu.fsf@gnu.org> <87zhgxmo9d.fsf@pobox.com> <87bltbyh95.fsf@gnu.org> 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="13927"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) Cc: Guile Devel To: Ludovic =?utf-8?Q?Court=C3=A8s?= Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Nov 17 20:34:42 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 1iWQJm-0003Ud-GT for guile-devel@m.gmane.org; Sun, 17 Nov 2019 20:34:42 +0100 Original-Received: from localhost ([::1]:55960 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iWQJk-0002Pq-Mw for guile-devel@m.gmane.org; Sun, 17 Nov 2019 14:34:40 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54372) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iWQJ4-0002Pk-P9 for guile-devel@gnu.org; Sun, 17 Nov 2019 14:34:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iWQJ3-0006jk-En for guile-devel@gnu.org; Sun, 17 Nov 2019 14:33:58 -0500 Original-Received: from fanzine.igalia.com ([178.60.130.6]:36745) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iWQJ2-0006dK-TT; Sun, 17 Nov 2019 14:33:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=lUDmRUNNsbdjGO3JeT1khn9marC1sbmPYbJnqw+WOBQ=; b=P4mDPgmPfqn+eLcWNskIKev0UvkeiLYjMrnkENdyOmKAvf9LdOl9tWiqypPEmuhp8Sl4dEcwZz46YV6kcE0EVzoYKiNYVUOfM3ZeCfD25CCpY8R00/B1EttdI1llhETqBAi/gVLdQFCCAGXtyOLZvziHSxwrA9kOPgDThMmRr2CNzU/G/2yYiWfQs/jqrUAgaxWLMyMD9c74RE5bcfvjM6Wklf2SDdftdwgvbYiIS8K+lVVfcXcfpdzHzJfUxoOx1+dsHkTQctzE6o5sgCLRj9Ixo8Q+0vJvL3KwMp7yPfJ6nNuZPUphLFlRWMhTKochXOR/pzJ2qmK4oATMJDjedg==; Original-Received: from cha74-2-88-160-189-213.fbx.proxad.net ([88.160.189.213] helo=sparrow) by fanzine.igalia.com with esmtpsa (Cipher TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim) id 1iWQIx-0002yh-VW; Sun, 17 Nov 2019 20:33:52 +0100 In-Reply-To: <87bltbyh95.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Sat, 16 Nov 2019 16:26:30 +0100") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] [fuzzy] X-Received-From: 178.60.130.6 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:20152 Archived-At: Hi :) On Sat 16 Nov 2019 16:26, Ludovic Court=C3=A8s writes: > Andy Wingo skribis: > >> On Fri 15 Nov 2019 10:03, Ludovic Court=C3=A8s writes: >> >>> I guess we could add a specific =E2=80=98&type-exception=E2=80=99 excep= tion 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 = deserve 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.) Agreed! > 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)? It was private also in the exception conversion work that Mark did, FWIW; it just moved over as-is. Honestly I think that now that exceptions are "primary" we should probably move in the opposite direction: instead of adding more converters from key+args to exception objects, we should encourage exception throwers to switch from "throw" to "raise-exception", and allow library authors to define converters in the other way from exception object to the equivalent arguments for "catch". So I think exposing set-guile-exception-converter! might be the wrong thing at this point. Dunno tho. > For instance, C bindings that currently call =E2=80=98throw=E2=80=99 coul= d provide > additional =E2=80=9Cexception converters=E2=80=9D for the benefit of Sche= me users > who=E2=80=99d rather use structured exceptions. (That would also give le= ss of > an incentive to provide a C API for all of this.) This is a good point! FWIW Regarding C and migration, I have the impression that probably 90% of exception throwers in C use the helpers from error.h (scm_wrong_num_args and so on), which we can change transparently. A remaining 5% might use scm_error_scm, for which a registry might make sense, and 5% use scm_throw directly. These are just guesses tho. >>> 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 = its 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= right now > we=E2=80=99re able to separate out the UI concern for exception display, = but not > for warnings. > > However, it seems that the handler passed to =E2=80=98with-exception-hand= ler=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 :-)). The handler runs within the continuation of "raise-continuable": (with-exception-handler (lambda (exn) (+ exn 30)) (lambda () (+ 2 (raise-exception 10 #:continuable? #t)))) =3D> 42 However I'm not sure this facility is what you want. Like for example there's lots of false-if-exception / catch #t out there; that's equivalent to: (define-syntax-rule (false-if-exception expr) (let/ec k (with-exception-handler (lambda (exn) (k #f)) (lambda () expr)))) So the exception handler there would intervene and get a first crack at the warning, messing up your intent. To me warnings are like logging, and logging is notoriously difficult to standardize :) If it were me I would make a mechanism for warnings that had a with-warning-handler and I would make sure to raise all warnings via a separate raise-warning procedure or something, independent of exceptions. But that's just me :) Andy