Email list hosting service & mailing list manager

The name "srfi-170-error" John Cowan (27 Jun 2020 14:51 UTC)
Re: The name "srfi-170-error" Lassi Kortela (27 Jun 2020 14:57 UTC)
Re: The name "srfi-170-error" John Cowan (27 Jun 2020 18:01 UTC)
Re: The name "srfi-170-error" Lassi Kortela (27 Jun 2020 20:57 UTC)
Re: The name "srfi-170-error" John Cowan (28 Jun 2020 03:38 UTC)
Re: The name "srfi-170-error" Lassi Kortela (28 Jun 2020 11:31 UTC)
Re: The name "srfi-170-error" hga@xxxxxx (28 Jun 2020 12:49 UTC)
Re: The name "srfi-170-error" Lassi Kortela (28 Jun 2020 13:08 UTC)
Re: The name "srfi-170-error" hga@xxxxxx (28 Jun 2020 13:54 UTC)
Re: The name "srfi-170-error" Arthur A. Gleckler (28 Jun 2020 15:21 UTC)
Re: The name "srfi-170-error" hga@xxxxxx (27 Jun 2020 15:19 UTC)
Re: The name "srfi-170-error" Lassi Kortela (27 Jun 2020 15:22 UTC)
Re: The name "srfi-170-error" hga@xxxxxx (27 Jun 2020 16:02 UTC)
Generic C API error SRFI Lassi Kortela (27 Jun 2020 16:16 UTC)
Re: Generic C API error SRFI John Cowan (27 Jun 2020 18:23 UTC)
Re: Generic C API error SRFI Lassi Kortela (27 Jun 2020 20:45 UTC)
Re: Generic C API error SRFI hga@xxxxxx (27 Jun 2020 21:09 UTC)
Re: The name "srfi-170-error" John Cowan (27 Jun 2020 16:31 UTC)
Re: The name "srfi-170-error" Lassi Kortela (27 Jun 2020 16:55 UTC)
Re: The name "srfi-170-error" hga@xxxxxx (27 Jun 2020 17:06 UTC)
Error collections Lassi Kortela (27 Jun 2020 17:08 UTC)
Re: The name "srfi-170-error" hga@xxxxxx (27 Jun 2020 17:20 UTC)

Re: The name "srfi-170-error" Lassi Kortela 28 Jun 2020 11:31 UTC

>     OK, so Scheme-side type-checking of the arguments given to the SRFI 170
>     implementation would also raise these exceptions. That makes sense.
>
> 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.  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.
>
>     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.

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

>     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.
>
> Well, that is the case for SRFI 170.  They don't have to be implemented
> via Posix syscalls, but they are Posix functions.

I'm not yet convinced that it's the case even for SRFI 170, but that
question will be settled as a side product of completing implementation
and testing so there's no need to debate it :)

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

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

I started using the symbol 'errno in proof-of-concept code and it looks
surprisingly natural so I'm fine with it as well.