Registry of known foreign error collections Lassi Kortela (27 Jul 2020 07:45 UTC)
Re: Registry of known foreign error collections Lassi Kortela (27 Jul 2020 08:06 UTC)
(missing)
Re: Registry of known foreign error collections Lassi Kortela (27 Jul 2020 12:49 UTC)
Re: Registry of known foreign error collections Arthur A. Gleckler (27 Jul 2020 17:16 UTC)
Re: Registry of known foreign error collections hga@xxxxxx (27 Jul 2020 19:22 UTC)
Re: Registry of known foreign error collections Arthur A. Gleckler (27 Jul 2020 19:33 UTC)
Re: Registry of known foreign error collections hga@xxxxxx (27 Jul 2020 19:45 UTC)
(missing)
Re: Registry of known foreign error collections Lassi Kortela (27 Jul 2020 20:03 UTC)
Re: Registry of known foreign error collections hga@xxxxxx (27 Jul 2020 20:17 UTC)
Re: Registry of known foreign error collections Lassi Kortela (27 Jul 2020 20:31 UTC)
Re: Registry of known foreign error collections Lassi Kortela (27 Jul 2020 19:48 UTC)
Re: Registry of known foreign error collections Lassi Kortela (27 Jul 2020 20:23 UTC)
Re: Registry of known foreign error collections hga@xxxxxx (27 Jul 2020 22:58 UTC)

Re: Registry of known foreign error collections hga@xxxxxx 27 Jul 2020 22:57 UTC

> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Monday, July 27, 2020 3:23 PM
>
> Thanks for thinking about this.

You're welcome.  A friend of mine once said I was a "reality organizer."

>> [ web page and initial "-meta" mailing list to discuss process etc. ]
>>
>> Create a relaxed, micro-quasi-SRFI style process: the above page tells
>> you the requirements for error-set collection "conventions", have a set
>> of gatekeepers, if any two agree a submission is ready, it goes.  I know
>> from experience elsewhere that this sort of process can work for these
>> sorts of artifacts, where the stakes are much lower than for e.g.
>> SRFIs.
>
> All of that sounds good to me. E.g. on the mailing list:
>
> Person A: "I sent a PR to add error set identifier 'libfoo. Is this OK?"
> Person B: "Looks good to me. Merged."

I mean both a person C as well as a person B agreeing it looks good, then
whichever is the 2nd to decide that doing the addition to the "database".
Or a system that does the addition upon recording the 2nd LGTM.

>> For example, there's no reason I can think of to limit an
>> error-set to just one "best" convention.
>
> What do you mean by this?

See below, I mean that there could be two legitimate sets of keys and
where they go for complicated enough error-sets.  For example the
numeric PostgreSQL class code like 28 doesn't strike me as essential
as all the others like code '|28P01| and symbol 'invalid_password.
Also whatever the convention the data is in, here, should the code
have bounding '|' characters or not.

> Ideally each error-set would have the same mnemonic error symbols in
> each Scheme implementation so that portable code can be written. In
> particular, the Windows API has error codes like this:
>
> * ERROR_ACCESS_DENIED
> * ERROR_ACPI_ERROR
> * ERROR_ALREADY_INITIALIZED
> * ...
>
> And SQLite has error codes like this:
>
> * SQLITE_CORRUPT_VTAB
> * SQLITE_IOERR_AUTH
> * SQLITE_READONLY_ROLLBACK
>
> So all error mnemonics in those sets have the same prefix (in WinAPI,
> "ERROR_" and in SQLite, "SQLITE_"). The error set registry should say
> whether that prefix is kept in the Scheme-side symbols or omitted from them.

I think you're focusing most on the data that will be in an error-set,
I'm focusing on their keys and a hierarchical arrangement of them.
E.g. for errnos

foreign-error:code -> '((number . 2)
                        (symbol . 'ENOENT]))

I'm focused on foreign-error:code holding an alist with its 'number and
symbol keys.  Your groveler ferrets out 2 and "ENOENT" from C code.

>> [ Process, and ] maybe an announcement mailing list.
>>
>> But for the latter I'm thinking discovery might be better done more
>> narrowly; at the extreme of the end user, he'll find out from
>> libraries that uses SRFI 198 when he starts using them.
>
> Indeed, ideally the registry works so well that most Scheme programmers
> don't need to know about it at all; thanks to standardization, they will
> have the same error sets with the same mnemonic identifiers everywhere
> with no special effort.

Indeed, the programmer should always be seeing the above, although I
suppose the order of the keys isn't as critical as that there be both.
But it would be better if the order in each slot were the same.

> [ IANA example, and where they failed, hooking this into the REPL, and
>   git as the database. ]
>
>> But I'm still thinking about the details of that, include how good
>> the fit [of git] is, organization of conventions, what their format
>> should be, etc.
>
> Storing the ground-truth information in simple S-expression files in Git
> has worked very well in various Scheme repos....

Indeed.  I'm referring to things like how do these files get arranged in
the Git repo, like flat or hierarchical by general categories like
databases, libraries, etc.; flat is probably better, search being a thing.

At the higher level, categories like error-sets or Scheme implementation
ids.  At the lower level, how do you represent the keys and values, for
SRFI 198 their slots, and hierarchy in slots.  And required, suggested,
and optional, or allowed sets of those, like my example of a memory
constrained microcontroller that might only report a couple of numbers
that you'd then have to look up elsewhere.

- Harold