unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
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: Fri, 15 Nov 2019 11:23:42 +0100	[thread overview]
Message-ID: <87zhgxmo9d.fsf@pobox.com> (raw)
In-Reply-To: <87sgmp1pfu.fsf@gnu.org> ("Ludovic Courtès"'s message of "Fri, 15 Nov 2019 10:03:49 +0100")

Hey thanks for the review :)

On Fri 15 Nov 2019 10:03, Ludovic Courtès <ludo@gnu.org> 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.

> 1. I see things like:
>
> +(define (make-condition type . field+value)
> +  "Return a new condition of type TYPE with fields initialized as specified
> +by FIELD+VALUE, a sequence of field names (symbols) and values."
> +  (unless (exception-type? type)
> +    (scm-error 'wrong-type-arg "make-condition" "Not a condition type: ~S"
> +               (list type) #f))
>
> and:
>
> +      (unless (symbol? key)
> +        (throw 'wrong-type-arg "throw" "Wrong type argument in position ~a: ~a"
> +               (list 1 key) (list key)))
>
> 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.)

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.

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

> 3. I wonder if we could take advantage of the new ‘&message’ exception
> to start i18n of error messages.  It might be as simple as telling
> xgettext to recognize ‘make-exception-with-message’ as a keyword, though
> currently there are few calls to ‘make-exception-with-message’ followed
> by a literal.

Eventually this will get called by `error', I think; Guile's R7RS layer
in wip-r7rs defines `error' as being:

  (define (error message . irritants)
    (raise-exception
     (let ((exn (make-exception-with-message message)))
       (if (null? irritants)
           exn
           (make-exception exn
                           (make-exception-with-irritants irritants))))))

But yes this is definitely something to think about it.

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

> Bah, you give us a present and I reply with an additional wishlist.
> ;-)

:)  I hope that the exceptions work can serve as a foundation for
further incremental, compatible improvement.

Cheers,

Andy



  reply	other threads:[~2019-11-15 10:23 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 [this message]
2019-11-16 15:26     ` Ludovic Courtès
2019-11-17 19:33       ` 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=87zhgxmo9d.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).