> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Sunday, June 28, 2020 8:08 AM
>
>>>>   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!

You're welcome!

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

Not Arthur, but this strikes me as a rather modest change, and since
it's subsuming POSIX system call errors....

Ah, per my previous observations on your exposing make-foreign-error,
and mine that we shouldn't force all users to raise an error, allowing
for them to be returned, the title should be more like "Foreign
error..." ... not even "reporting", since I'm suggesting we provide
facilities, but not be prescriptive in how they're used.

E.g. going back to microcontrollers and the like, printing to stderr
which might go to a RS-232 or JTAG debugging interface would be
allowed.  Which suggests the need for a procedure to convert a
foreign-error into a single string, or outputting it to a port so a
string doesn't have to be allocated.

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

Note I was broaching the idea that we should consider adding this to
the remit of the New, Improved SRFI 198, and I'd also add how to name
this error-set ("domain"??), not how to do that.  That said:

> 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 thank you for directing me to the above.

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

Absolutely.  Doing that from the start of my SRFI 170 implementation
later generated some bugs as the two error types were disambiguated
that I just noticed and fixed.  As a general principle, Don't Lie To
The User, not matter how good your intentions, or in this case just
moving error detection higher in the stack ... while still generating
errors POSIX might not, e.g. substituting a number for a pointer.

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

True, but we could create our own for this disjoint error-set,
particularly for memory limited scenarios were most of the error
reporting information could at compile time be used to generate
documentation the user could then use to map 'canbus 3 into
"CAN_H shorted to battery voltage."

> [ Java. ]

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

Agreed 100%

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

There will be *many* error-sets as this SRFI gets more use....

- Harold