> 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.

Good point. I was only prepared for error sets that have both symbols
and numbers. But we should support symbol-only and number-only as well.

> 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.

Exactly.

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

Also a good point. I can't think of a good term. Maybe we should collect
many error sets and then revisit the question.

> 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.

Being able to create an error object without raising it will surely
prove to be valuable.

I'm neutral on whether or not the SRFI should provide its own `raise`
procedure; I'll let you and John decide.

> 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.

We'd best structure the API so that we are prepared for that
possibility. I can't think of any concrete examples; maybe switching the
OS / desktop environment locale while the Scheme program stays running?

> 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.

It should probably return #f if the caller gives an explicit locale and
we don't have the requested message in that locale. Then the caller can
try another locale, omit the locale argument, or give up.

> 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:

If by "arguments" you mean procedure call arguments, it's a very good
idea to support carrying arglist information in the exception object.

I don't have an opinion on whether to have a separate user-data alist,
or a single alist of all properties where some keys simply have standard
meanings specified by SRFI 198.

Similar concerns apply to a generic logging framework with pluggable
backends (file, pipe, syslog, json lines, etc.). We could perhaps design
a logging framework in tandem with SRFI 198.

> 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.

Sounds good.

> 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.

Good point. Agreed. I don't have any proposal for the details thought up.