Final review of johnwcowan/srfi-170/srfi-170.html, part 1 through 3.3 File system temp-file-prefix hga@xxxxxx 13 Aug 2020 15:59 UTC
Re: Final review of johnwcowan/srfi-170/srfi-170.html, part 1 through 3.3 File system temp-file-prefix John Cowan 13 Aug 2020 18:18 UTC
On POSIX errnos using 'number as a key, and SRFI 198 not defining that, 'code, etc. as standards at its level hga@xxxxxx 13 Aug 2020 18:46 UTC
Re: On POSIX errnos using 'number as a key, and SRFI 198 not defining that, 'code, etc. as standards at its level John Cowan 13 Aug 2020 20:31 UTC
Re: On POSIX errnos using 'number as a key, and SRFI 198 not defining that, 'code, etc. as standards at its level hga@xxxxxx 13 Aug 2020 21:04 UTC
Clearing up confusion Lassi Kortela 14 Aug 2020 15:12 UTC
Re: Clearing up confusion, and Windows errors as POSIX errno's Lassi Kortela 14 Aug 2020 15:27 UTC
Re: Clearing up confusion, and Windows errors as POSIX errno's hga@xxxxxx 15 Aug 2020 16:50 UTC
Re: Clearing up confusion John Cowan 15 Aug 2020 00:54 UTC
Re: Clearing up confusion Marc Nieper-Wi├čkirchen 15 Aug 2020 10:46 UTC
Clearing up the previous clearing up Lassi Kortela 15 Aug 2020 11:46 UTC
Re: Clearing up the previous clearing up John Cowan 15 Aug 2020 15:03 UTC
Re: Final review of johnwcowan/srfi-170/srfi-170.html, part 1 through 3.3 File system temp-file-prefix hga@xxxxxx 14 Aug 2020 11:31 UTC
Re: Final review of johnwcowan/srfi-170/srfi-170.html, part 1 through 3.3 File system temp-file-prefix John Cowan 14 Aug 2020 13:22 UTC
Re: Final review of johnwcowan/srfi-170/srfi-170.html, part 1 through 3.3 File system temp-file-prefix hga@xxxxxx 14 Aug 2020 14:01 UTC

Clearing up confusion Lassi Kortela 14 Aug 2020 15:12 UTC

> If a universal set of facility names is off the table, then Posix errors
> could be recognized by an 'errno key, whose value is the numeric error.

That sounds exactly right to me.

> I believe Lassi's proposal is to make belonging to the universal set
> optional, unless I suppose you want it indexed in the most obvious way
> on the Schemeregistry (and of course having your set be recorded there
> is entirely optional).
>
> But 'errno is */the*/ logical and obvious key to use for the integer
> errno value.  Hmmm, who says a key can't also be used as a value, e.g.
> '(set errno errno 2 name ENOENT ....)?  A bit confusing, but not fatally
> so??  Or use 'posix as the 'set value?  Any POSIX status reporting
> that's not going to include an errno??

Sorry about the confusion.

Likewise, that sounds like exactly the right thing.

SRFI 198 is meant to let people represent absolutely any statuses of any
kind. The spectrum is so wide that we'd be hard pressed to anticipate
everything. That's why I'm advocating for 198 to be in spirit a simple
dictionary with a tag attached to it. An empty dictionary being valid as
usual.

SRFI 170 is an easy special case, since POSIX/Unix errors use the
well-known errno system and always have done so. WinAPI uses the almost
as simple GetLastError() and FormatMessage(). Other OSes probably
similar. Hence error objects for 170 are much easier to understand than
error objects in general.

If a procedure in 170 is implementated using POSIX or a POSIX emulation
library like cygwin, it should return something like (make-foreign-error
'set 'errno 'number 2 'name 'ENOENT 'message "No such file or directory"
...) as John suggests.

A 170 procedure implemented using the Windows API should probably return
(make-foreign-error 'set 'windows 'number 2 'name 'ERROR_FILE_NOT_FOUND
...).

Adding error-handling procedures into 170 is probably not useful. (Or
I'd say that if we need to add some then we have failed in designing 198
to be easy enough). All we need to mandate is that 170 errors be raised
as 198 foreign-error objects. The error handler can check (eq? 'errno
(foreign-error-ref st 'set)) and (eq? 'windows (foreign-error-ref st
'set)) and things like that.

It may make sense to add POSIX-specific keys into the error object (in
addition to the usual keys for 'errno and 'windows type errors) but I
can't think of any particular ones at the moment.

In particular, I'd stay with the generic 'set and 'number keys since
they'll make it easy to unambiguously tie error object properties into
error set enumerators later. An enumerator could be something like
(foreign-status-set-for-each 'errno (lambda (number name) ...)).

(Yes, plist keys can have values that are equal to plist keys :) Same
thing with alists, hash-tables and any other dictionary. Any attempt to
prevent that will probably result in something worse.)