Am Mo., 17. Aug. 2020 um 18:02 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:

> > 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.
>
> Indeed, I think that would be enough. In fact, not even the raise
> procedure `posix-error` needs to be exported since each SRFI 170
> implementation can internally raise errors whichever way it finds best.

I added it because the user may want to add some "posix-like/SRFI
170-like" procedure that shall raise be able to raise compatible
errors (e.g. when it needs to forge posix errors).