> If a universal set of facility names is off the table, then Posix errors
> could be recognized by an 'errno key, whose value is the numeric error.

That sounds exactly right to me.

> I believe Lassi's proposal is to make belonging to the universal set
> optional, unless I suppose you want it indexed in the most obvious way
> on the Schemeregistry (and of course having your set be recorded there
> is entirely optional).
>
> But 'errno is */the*/ logical and obvious key to use for the integer
> errno value.  Hmmm, who says a key can't also be used as a value, e.g.
> '(set errno errno 2 name ENOENT ....)?  A bit confusing, but not fatally
> so??  Or use 'posix as the 'set value?  Any POSIX status reporting
> that's not going to include an errno??

Sorry about the confusion.

Likewise, that sounds like exactly the right thing.

SRFI 198 is meant to let people represent absolutely any statuses of any
kind. The spectrum is so wide that we'd be hard pressed to anticipate
everything. That's why I'm advocating for 198 to be in spirit a simple
dictionary with a tag attached to it. An empty dictionary being valid as
usual.

SRFI 170 is an easy special case, since POSIX/Unix errors use the
well-known errno system and always have done so. WinAPI uses the almost
as simple GetLastError() and FormatMessage(). Other OSes probably
similar. Hence error objects for 170 are much easier to understand than
error objects in general.

If a procedure in 170 is implementated using POSIX or a POSIX emulation
library like cygwin, it should return something like (make-foreign-error
'set 'errno 'number 2 'name 'ENOENT 'message "No such file or directory"
...) as John suggests.

A 170 procedure implemented using the Windows API should probably return
(make-foreign-error 'set 'windows 'number 2 'name 'ERROR_FILE_NOT_FOUND
...).

Adding error-handling procedures into 170 is probably not useful. (Or
I'd say that if we need to add some then we have failed in designing 198
to be easy enough). All we need to mandate is that 170 errors be raised
as 198 foreign-error objects. The error handler can check (eq? 'errno
(foreign-error-ref st 'set)) and (eq? 'windows (foreign-error-ref st
'set)) and things like that.

It may make sense to add POSIX-specific keys into the error object (in
addition to the usual keys for 'errno and 'windows type errors) but I
can't think of any particular ones at the moment.

In particular, I'd stay with the generic 'set and 'number keys since
they'll make it easy to unambiguously tie error object properties into
error set enumerators later. An enumerator could be something like
(foreign-status-set-for-each 'errno (lambda (number name) ...)).

(Yes, plist keys can have values that are equal to plist keys :) Same
thing with alists, hash-tables and any other dictionary. Any attempt to
prevent that will probably result in something worse.)