> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Saturday, June 27, 2020 4:34 PM
>
> In the README here: <https://github.com/lassik/scheme-foreign-error-wip>

First impressions:

Symbol and number are I guess an and/or.  Some APIs provide numbers,
like POSIX errnos and I think Oracle errors, whereas PostgreSQL's are
alphanumeric.  POSIX errnos also have associated define strings; the
SRFI 198 API currently has a procedure for mapping numbers to those
strings, efficiently represented as symbols, which I suppose would in
this scheme be used in populating the symbol key in the alist handed
to one of the error creation procedures.

Foreign "procedure" might be too specific, e.g. the PostgreSQL wire
protocol has "messages" rather than "procedures."  Maybe something
like "action"??

Do we want to expose make-foreign-error in the API?  The style John
has used so far hides that inside the function that raises an error.
But that's because he has these APIs raise errors, we shouldn't
preclude someone from creating a foreign API where errors are returned
instead of raised.

I have no informed opinion on how locales should be handled, except to
wonder if a single running process might need to handle multiple ones.
Which I can see for a server, each user potentially specifying their
own.  At first glance, making it an optional argument to
foreign-error:message sounds good, albeit expensive in space.  But it
gets awkward if the user has a particular locale that's not in the set.

Here I'm going to ask if there's any good reason to not explicitly
break out "arguments" from data.  That information is so valuable we
should strongly encourage developers to include it, without making
it mandatory.

Of course, this fits cleanly into turning data into an alist, but how
about adding a standard set of key symbols that might appear there,
like 'arguments, and:

As a partial answer to "srfi-170-error MUST DIE!!!", I repeat that
knowing the "origin" of an error is valuable, especially once 170 is
absorbed into R7RS-large.  Having 'origin or whatever as one of the
standard possible data alist keys would satisfy my desire, in this
case it for example clues the user to look at its discussion.

At this point, populating each error constructor invocation is getting
onerous.  Conventions, or a mechanism to set defaults for the contents
of a file, library, or whatever would I think be welcome, albeit the
latter being somewhat dangerous.

- Harold