Full proposal for the localized error message API Lassi Kortela (26 Jul 2020 22:00 UTC)
Re: Full proposal for the localized error message API Lassi Kortela (26 Jul 2020 22:01 UTC)
Re: Full proposal for the localized error message API Lassi Kortela (26 Jul 2020 22:10 UTC)

Full proposal for the localized error message API Lassi Kortela 26 Jul 2020 22:00 UTC

Based on the last thread, I would recommend this API:

(foreign-error:message ferr [locale]) -> string or #f
(foreign-error:locales ferr) -> list of symbols

The constructor would be called thus:

(make-foreign-error '((message . <string or procedure or #f>))) -> ferr

If `message` is...

* a string, then the omitted locale `#f` returns that string and all
other locales return `#f`.

* the value `#f`, then no message is known for the error at all, and all
locales return `#f`.

* a procedure, then the procedure takes exactly one required argument
giving the locale. If the locale is `#t` then a list of all supported
locales is returned. It the locale is `#f` then the

Reasons:

- It's opt-in. People who don't care about locales can omit the optional
argument to `foreign-error:message`.

- If the list of supported locales is slow to enumerate, then requiring
the user to explicitly call a lambda (instead of enumerating all locales
at the time the error object is constructed) to list locales is more
efficient for the common case where the user only wants a particular
language or the default one.

- For cases where it's cheaper to fetch the full list of locales and/or
their messages right away, the procedure can be a closure that simply
returns data from the pre-collected list.

- It's good that `foreign-error:message` always returns a string, never
a lambda. That's a simple API for users. If the error object has a
lambda to get messages, that lambda will be called transparently and the
user doesn't have to care about the difference.