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: GNU Guile 2.9.5 Released [beta] Date: Mon, 06 Jan 2020 21:34:59 +0100 Message-ID: <87eewcs4r0.fsf@pobox.com> References: <87lfs8kkao.fsf@pobox.com> <20191201204142.0388791e61fa443e615605da@gmail.com> <87eewdu0av.fsf@pobox.com> <20200105232640.8d389c139c7b4993e90938a1@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="212978"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cc: Andy Wingo , guile-users@gnu.org, guile-devel@gnu.org To: Chris Vine Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Jan 06 21:35:25 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 1ioZ5w-000tEy-Vm for guile-devel@m.gmane.org; Mon, 06 Jan 2020 21:35:25 +0100 Original-Received: from localhost ([::1]:60946 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ioZ5v-0005Hl-GO for guile-devel@m.gmane.org; Mon, 06 Jan 2020 15:35:23 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50197) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ioZ5p-0005HM-5y for guile-devel@gnu.org; Mon, 06 Jan 2020 15:35:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ioZ5n-0008S3-QH for guile-devel@gnu.org; Mon, 06 Jan 2020 15:35:17 -0500 Original-Received: from fanzine.igalia.com ([178.60.130.6]:51138) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ioZ5n-0008P9-7N for guile-devel@gnu.org; Mon, 06 Jan 2020 15:35:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=PosLaiINDbUPtC5sBylYQ0duiOiJp9lJbADbvUF4HpU=; b=dCiJT9v/IZWRp+p9w8lezq0m2RiulBNK9RBx5rgRCOCUbqcDZkCx26MSeucC1V2QMxU+nJzM5bu8QFDhFBwvvWeL7tQnmkvu+XVk+n1uYKVkP6T0FIuhCRDv8s/HYYXvE6fOzCdoEsuy46qPIEmR4AE6E5saal75yvLrWC6C0OMt2l7jcE1fV6Qk1gy6Q8dUt+bgoDH+FRWF+f6pGTiobA7LjNl1u/3WCgBdLYw3s16yX0TfJiPTMVP9xXa6WV6nLxOVQb7eIkXTIHLCW+QTYu7eAOnytJjdM4Y0X85vFqjZeIdiVApavZ40WIzgJLOZvDCm3JLh02VuH48Kjjc8rw==; Original-Received: from [88.123.12.110] (helo=sparrow) by fanzine.igalia.com with esmtpsa (Cipher TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim) id 1ioZ5g-0006B4-Tq; Mon, 06 Jan 2020 21:35:09 +0100 In-Reply-To: <20200105232640.8d389c139c7b4993e90938a1@gmail.com> (Chris Vine's message of "Sun, 5 Jan 2020 23:26:40 +0000") 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:20234 Archived-At: 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. > On the other hand, as you say it does not seem feasible to implement > in guile the R6RS/R7RS requirement to unwind to the environment of the > call to 'guard' when evaluating the cond clauses, and then return to > the environment of the original exception in order to re-raise if no > cond clause matches. It's feasible, just not a good idea IMO. The problem is that call/cc is quite expensive. Additionally that it captures the whole state of the current thread, so a fiber (github.com/wingo/fibers) with a `guard' may error if it is preempted and migrated to a different CPU. > Furthermore such a return is only relevant if the exception is to be > re-raised with 'raise-continuable' instead of 'raise': it is pointless > if the exception is re-raised with 'raise' because with 'raise' you > can never get back there again. FWIW I am not sure how raise-continuable will be used but it's a fairly straightforward thing implementation-wise that doesn't bother me. > I am somewhat influenced by my view of 'raise-continuable'. I don't > like it - how often does anyone use continuable exceptions, which seem > to be a reimplementation of common lisp restarts? I am not sure that they are restarts. A restart to my mind is more like: (define (with-restart name thunk) (let lp () (define tag (make-prompt-tag)) (call-with-prompt tag (lambda () (parameterize ((current-restarts (acons name tag (current-restart)))) (thunk))) (lambda (k) (lp))))) (define (invoke-restart-by-name name . vals) (match (assoc name (current-restarts)) ((name . tag) (apply abort-to-prompt tag vals)))) So you could invoke a restart within an exception handler but it has nothing to do with whether raise or raise-continuable was used. The continuation captured by the equivalent of common lisp's `restart-case' isn't the continuation that raises the error. Regards, Andy