>      > This name is not going to make much sense when and if 170 is
>      > incorporated into R7RS-large, in which case it will probably be
>     called
>      > (scheme posix) or (scheme posix core) or something of the sort.
>     Perhaps
>      > this facility should be migrated to SRFI 198 as well and called
>     simply
>      > "posix-error".  That way any Posix-related SRFI can raise it and
>     any of
>      > their callers can check for it.
>
> My original point (repeated here) seems to have gotten lost.  When the
> Scheme parts of SRFI 170 report an error, almost always a domain error
> like "dir must be a string", this is done by raising an error satisfying
> `srfi-170-error?`; there are suitable accessors.  This has nothing to do
> with syscalls, but is just an ordinary Scheme condition.

OK, so Scheme-side type-checking of the arguments given to the SRFI 170
implementation would also raise these exceptions. That makes sense.

However, some of those exceptions would map neatly to Unix errno errors.
So SRFI 170 errors and OS errors are two overlapping sets.

> My proposal is to rename it `posix-error?`, because the term
> `srfi-170-error?` will be less relevant in an R7RS-large world.  I also
> suggest moving it to SRFI 198 so that other Posix-based SRFIs like the
> terminal and subprocess SRFIs can make use of it.

I continue to advise against use of the term "POSIX" instead of "Unix"
(or more generically, "OS") unless there is a clear intent to limit a
SRFI's functionality to such things that have already been standardized
by POSIX.

>     - Cygwin/MSYS programs can probably access both Unix syscall emulations
>     (errno) and WinAPI calls (GetLastError()). There needs to be a
>     meaningful way to distinguish between the two.
>
> Cygwin programs can, yes.

That means SRFI 170 should probably rely on the proposed, upcoming
"generic external error framework" SRFI to pass OS errors to Scheme.
That gives 170 implementors full flexibility in representing
errno-based, WinAPI-based and any other OS errors.

>     - SRFI 170 procedures should be implementable using either Unix or
>     Windows syscalls (or equivalents in other operating systems). This
>     implies that SRFI 170 procedures can raise exceptions based on Unix
>     errors, WinAPI errors, or a mix of the two.
>
> Chicken's posixunix and posixwin.scm files shows one way to do this;
> because Chicken compiles to C, these files have embedded C.  Posixwin
> takes advantage of the Win32 UCRT, its native (but weaksauce) mini-Posix
> <https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/crt-alphabetical-function-reference?redirectedfrom=MSDN&view=vs-2019>,
> but goes beyond it where necessary.

Interesting to know. This is the first time I hear of those MS
libraries; I have no competence to say anything about them.

>     - "POSIX errno" is a misnomer since it copes identically with errno's
>     that are not in POSIX. "Unix errno" or just "errno" would be
>     appropriate.s
>
> Actually "errno" is defined by ISO C.

errno is defined by C and the definition is inherited/extended by POSIX,
but the set of known errno values is further extended by many Unix-like
operating systems.

Perhaps we should simply call it "errno" in Scheme. Is that too
confusing to Schemers who are blissfully unaware of C-level stuff?