>>>   That means SRFI 170 should probably rely on the proposed, upcoming
>>>   "generic external error framework" SRFI to pass OS errors to Scheme.
>>>
>>> Yes.  That's what I am proposing that SRFI 198 become, along the lines
>>> you sketched out.
>>
>> Sounds perfect. Is Harold on board with this plan?
>
> Still waking up, but yes, in so far as this generalizes SRFI 198.

Great!

Arthur: Is it OK if we make the rather drastic change of broadening the
scope of SRFI 198 from "POSIX system call exceptions" to "Foreign
exceptions" or some such? The title and much of the text of the SRFI
would be altered.

Who should do most of the writing/editing for the next draft?

> Can or should this "foreign" error scheme also allow for Scheme
> domain errors of the "srfi-170-error" type?  These straddle the
> Scheme-foreign API boundary, for example being used to provide high
> quality error messages for type errors, instead of descending down
> into C to discover and raise an error because the open call would
> otherwise be handed a number for a file name string.

Providing high-quality error messages about type errors on the Scheme
side is a very good idea.

Not sure how this should be done. Gambit just added a `define-procedure`
macro as a unified way for writing type-checked FFI procedures. Those
procedure raise particular kinds of exceptions. I presume some of the
other featureful FFIs have similar provisions. In that case, the easiest
way to implement SRFI 170 would be to simply re-use those facilities.

I still think we should not fabricate errno values except in very
exceptional cases. In particular, we should not use errnos like EINVAL
to indicate type-checking errors on the Scheme side. And since C does
not provide a standard way to carry run-time type information, C APIs
generally do not have error codes for invalid argument types anyway.

Java may be a different story, and Java implementatoin of SRFI 170 /
SRFI 198 should definitely be legit.

>> I started using the symbol 'errno in proof-of-concept code and it
>> looks surprisingly natural so I'm fine with it as well.
>
> To populate foreign-error:error-set?  Using it to describe pure
> Windows errors sounds a bit confusing, not sure if fatally so.

The idea is that there should be any number of distinct error sets. The
'errno set would be for anything you can get from C's `errno`. I think
it's clearest for users if we keep this 1:1 correspondence between the
Scheme errno set and the C errno set.

The proof-of-concept code at
<https://github.com/lassik/scheme-foreign-error-wip> currently uses
'windows as the name for the WinAPI set, and 'winsock for the Windows
Sockets set (which, as noted previously, is separate from the main
WinAPI set for some reason).