From: Andy Wingo <wingo@pobox.com>
To: Chris Vine <vine35792468@gmail.com>
Cc: Andy Wingo <wingo@pobox.com>, guile-users@gnu.org, guile-devel@gnu.org
Subject: Re: GNU Guile 2.9.5 Released [beta]
Date: Mon, 06 Jan 2020 21:34:59 +0100 [thread overview]
Message-ID: <87eewcs4r0.fsf@pobox.com> (raw)
In-Reply-To: <20200105232640.8d389c139c7b4993e90938a1@gmail.com> (Chris Vine's message of "Sun, 5 Jan 2020 23:26:40 +0000")
On Mon 06 Jan 2020 00:26, Chris Vine <vine35792468@gmail.com> 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
next prev parent reply other threads:[~2020-01-06 20:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-22 15:22 GNU Guile 2.9.5 Released [beta] Andy Wingo
2019-11-22 16:01 ` tomas
2019-12-01 20:41 ` Chris Vine
2020-01-05 20:15 ` Andy Wingo
2020-01-05 23:26 ` Chris Vine
2020-01-06 20:34 ` Andy Wingo [this message]
2020-01-06 23:14 ` Chris Vine
2020-01-07 21:53 ` Andy Wingo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87eewcs4r0.fsf@pobox.com \
--to=wingo@pobox.com \
--cc=guile-devel@gnu.org \
--cc=guile-users@gnu.org \
--cc=vine35792468@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).