Re: guile 3 update, halloween edition

[Ludovic Courtès]

Hi Andy!

Andy Wingo <address@hidden> skribis:

> On Fri 15 Nov 2019 10:03, Ludovic Courtès <address@hidden> writes:
>
>> 0. Do I get it right that ‘throw’ and ‘catch’ are not “deprecated” in
>> the sense of (ice-9 deprecated) and are instead simply not the
>> “preferred” exception mechanism?
>
> Correct.  I think we could envision deprecating them in some future but
> not within the next couple years at least.

Alright, sounds good.

>> 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.)

> Yes.  So right now Guile is in a bit of a transitional state -- it still
> signals 99.9% of errors via `throw'.  Probably we want to change to have
> structured exceptions for almost all of these.  To preserve
> compatibility we would probably need to mix in an
> &exception-with-kind-and-args to all of these exceptions, or otherwise
> augment `exception-kind' and `exception-args' to synthesize these values
> when appropriate.

Yes, I agree.

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)?

If it were public, I imagine that users could take advantage of it to
support both exception styles, just like Guile does.  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.)

WDYT?

>> Guix has ‘&location’ error conditions, which I’ve found useful when
>> combined with other error conditions in cases where location info from
>> the stack isn’t useful:
>>
>>   https://git.savannah.gnu.org/cgit/guix.git/tree/guix/utils.scm#n832
>>
>> I wonder if (ice-9 exceptions) should provide something like that.
>
> Neat :)  Yes sure.  I think, any exception type can be added to (ice-9
> exceptions) -- there's little "name cost" like there is in boot-9.
> Which reminds me, I want to make boot-9 do a (resolve-module '(ice-9
> exceptions)) so that the more capable make-exception-from-throw always
> gets installed.
>
>> 2. What are you thoughts regarding exposing structured exceptions to C?
>> I’ve always been frustrated by ‘system-error’ :-).  Guix has a hack to
>> augment ‘system-error’ with information about the offending file name:
>>
>>   https://git.savannah.gnu.org/cgit/guix.git/tree/guix/ui.scm#n520
>>
>> If the POSIX bindings would emit a structured ‘&system-error’ record,
>> that’d be pretty cool.
>
> I don't know :)  Right now raise-exception is marked SCM_INTERNAL.
> Probably it should be public.  There is no public C API for any of this
> new functionality, as it stands; a TODO.
>
> Regarding exception objects, there are two questions: one, how to create
> exceptions of specific kinds; I suspect scm_make_system_error () would
> be fine, and probably you want scm_make_exception to be able to mix
> various exceptions.  Second question, do we want to expose accessors
> too?  It can be a lot of API surface and I am a bit wary of it.  But,
> perhaps it is the right thing.  I do not know.

Yeah, it might be that having C stick to ‘throw’ + allowing for
user-defined exception converters would be enough.

>> 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 :-)).

Thank you!

Ludo’.