From: Andy Wingo <wingo@pobox.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: Guile Devel <guile-devel@gnu.org>
Subject: Re: guile 3 update, halloween edition
Date: Sun, 17 Nov 2019 20:33:32 +0100 [thread overview]
Message-ID: <87wobyl2lv.fsf@pobox.com> (raw)
In-Reply-To: <87bltbyh95.fsf@gnu.org> ("Ludovic Courtès"'s message of "Sat, 16 Nov 2019 16:26:30 +0100")
Hi :)
On Sat 16 Nov 2019 16:26, Ludovic Courtès <ludo@gnu.org> writes:
> Andy Wingo <wingo@pobox.com> skribis:
>
>> On Fri 15 Nov 2019 10:03, Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> I guess we could add a specific ‘&type-exception’ exception or similar,
>>> which would allow us to improve error reporting (that can come later, of
>>> course.)
>
> What I meant is that type errors are “special” enough to deserve their
> own type more specific than the catch-all ‘&assertion-failure’ (just
> like there’s already a separate ‘&undefined-variable’, for instance.)
Agreed!
> Speaking of which, it seems that ‘set-guile-exception-converter!’ is
> currently private, but I wonder if the goal was to make it public (it
> seems to be unused)?
It was private also in the exception conversion work that Mark did,
FWIW; it just moved over as-is.
Honestly I think that now that exceptions are "primary" we should
probably move in the opposite direction: instead of adding more
converters from key+args to exception objects, we should encourage
exception throwers to switch from "throw" to "raise-exception", and
allow library authors to define converters in the other way from
exception object to the equivalent arguments for "catch". So I think
exposing set-guile-exception-converter! might be the wrong thing at this
point. Dunno tho.
> For instance, C bindings that currently call ‘throw’ could provide
> additional “exception converters” for the benefit of Scheme users
> who’d rather use structured exceptions. (That would also give less of
> an incentive to provide a C API for all of this.)
This is a good point!
FWIW Regarding C and migration, I have the impression that probably 90%
of exception throwers in C use the helpers from error.h
(scm_wrong_num_args and so on), which we can change transparently. A
remaining 5% might use scm_error_scm, for which a registry might make
sense, and 5% use scm_throw directly. These are just guesses tho.
>>> 4. Is ‘&warning’ actually used? Is the goal to make it continuable?
>>> That sounds great.
>>
>> Any exception can be raised in a continuable way. Whether a raise is
>> continuable or not depends on the value of the #:continuable? keyword to
>> raise-exception. I think that's the intention of &warning but I don't
>> really have instincts about how it might be used. Guile defines it
>> because it's in R6RS, but how it will be used is an open question :)
>
> I suppose the intent is to effectively allow users to implement the UI
> stuff as a sort of co-routine to support separation of concerns: you
> just raise a ‘&warning’ that some other code displays in its preferred
> way (console message, popup window, whatever) and eventually calls your
> continuation.
>
> That’s something I’ve been wanting for some time, because right now
> we’re able to separate out the UI concern for exception display, but not
> for warnings.
>
> However, it seems that the handler passed to ‘with-exception-handler’
> does not receive the continuation, so is it the case that currently
> handlers cannot resume exceptions? (Again not a showstopper IMO but
> rather another wishlist item :-)).
The handler runs within the continuation of "raise-continuable":
(with-exception-handler
(lambda (exn) (+ exn 30))
(lambda () (+ 2 (raise-exception 10 #:continuable? #t))))
=> 42
However I'm not sure this facility is what you want. Like for example
there's lots of false-if-exception / catch #t out there; that's
equivalent to:
(define-syntax-rule (false-if-exception expr)
(let/ec k
(with-exception-handler
(lambda (exn) (k #f))
(lambda () expr))))
So the exception handler there would intervene and get a first crack at
the warning, messing up your intent. To me warnings are like logging,
and logging is notoriously difficult to standardize :) If it were me I
would make a mechanism for warnings that had a with-warning-handler and
I would make sure to raise all warnings via a separate raise-warning
procedure or something, independent of exceptions. But that's just me
:)
Andy
prev parent reply other threads:[~2019-11-17 19:33 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-30 20:13 guile 3 update, halloween edition Andy Wingo
2019-10-30 21:19 ` Christopher Lemmer Webber
2019-10-31 0:01 ` Chris Vine
2019-10-31 16:20 ` Andy Wingo
2019-10-31 17:27 ` Chris Vine
2019-10-31 1:31 ` Nala Ginrut
2019-10-31 1:47 ` Thompson, David
2019-10-31 14:17 ` Mikael Djurfeldt
2019-10-31 16:13 ` Andy Wingo
2019-10-31 14:46 ` David Pirotte
2019-10-31 16:44 ` Sjoerd van Leent
2019-11-02 5:20 ` Mark H Weaver
2019-11-02 19:33 ` Mark H Weaver
2019-11-03 19:16 ` Andy Wingo
2019-11-03 20:18 ` Mark H Weaver
2019-11-15 9:03 ` Ludovic Courtès
2019-11-15 10:23 ` Andy Wingo
2019-11-16 15:26 ` Ludovic Courtès
2019-11-17 19:33 ` Andy Wingo [this message]
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=87wobyl2lv.fsf@pobox.com \
--to=wingo@pobox.com \
--cc=guile-devel@gnu.org \
--cc=ludo@gnu.org \
/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).