>> The question is what types it is required to be disjoint from.
>
> OK, so plists, no matter how distinguished on the inside, are not
> acceptable foreign-errors/conditions/statuses.

Should we list the particular types from which foreign-status should be
disjoint?

>> A question: is it expected that only a single property's value
>> requires locallization?
>
> You tell me!  I would think absolutely not, I can't imagine the SRFI
> restricting localization to just one key like 'message.  Instead we
> could specify one key/value pair like 'message will be localized if the
> implementation does localization, and say the conventions for
> localization of other key/value pairs are all applied to whatever keys
> the error/condition/status-set collection declares might be localized.

In addition to a message, PostgreSQL may return a separate "detailed
message" as well as a "hint" with troubleshooting tips. That's three
different messages, which I presume can all be localized.

So being able to localize more than just the 'message field is good, and
it would be nice to agree on a standard calling convention.

Transparently calling lambdas is a particularly nice way to solve
problems like this, since we don't have to decide ahead of time which
properties need a lambda (for things like localization).

>>     > - Plist keys should be symbols.
>>
>>     Why not "must" be symbols?  Provides one way to validate the plist.
>>
>> I think the reference is to them being keywords in systems that have
>> keywords that are disjoint from symbols.  My inclination is not to
>> bother with keywords here.
>
> And not have the SRFI text require that all keys must be symbols?
> Flexibility at the cost of portability....

(make-foreign-status 'errno 'EINTR 'code 4) looks almost like a keyword
call, so keywords are bound to come up at some point in some context...
That's why I would prefer to handle them now. AFAICT the foreign-status
constructors are the only places in the SRFI where they matter.

>>     We ***really*** want to encourage this paradigm.

(I interpret this as: really want to encourage raising exceptions.)

>> We might want to return a success HTTP status but raise a failure
>> status, though.

Yes. Some Python library had a ".raise_status" method you needed to call
manually to raise 404's and the like as exceptions. I always forgot it.

> There's also the question of whom does what.  A Scheme server process
> would generally want to return failure statuses instead of halting and
> catching fire, one reason we keep make-foreign-/whatever/ in the API,
> but a Scheme client for it might want to raise a non-continuable
> exception because it believes the error is at its end, or it simply
> can't continue.

Sounds reasonable.

> And in the SRFI text we require raise-foreign-error to
> first call make-foreign-/whatever./

Does it matter to the spec how these internals are handled?