guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: guile 3 update, halloween edition


From: Andy Wingo
Subject: Re: guile 3 update, halloween edition
Date: Sun, 17 Nov 2019 20:33:32 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)

Hi :)

On Sat 16 Nov 2019 16:26, Ludovic Courtès <address@hidden> writes:

> Andy Wingo <address@hidden> skribis:
>
>> On Fri 15 Nov 2019 10:03, Ludovic Courtès <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]