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,gmane.lisp.guile.user Subject: Re: GNU Guile 2.9.5 Released [beta] Date: Mon, 6 Jan 2020 23:14:19 +0000 Message-ID: <20200106231419.7fd821d8a60f0ef400f7ffe1@gmail.com> References: <87lfs8kkao.fsf@pobox.com> <20191201204142.0388791e61fa443e615605da@gmail.com> <87eewdu0av.fsf@pobox.com> <20200105232640.8d389c139c7b4993e90938a1@gmail.com> <87eewcs4r0.fsf@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="75863"; mail-complaints-to="usenet@blaine.gmane.org" Cc: guile-user@gnu.org, guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Jan 07 00:14:10 2020 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 1iobZZ-000Jbt-7g for guile-devel@m.gmane.org; Tue, 07 Jan 2020 00:14:09 +0100 Original-Received: from localhost ([::1]:48578 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iobZX-0007xb-Uv for guile-devel@m.gmane.org; Mon, 06 Jan 2020 18:14:07 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48469) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iobZS-0007wV-V6 for guile-devel@gnu.org; Mon, 06 Jan 2020 18:14:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iobZR-000490-PZ for guile-devel@gnu.org; Mon, 06 Jan 2020 18:14:02 -0500 Original-Received: from mail-wr1-x431.google.com ([2a00:1450:4864:20::431]:43306) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iobZR-00047s-IM; Mon, 06 Jan 2020 18:14:01 -0500 Original-Received: by mail-wr1-x431.google.com with SMTP id d16so51799303wre.10; Mon, 06 Jan 2020 15:14:01 -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=Tf69fcORYWYhnCdQYw6oN1tlXo65BcWnyINprdVGUUI=; b=F+7Xo1c5zRmoWTO7NIDGeeWMucdyjlR3huymn/TBgG8cMIPbb8h3mrlI7zcWk+y9oJ rPU5DuvuygLgf4SgWAOg7dxG+LgDrLTBgvJ5SsxlUZHzCwJ7IyK/QvUfPVLPM8bo6dDr +kN9GkvcU9zKg3Y4rsOSj8geBpyTSioP+3fRNacveiR3NvGi6ow2KFyTXk7sm10FKTOm 6F//yhQDiKM57RqR/Bft5VCwIstlrlkISBAYduZHKO1aThTGLXmEnFR0XvmcvlBCP0w7 wsAaMz1nkvANOtmJSJRiA4Htsc7xio3bXWaJX6+UkdqpwyC8xKXn8P5xC/7gqqZtkTcn cW4g== 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=Tf69fcORYWYhnCdQYw6oN1tlXo65BcWnyINprdVGUUI=; b=S21gHmLLGdbPO+pWNwoA++0j9J5uoWDyc/9G74ZJIiMPmNMC3xL4EWYhD469k8z/fV IVjDRXDXW9yTjKzZk3NdV7BwPR3gDJvR1G0ocsYwQlj/tVRwCWBhYYpXR336NkSywVer Znu6zinoxOBYY6klDeMipeNULwmerVWQhOkPVQqT4v88bvAP8Arl8bK5Vg3GqX99/IMz gnjkRrAqI2PBqe1H889m0V81q0sycWC5Pv2uCq5r30QrFlSOVNis5s0B8wCDTxiR+jpA Re8zP5vdSsuIWMJFppwJ39hP6BMMrkactEmrQCIlgnLNtXPdsEuO4fDJg5Jz4vJk2/R+ 3hpA== X-Gm-Message-State: APjAAAW2HErJwUTt3R802e79H5AcIHztv4A9bX4+HzGE3F76e1sftSit V9p0Nib6vtZZhlP9+U9MQdjYDGMs X-Google-Smtp-Source: APXvYqzKx8bcZfGHNOrCRJDRUMfBosLCfajnvi678Sxni6qxXwMOBanFxmI7YiXbHS5uSFvN3CyzUg== X-Received: by 2002:adf:e70d:: with SMTP id c13mr105774595wrm.248.1578352440198; Mon, 06 Jan 2020 15:14:00 -0800 (PST) Original-Received: from bother.homenet ([91.110.243.20]) by smtp.gmail.com with ESMTPSA id a14sm79050692wrx.81.2020.01.06.15.13.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Jan 2020 15:13:59 -0800 (PST) Original-Received: from bother.homenet (localhost [127.0.0.1]) by bother.homenet (Postfix) with SMTP id 823E7267A1E; Mon, 6 Jan 2020 23:14:19 +0000 (GMT) In-Reply-To: <87eewcs4r0.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::431 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:20237 gmane.lisp.guile.user:16003 Archived-At: On Mon, 06 Jan 2020 21:34:59 +0100 Andy Wingo wrote: > On Mon 06 Jan 2020 00:26, Chris Vine writes: > > I have a 'try' macro which adopts the approach that if an exception > > arises, the macro unwinds from the dynamic environment of the code > > where the exception arose to the dynamic environment of the call to > > 'try', evaluates the cond clauses in that environment, and then if no > > cond clause matches re-raises the exception in that environment with > > 'raise' (rather than 'raise-continuable'). In other words, it does > > stack unwinding in the same way as exception implementations in almost > > all other mainstream languages which use exceptions. It would be > > trivial to implement this with guile-3.0's with-exception-handler with > > its unwind? argument set to true. > > I am not sure this really matches with this use case: > > (define (call-with-backtrace thunk) > (call/ec > (lambda (ret) > (with-exception-handler > (lambda (exn) > (show-backtrace exn) ;; placeholder > (ret)) > thunk)))) > > (define (false-on-file-errors thunk) > (call/ec > (lambda (ret) > (with-exception-handler > (lambda (exn) > (if (file-error? exn) > (ret #f) > (raise-continuable exn))) > thunk)))) > > (define (foo f) > (call-with-backtrace > (lambda () > (false-on-file-errors f)))) > > > If there's an error while invoking `f' that's not a file error, you want > to have remained in the context of the error so you can show a full > backtrace. To my mind this is central to the exception handler design. > So far so good I think. > > If I change the implementation of `false-on-file-errors' to be: > > (define (false-on-file-errors thunk) > (guard (exn ((file-error? exn) #f)) > (thunk))) > > I think this change should preserve the not-unwinding environment that > `call-with-backtrace' expects. Good point. My approach does provide the programmer with less conveyed stack information after the re-raise of an unhandled exception, requiring more manual intervention to recover the information when debugging the exception. Before you suggested it I had not previously considered your proposal. It may turn out to be the optimum solution, but I wonder if it would surprise the programmer to have the cond conditionals evaluated in a different dynamic environment from the one in which the cond consequential is evaluated where there is a conditional which is true. But I am not sure if that is of any importance. Chris