>From: Lassi Kortela <xxxxxx@lassi.io>
>Date: Sunday, June 28, 2020 6:31 AM
>
>>  OK, so Scheme-side type-checking of the arguments given to the SRFI 170
>>  implementation would also raise these exceptions. That makes sense.

See below, I'd like that.

>> Well, it doesn't have to.  Most SRFIs just use `assume` for dealing with
>> domain errors.  But for whatever reasons (I'd like to know what they
>> are), Harold chose to actually raise conditions of a specific type that
>> has nothing to do with what we are now calling external errors.

See previous messages on the usefulness of origins, plus I needed
*something*, and neither of us thought about R7RS-large at the time.

>> Now maybe these exceptions don't actually need to be shared with
>> any other SRFI.  All I am saying is, they have to have a different
>> name.

I.e. not "foreign-error"?  Have a nearly completely parallel generic
error reporting system for these domain errors detected in Scheme code?
See below.

>>  However, some of those exceptions would map neatly to Unix errno
>>  errors.  So SRFI 170 errors and OS errors are two overlapping sets.
>>
>> Not really.  Errors in srfi-170.scm are either raised by errno-error if
>> they are external or by posix-170-error (THIS NAME MUST DIE!) if not.

This is a disproportionate attack on a quick hack which is not part of
an API, and trivially replaceable.

> OK, so OS errors raised by SRFI 170 would fall under the newfangled
> generic-foreign-error SRFI 198 framework. LGTM.

Indeed, this is the exact sort of usage "the newfangled
generic-foreign-error SRFI 198 framework" is intended for.

>>  [ POSIX too specific, especially when we fold in Windows for
>>    e.g. SRFI 170?? ]

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

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.

>>  Perhaps we should simply call it "errno" in Scheme. Is that too
>>  confusing to Schemers who are blissfully unaware of C-level stuff?
>>
>> Eh, I'm okay with that. Dr. Google will educate them if necessary.

Dr. Google is getting less and less useful as time goes by, but some
things like "errno" should stay useful in its hands.

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

- Harold