> 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