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.devel Subject: Re: GNU Guile 2.9.5 Released [beta] Date: Sun, 1 Dec 2019 20:41:42 +0000 Message-ID: <20191201204142.0388791e61fa443e615605da@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="21813"; mail-complaints-to="usenet@blaine.gmane.org" Cc: guile-users@gnu.org, guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Dec 01 21:41:49 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 1ibW2P-0005Yw-8e for guile-devel@m.gmane.org; Sun, 01 Dec 2019 21:41:49 +0100 Original-Received: from localhost ([::1]:55330 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ibW2O-0006gS-5M for guile-devel@m.gmane.org; Sun, 01 Dec 2019 15:41:48 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45137) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ibW27-0006gC-5l for guile-devel@gnu.org; Sun, 01 Dec 2019 15:41:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ibW24-0006ft-Uv for guile-devel@gnu.org; Sun, 01 Dec 2019 15:41:30 -0500 Original-Received: from mail-wr1-x42b.google.com ([2a00:1450:4864:20::42b]:47053) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ibW24-0006eB-OW for guile-devel@gnu.org; Sun, 01 Dec 2019 15:41:28 -0500 Original-Received: by mail-wr1-x42b.google.com with SMTP id z7so38192537wrl.13; Sun, 01 Dec 2019 12:41:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=ijKULzii/YiJysGp+phFuOjeIgrHfihcXRz5knEV54k=; b=hx60uzu3wldM/tenJgb3du6YwXksIPwd/g7MYdU0k0CHiTs/IjfirNhd3BNjoBW73i MQIxXG4PRuMBDPQJ4z2giaLf0JriMZ12giXkPFuNgM0vgUEjg/kVPsGhrEgsVRZARSgy pWVRIppUJ59/Tm/4YbIyJeLr1EstDmQ9fFJGF5lyy59ClCW4E10FMa/18+aMPiyPqdZd TY8QnRCLkwPdRI6p++pJkcN/nMLt9oXBqebJrbTv9g3pOcPrtgjSeOIwx0G5t9wQTGtC ldKGPKGbkNwFdvXS+NmTdTK9nLnxQvzkaZMaZot3JehciyWpXid419XE1ZzMXA3A2HzR q8/w== 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:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=ijKULzii/YiJysGp+phFuOjeIgrHfihcXRz5knEV54k=; b=bDzlFP8nERjCD0E31LC1ckRMVTYLe43QzPkV2/roCbP346zhFsCOKJm+WoczJakM8G nInmoEyCCV4umylmAsTTWSWOHgecdITzC22QxbDqChlhZI3+6w+7Z4Wvx2qF/zTZilgC wpQgjDDFHRfjJHIBTdPc4FmTFO4RQIAo04GWppvphMWs6nHH994lcOf1B+uzdQoS952N jB5a8PFgMdfOFCZ/1JWro7cFCMDMLEozGNY2cjOhey1LI3082+GlgjGxo43OK+pwkOwU HH5mK0ypBYMF5VjXv1oVrCcY12Dz7fPeneLRLqcGcfdzfv8GmMicNO4VKpojdzrmARkU MiTA== X-Gm-Message-State: APjAAAVY9VDLTnv65CI8ADYCliW0+xMnrsF6rOzzDy2KcUfwb2+SXXml jwm9cx7gOSFVIq0UJ8IQbcR8sc3w X-Google-Smtp-Source: APXvYqw5G+So+KID2GPP9yP80WPyYIy7J2t5VRYV/WcIf5uVf/HV27b+iYoNi8OnO8k2TZb81wJp+Q== X-Received: by 2002:a5d:4a91:: with SMTP id o17mr9448904wrq.232.1575232887056; Sun, 01 Dec 2019 12:41:27 -0800 (PST) Original-Received: from bother.homenet ([2002:5f92:6c68:10:92c5:87ef:6ea8:1cef]) by smtp.gmail.com with ESMTPSA id v20sm21732963wmj.32.2019.12.01.12.41.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 01 Dec 2019 12:41:26 -0800 (PST) Original-Received: from bother.homenet (localhost [127.0.0.1]) by bother.homenet (Postfix) with SMTP id 87F482601B3; Sun, 1 Dec 2019 20:41:42 +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::42b 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:20174 Archived-At: 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