From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Chris Vine Newsgroups: gmane.lisp.guile.user Subject: Re: GNU Guile 2.9.5 Released [beta] Date: Sun, 1 Dec 2019 20:59:02 +0000 Message-ID: <20191201205902.ca2725cc28e51edb5ffd5788@gmail.com> References: <87lfs8kkao.fsf@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="91556"; mail-complaints-to="usenet@blaine.gmane.org" To: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sun Dec 01 21:59:09 2019 Return-path: Envelope-to: guile-user@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 1ibWJA-000NgJ-Sg for guile-user@m.gmane.org; Sun, 01 Dec 2019 21:59:09 +0100 Original-Received: from localhost ([::1]:55458 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ibWJ9-00066N-K8 for guile-user@m.gmane.org; Sun, 01 Dec 2019 15:59:07 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48868) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ibWIr-00066C-9D for guile-user@gnu.org; Sun, 01 Dec 2019 15:58:50 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ibWIp-0001MD-KQ for guile-user@gnu.org; Sun, 01 Dec 2019 15:58:49 -0500 Original-Received: from mail-wr1-x42d.google.com ([2a00:1450:4864:20::42d]:41165) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ibWIp-0001Kh-BO for guile-user@gnu.org; Sun, 01 Dec 2019 15:58:47 -0500 Original-Received: by mail-wr1-x42d.google.com with SMTP id b18so41695107wrj.8 for ; Sun, 01 Dec 2019 12:58:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=SGRS7MYoJNeVhGS40stlrucP32ETrb4iQ7xNHSqUMcA=; b=WWQ9V/3XDFUnaGXQF/zm/QB8AtZS097UFh9W2/qbRTB7hRbG4DOYbwlSkubHiyD5Aq zCuViPl8VVSpENmiP1e1D1ve+lNUiyvlXwu7FkEYeY47tA7fU2bmq8od/9Pq6yxdN6kN dGDTKtzYkuqDE3WsH/wVWVyJFh08fEmP6KspHrxOEBhQQSttuSOsyT8z6KY+R8NZtXcz U/2pCnmgx/DUztViiEv/MgMZTXseL2oj0t7fQIt+dPkNfwUo4p9hg9jfdA37dovDVHHf Z5B7Z9UYkATPMFX4l1GQECiyQMkwijBhupJCH/qkDHQZPgX2bf7nsf0ppOMJ/UovELWv qitA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=SGRS7MYoJNeVhGS40stlrucP32ETrb4iQ7xNHSqUMcA=; b=V49xxsisy+h/BcgURbVoypmOA7SX5h58bU+Y4ya0zloBuo7lEEsic88PJDnAimq1/r BdEKtufuF5tOyNFTCQHinJ5a+SEixFBtF5Gr1888c+LmbpEgT4CBjLbNjh6Y1wFoXi4Z cUnPUMOXQjc7CW1y4Dd66ocmcl/b9OzKjIjk2vnbf35eKMKiQJ92MwAU9faH3HrlbOD3 UU+3icsmVPAKpDwnEWiOqQ9DakcR8HvOPsxmOKkxDFGH6Jpbr5txKiG+4n26Dbw6kyHn q716Na+r8006qDf3hrD2vHIIlRdtJIl0z6G9EWY0TkL0iIRPHWg1ZpIbx+S8UWBu2hgZ imVw== X-Gm-Message-State: APjAAAVi8XH6Bey5+0ZeVQKUenPbbzXLad3KFbbWGR+2QsoqChrks9P1 RIiGMEcSDbBhn64XXDhagbzhXZMB X-Google-Smtp-Source: APXvYqznL+Q6qpGxULmsPpNbmkt0ypIfM60tIOgpat8JhLY5eN3X+kifa23ASLqmhnU5W2O5kqPRJw== X-Received: by 2002:adf:f28c:: with SMTP id k12mr43481082wro.360.1575233925753; Sun, 01 Dec 2019 12:58:45 -0800 (PST) Original-Received: from bother.homenet ([95.146.108.104]) by smtp.gmail.com with ESMTPSA id e19sm21540705wme.6.2019.12.01.12.58.44 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 01 Dec 2019 12:58:45 -0800 (PST) Original-Received: from bother.homenet (localhost [127.0.0.1]) by bother.homenet (Postfix) with SMTP id 00F5C2601B3 for ; Sun, 1 Dec 2019 20:59:02 +0000 (GMT) In-Reply-To: <87lfs8kkao.fsf@pobox.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; x86_64-unknown-linux-gnu) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::42d X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.org gmane.lisp.guile.user:15922 Archived-At: Sorry, a resend to guile-user - the copy to that mailing list was misaddressed. ------------------------------ On Fri, 22 Nov 2019 16:22:39 +0100 Andy Wingo wrote: > We are pleased to announce GNU Guile release 2.9.5. This is the fifth > pre-release of what will eventually become the 3.0 release series. [snip] > ** Reimplementation of exceptions >=20 > Since Guile's origins 25 years ago, `throw' and `catch' have been the > primary exception-handling primitives. However these primitives have > two problems. One is that it's hard to handle exceptions in a > structured way using `catch'. Few people remember what the > corresponding `key' and `args' are that an exception handler would see > in response to a call to `error', for example. In practice, this > results in more generic catch-all exception handling than one might > like. >=20 > The other problem is that `throw', `catch', and especially > `with-throw-handler' are quite unlike what the rest of the Scheme world > uses. R6RS and R7RS, for example, have mostly converged on > SRFI-34-style `with-exception-handler' and `raise' primitives, and > encourage the use of SRFI-35-style structured exception objects to > describe the error. Guile's R6RS layer incorporates an adapter between > `throw'/`catch' and structured exception handling, but it didn't apply > to SRFI-34/SRFI-35, and we would have to duplicate it for R7RS. >=20 > In light of these considerations, Guile has now changed to make > `with-exception-handler' and `raise-exception' its primitives for > exception handling and defined a hierarchy of R6RS-style exception types > in its core. SRFI-34/35, R6RS, and the exception-handling components of > SRFI-18 (threads) have been re-implemented in terms of this core > functionality. There is also a a compatibility layer that makes it so > that exceptions originating in `throw' can be handled by > `with-exception-hander', and vice-versa for `raise-exception' and > `catch'. >=20 > Generally speaking, users will see no difference. The one significant > difference is that users of SRFI-34 will see more exceptions flowing > through their `with-exception-handler'/`guard' forms, because whereas > before they would only see exceptions thrown by SRFI-34, now they will > see exceptions thrown by R6RS, R7RS, or indeed `throw'. >=20 > Guile's situation is transitional. Most exceptions are still signalled > via `throw'. These will probably migrate over time to > `raise-exception', while preserving compatibility of course. >=20 > See "Exceptions" in the manual, for full details on the new API. Is this rewrite, and the new with-exception-handler procedure, an opportunity to think about standardization of guile's implementation of the R6RS/R7RS 'guard' form, or at least think about what is wanted for 'guard'? The formal semantics (including specimen implementation) of 'guard' for R6RS with the corrigendum to =A77.1 of the standard library at http://www.r6rs.org/r6rs-errata.html, and for R7RS without corrigendum (at =A74.2.7 and =A77.3, page 72 of the standard), is: (i) to evaluate the guard body within a block with its own continuation (as constructed by call/cc); (ii) if an exception is thrown, evaluate the handler (and its cond clauses) in the dynamic context of the original caller of 'guard' via that continuation; (iii) if no matching cond clause and no else clause is found, return to the dynamic environment of the original 'raise' and re-raise the exception with 'raise-continuable', even for non-continuable exceptions. If a fully conforming R6RS/R7RS implementation runs this code: (guard (exn [(equal? exn 5) #f]) (guard (exn [(equal? exn 6) 'never-reached]) (dynamic-wind (lambda () (display "in") (newline)) (lambda () (raise 5)) (lambda () (display "out") (newline))))) the code evaluates to #f and should print this: in out in out In chez scheme it does so. In most other implementations (including guile and racket) it seems to print: in out Guile 2.9.5 appears to implement 'guard' this way: (i) to evaluate the guard body within a block with its own continuation (as constructed by call/ec); (ii) if an exception is thrown, evaluate the handler (and its cond clauses) in the dynamic environment of the guard body within which the raise occurred (apart from the current exception handler which is reset); (iii) if no matching cond clause and no else clause is found, re-raise the exception with 'raise' within the dynamic context of that guard body. I don't especially like the mandated behaviour of 'guard', which seems to be intended to allow the guard form to handle continuable exceptions as continuable elsewhere in the call stack, which seems fairly pointless to me. If this is to be departed from, then how about doing what most people expect of a high-level exception form, and to unwind the stack by executing the cond clauses within the dynamic context of the caller of 'guard' (as R6RS/R7RS do), not in that of the guard body, and then if a re-throw is necessary do it with 'raise' within that context instead of returning to the guard body to do so? I think this could be achieved simply by executing with-exception-handler in the guard0 syntactic form with #unwind set to true. Chris