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.