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: Fri, 15 Nov 2019 11:23:42 +0100 Message-ID: <87zhgxmo9d.fsf@pobox.com> References: <87o8xyhtz6.fsf@pobox.com> <87sgmp1pfu.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="137935"; 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 Fri Nov 15 11:24:16 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 1iVYlz-000ZjC-Hg for guile-devel@m.gmane.org; Fri, 15 Nov 2019 11:24:15 +0100 Original-Received: from localhost ([::1]:37422 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iVYly-0004cJ-DW for guile-devel@m.gmane.org; Fri, 15 Nov 2019 05:24:14 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57335) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iVYls-0004ZF-Jv for guile-devel@gnu.org; Fri, 15 Nov 2019 05:24:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iVYlq-00030x-Vg for guile-devel@gnu.org; Fri, 15 Nov 2019 05:24:08 -0500 Original-Received: from fanzine.igalia.com ([178.60.130.6]:54541) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iVYlq-0002yN-AN; Fri, 15 Nov 2019 05:24:06 -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=IRJyI6oO6n8M6hFc+jhCpl2gLnu6oG0jQ9kc2Rxxx6Q=; b=RGPqEvV+1wjjln6KGccYk00a487jiNQTz9Iu/yeesivzXEJN3V26HXy0YD6U2E5khMsRSt6wgnKubYIfsIRB+Nd9X2IyTBuEDWma3zQPizf+SRadFNJCGsOEAuhCN/lhMaVxdtWhTbLZBv6n/xLwxqZwzQwBFatL1S6EVQF8xBOxLNqVvVDGOzRDtahtZ0++FFKf9wo8qf/ZL67fvZbJeXTTJMB3MlzEFLmEPea6vwifD+sYY53bA3BcNl0ECSZFJ275Y9RmIvkczpalaZKsp6vIiXhe+9pjcuR0A5YYNWG2V9fKh5q4bTS5tg+7L2NG/pVH1lvq5D55TquGLEIE6A==; 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 1iVYlm-00068d-5i; Fri, 15 Nov 2019 11:24:02 +0100 In-Reply-To: <87sgmp1pfu.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Fri, 15 Nov 2019 10:03:49 +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:20146 Archived-At: Hey thanks for the review :) 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. > 1. I see things like: > > +(define (make-condition type . field+value) > + "Return a new condition of type TYPE with fields initialized as specif= ied > +by FIELD+VALUE, a sequence of field names (symbols) and values." > + (unless (exception-type? type) > + (scm-error 'wrong-type-arg "make-condition" "Not a condition type: ~= S" > + (list type) #f)) > > and: > > + (unless (symbol? key) > + (throw 'wrong-type-arg "throw" "Wrong type argument in position = ~a: ~a" > + (list 1 key) (list key))) > > I guess we could add a specific =E2=80=98&type-exception=E2=80=99 excepti= on or similar, > which would allow us to improve error reporting (that can come later, of > course.) 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. > Guix has =E2=80=98&location=E2=80=99 error conditions, which I=E2=80=99ve= 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 offendi= ng 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. > 3. I wonder if we could take advantage of the new =E2=80=98&message=E2=80= =99 exception > to start i18n of error messages. It might be as simple as telling > xgettext to recognize =E2=80=98make-exception-with-message=E2=80=99 as a = keyword, though > currently there are few calls to =E2=80=98make-exception-with-message=E2= =80=99 followed > by a literal. Eventually this will get called by `error', I think; Guile's R7RS layer in wip-r7rs defines `error' as being: (define (error message . irritants) (raise-exception (let ((exn (make-exception-with-message message))) (if (null? irritants) exn (make-exception exn (make-exception-with-irritants irritants)))))) But yes this is definitely something to think about it. > 4. Is =E2=80=98&warning=E2=80=99 actually used? Is the goal to make it c= ontinuable? > 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 :) > Bah, you give us a present and I reply with an additional wishlist. > ;-) :) I hope that the exceptions work can serve as a foundation for further incremental, compatible improvement. Cheers, Andy