First draft of foreign-errors SRFI API Lassi Kortela (27 Jun 2020 21:34 UTC)
Re: First draft of foreign-errors SRFI API John Cowan (28 Jun 2020 02:30 UTC)
Re: First draft of foreign-errors SRFI API Lassi Kortela (28 Jun 2020 11:40 UTC)
Re: First draft of foreign-errors SRFI API hga@xxxxxx (28 Jun 2020 13:09 UTC)
Re: First draft of foreign-errors SRFI API Lassi Kortela (28 Jun 2020 13:31 UTC)
Re: First draft of foreign-errors SRFI API hga@xxxxxx (28 Jun 2020 12:05 UTC)
Re: First draft of foreign-errors SRFI API Lassi Kortela (28 Jun 2020 15:10 UTC)
Re: First draft of foreign-errors SRFI API hga@xxxxxx (29 Jun 2020 16:49 UTC)
Re: First draft of foreign-errors SRFI API Arthur A. Gleckler (29 Jun 2020 17:35 UTC)
Re: First draft of foreign-errors SRFI API hga@xxxxxx (29 Jun 2020 17:55 UTC)
Re: First draft of foreign-errors SRFI API hga@xxxxxx (29 Jun 2020 18:10 UTC)

Re: First draft of foreign-errors SRFI API hga@xxxxxx 28 Jun 2020 13:08 UTC

> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Sunday, June 28, 2020 6:40 AM
>
> Thanks for the quick feedback!
>
>> I think the first half of this makes sense, but I don't think the idea
>> of reifying all the symbols of a collections, still less all the
>> collections.

As in all the error-sets?  That would indeed be too much.

>> The Oracle collection has 1963 messages in it, and who
>> even knows if Oracle provides a way to navigate through them.  If we
>> keep them just names, we are completely free to let them be used by any
>> system, whether we have an overview of it or not.
>
> I don't know what reification means precisely,

In this case, I interpret it as meaning that the Error set procedures
would be working off an internal database the implementation
constructs that contains *all* possible errors for an error-set, i.e.
for Oracle (and only the database?), all 1963 errors, including message
strings.  Which I wouldn't want to burden a microcontroller with....

> but the idea is not to limit a particular error collection to a
> particular set of errors defined in advance. The set of all error
> collections should be open to changes, as should each individual
> collection in it IMHO.
>
> Enumerating all known errors in a particular collection can be
> convenient (prior art e.g.
> <https://docs.python.org/3/library/errno.html>) but it should still be
> possible to get the error message for errors not known at compile time.

So the Error set procedures would have both?  Or perhaps construct just
the subset used by the application??

> People who enumerate a collection should do so with the assumption that
> the collection may be incomplete.
>
> I'm not 100% sure that having enumeration is a good idea, so I'll gladly
> listen to more arguments to the contrary.
>
> [ Localization, where you're definitely thinking of having compile time
>   construction of a database of English messages, not available at run
>   time in for example a foreign localized version of Windows. ]

- Harold