> From: "Marc Nieper-Wißkirchen" <xxxxxx@nieper-wisskirchen.de>
> Date: Monday, August 17, 2020 10:51 AM
>
> 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.

While there are objections to them for Scheme implementations that
have real debugging capabilities, there are additional ones however
you get them, specifically:

'scheme-procedure, which one made the raise call
'foreign-interface, which POSIX function reported an error
  (and that requires a lot more out of a debugger)
'args, the arguments the Scheme procedure was called with

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

We for example might want to add posix-error-keys, which is just
foreign-error-keys, and in the same way posix-error-ref to mirror
foreign-error-ref for the above keys, and keys we haven't yet thought
of.  For example, I don't want to limit the options of future
SRFI 170 implementors.  Required keys?  Certainly?  No additional
ones ever...?

Strictly limiting the data you can get from a raised error is very
much not in the spirit of SRFI 198, although it fits the scsh
errno-error procedure that started this whole saga.

- Harold

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