Am Mo., 17. Aug. 2020 um 18:25 Uhr schrieb <xxxxxx@ancell-ent.com>:

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

We live in an open world :), by which I mean that if SRFI 170 just
specifies "posix-error-errno" and "posix-error-message", it does not
mean that a later SRFI (like SRFI 178) or some implementation cannot
define "posix-error-who" or "posix-error-irritants" on top of it.

This works as long as SRFI 170 doesn't say that a posix error object
consists of an errno and a message, which I deliberately didn't say.