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