Following this argument, wouldn't it be enough for SRFI 170 to define
the following procedures:

(posix-error? obj) -> boolean
(posix-error-errno posix-error) -> symbol
(posix-error-message posix-error) -> string
(posix-error errno message) -> exception

With these procedures, SRFI 170 would be independent of SRFI 198 and
could be finalized independently.

SRFI 198 can later implement these four procedures in terms of its
foreign error objects and specify some mapping that has to be obeyed
for systems supporting SRFI 170 and SRFI 198.

Marc

Am Mo., 17. Aug. 2020 um 17:39 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> Just a quick note... Many programming language's OS API effectively
> gives you 'errno (a symbol) and 'message (a string).
>
> If SRFI 170 says:
>
> - all errors are raised as SRFI 198 foreign-status objects
>
> - The implementation should work hard to fill in the 'errno and 'message
> properties whenever possible. 'errno can freely be synthesized from
> other operating system's similar errors, but should not be entirely
> fantastical just for the sake of having it present.
>
> ...wouldn't that get us everything we urgently need and most languages
> give, with minimal effort and minimal restrictions on the final form of
> SRFI 198.
>
> If we have a property named 'errno, it makes no sense to put anything
> other than C/POSIX/Unix errno compatible values in it. Anything else
> would confuse people. Likewise, C/POSIX/Unix errno numbers are not
> portable, so clearly the value should always be symbolic (ENOENT etc.)
> instead of numeric.
>
> If we have a property named 'message (or 'text), it makes no sense to
> put anything other than a human-readable string in there. We can't
> guarantee that an English message is available in the general case, so
> 'message can be whichever localization is at hand. We can later add a
> separate 'localize-message or something to deal with that -- it doesn't
> have to be SRFI 170's concern.