> A Scheme implementor who wants to have his POSIX calls, for SRFI 170
> and/or future SRFIs done by our team, conform to those SRFIs, could in
> theory change or augment his C level error signaling to always conform
> to our method, or a proper superset including it.  He is after all
> presumably already reporting the integer errno in one way or another.

That's one of the main draws in having 'set correspond to the C level,
and storing other useful stuff in 'set-independent properties. The
Scheme implementation's lowest-level C API wrappers can each be reused
for multiple higher-level wrapper.

However, the Scheme implementor would still have to use foreign-status
objects for most or all C-level errors, which they may not want to do.
Since foreign-status is an abstract data type, its interface can be
implemented by more than one native type.

>> Namespacing is not such a problem when we have the Scheme Registry to
>> help avoid conflicts.
>
> But while I haven't read for real the proceeding emails, and I recall
> your having a proposal, the most natural way to partition the files
> for SRFI 198 errors is by 'set and my previously suggested 'subset
> (the latter inspired by '(set sqlstate subset postgresql/oracle/etc.)).

A labeling system where each entity has zero or more tags, is generally
better than a system where each entity belongs to exactly one category.
Humans are not good at categorizing things in the presence of unknowns.

Hence I would no longer worry at all about partitioning the properties
by set. The original plan was to partition the error numbers and symbols
by set, which is what the concept of the set was about. Originally I
also assumed that it would make sense to partition the other properties
by set, but now that we've coined many new properties, it no longer
seems that way.

We'll define more resilient properties if we start from the assumption
that they are set-independent. 'facility or 'filename is a good example.
Lots of external systems have facilities and filenames. That forces us
to define it in such a way that it's adaptable to unknown situations.

>> The 'errno property would be to contain a (possibly) synthetic errno
>> value. Since it's synthetic, it should be possible to give it to go
>> along with any 'set.
>
> John's already covered this in his latest message.  This could also
> be a job for subsets, e.g. '(set posix subset native-windows).

I don't get it. This way you'd lose the native WinAPI error code and
gain nothing over a separate 'errno property.

> As far as I know, POSIX errors always have a specific errno, if not,
> a return of e.g. NULL for e.g. getpwuid/getpwnam() means this is not
> an error, I just can't find that user in *this* system, common when
> moving files from system to system.
That's right, errno can represent all POSIX errors. There may be a few
individual functions that report error some other way; not sure.

>> The symbol is primary -- the numerical errno values are less useful as
>> they vary by OS. That's why the synthetic 'errno property should also
>> use symbols rather than numbers.
>
> That might not be too much of a burden to an implementor raising an
> error at the C level, since that's the natural level for establishing
> the system specific errno number to errno #define name mapping.

The implementor has to do whatever it takes to get the symbol, even if
it's tedious work. There's unfortunately no reasonable way around it.

For Unix errnos, the implementor needs a groveler similar to this:

#define GROVEL(e) case e: return #e
const char *errno_number_to_symbol(int number) {
   switch(number) {
#ifdef EFOO
GROVEL(EFOO);
#endif
#ifdef EBAR
GROVEL(EBAR);
#endif
// ...
   }
   return NULL;
}

That should probably be exported as a Scheme procedure for any Scheme
code that needs it.

For something like WinAPI, one needs to hard-code a
winapi-number->errno-symbol table.

As a separate issue, dealing with numbers instead of symbols in a
high-level language like Scheme should be avoided. This would be
advisable even if all errno values were the same across all operating
systems.

>> It's not lying to the user if the 'errno property is well-known and
>> deliberately designed to be synthetic where the real errno is not
>> available. We could call it 'synthetic-errno for emphasis, but I'm not
>> sure it adds anything.
>
> If we're not starting with a real errno number, if it's truly
> synthetic, it's a lie.  A name less overt than '*synthetic*-errno-name
> for both real and synthetic would satisfy me on this account.  Or
> combing both my "perhaps justifiable" to lie and subset idea, using a
> 'windows subset key would signal to the user that he's not getting a
> "real" errno name.
>
>> A real errno coming from that C variable would carry '(set errno symbol
>> EINTR number 4) in addition to '(errno EINTR). That's how you can
>> distinguish the real from the fake.
>
> Ugh, that subverts the desire to make a pure Windows version of
> e.g. SRFI 170 look and feel as much as possible like one based on a
> native POSIX interface.

POSIX is just an interface. All interfaces are based on lies. I continue
to not get the fascination with POSIX over and above other things that
are also useful. There is no POSIX OS; there's Linux, FreeBSD, MacOS,
Cygwin, etc. all different OSes offering a POSIX-compatible interface.

>> However, note that C APIs also fake errno values quite often.
>
> Sure, but I don't have to approve of that ^_^.
>
>> By no means is it guaranteed that a C errno comes from the
>> kernel. It can just be a lower-level synthetic errno and we have no
>> way of knowing. It's all relative.
>
> "It's all relative" are weasel words for "I'm lying."  In the Anglosphere
> for more than a century when non-scientists glommed onto Einstein's
> formulation of "Special Relativity", which defined exceptions to
> Newtonian mechanics (e.g. at speeds approach c, the speed of light).

Approach the speed of lies?

All interfaces are based on lies. Everything in a computer is a lie -- a
crude approximation of some goal outside the computer, that goal also
being a lie, merely a more sophisticated one. The art is to lie well. In
that sense computing is similar to all other mental pursuits.

Von Neumann: "The sciences do not try to explain, they hardly even try
to interpret, they mainly make models. By a model is meant a
mathematical construct which, with the addition of certain verbal
interpretations, describes observed phenomena. The justification of such
a mathematical construct is solely and precisely that it is expected to
work."

>>> [ What about a 'success? key. ]
>>
>> WinAPI also has lots of functions that return NULL vs non-NULL (or FALSE
>> vs non-FALSE) to mean failure vs success. There are tons of C APIs based
>> on that principle out there.
>
> Which tells me to rename my tentative "generic-unix-lib" to "generic-c-lib",
> although I already anticipated it being fine for any libraru that has a
> binary success return, 0 vs. -1, NULL vs. non-NULL, FALSE or TRUE, it's all
> the same thing for my purposes, and the exact values are irrelevant for
> end users.

What specific thing do we aim to encapsulate? Do you want to preserve
the precise return value as well as derive a success-vs-failure boolean
from it?

>> But why have the 'set property when the number is not part of a finite,
>> grovelable set? If all properties default to #f, then 'set #f is a
>> natural way to say that we don't have one.
>
> I'm not sure I really need to justify a why, vs. you justifying a why
> not.  Your intuition that this is bad is worth respecting, but for me
> that's just a clue to then come up with rational arguments, and to
> then weigh them before making decisions.
>
> But I have several, starting with it being the primary key for
> organizing Schemeregistry.  If you don't want to make 'set required,
> you need a proposal to make that corner of the registry sane for people
> who put stuff into it and who use it (forgive me if you've already done
> that and I haven't read it yet, I'm working backwards in the emails).

I fully agree that we should discuss based on reasons, but I already
gave my reason: An enumerable set is a definite, useful concept. I think
we shouldn't stretch its definition to include things that don't
naturally fit.

I fully agree that we should include information like "this status came
from libsodium". It's just not clear in which property to put that info.

There may be many cases where one error set is shared by many different
libraries. In fact, many C libraries unrelated to POSIX probably use
errno codes to report their errors.

Sticking to well-defined concepts aids clear thinking and problem
decomposition. Since we can't predict the future, clear thinking is the
only safeguard we have against design mistakes. Not a very good one, but
at least it's something. Scheme has done well by relying on it. Many
other languages have taken lots of shortcuts and not kept as clean over
the long term.

As argued at the beginning of this mail, I no longer believe we should
be eager to tie properties into sets, other than the obvious
'code/number and 'name/symbol. I've had several bad experiences where I
though "hey, I'll be clever and divide all things neatly into sets" only
to be outsmarted by reality soone after.

> John has a very good one for guards.

His example didn't take into account that if all properties have #f
defaults, we can easily test whether any property is eq? to some value
without knowing whether that property exists.

> Sorry if I haven't been clear, ***libsodium and many other C libraries
> do not have a number to report as such***.  Where I take "number" to
> be something like an integer errno, or a 5 byte SQLSTATE.
>
> We translate its specific UNIX style 0 vs. -1 return into either a
> binary 'success? value, or just make that subkey (which is optional
> to define and include in the status object) only return errors. If
> it never has to report a success as a status object, the UNIX silence
> is success principle, which is also used as the fundamental error
> handling paradigm for SRFI 170, 205, etc.

Good point. On success we simply don't raise an error, so any raised
'libsodium status is an error status.

I agree with you that we need to have _some_ property that says
'libsodium. I'm not sure 'set is the right one.

'errno is clearly an error set, but all errno errors don't come from
POSIX either.