Added SRFI 198 to the CC list.
Date: Sunday, August 09, 2020 11:07 AM
Okay, here's what I've done and pushed to johnwcowan/srfi-170:
[ Editorial changes, or still to be implimented in Chibi Scheme. ]
4. Reduced 3.1 to just foreign-status?. I'd like to add some way to get the Posix name of the errno, which is the minimum necessary information, but things still aren't stable enough. Is SRFI-198 going to expose:
a) only foreign-status-plist,
I don't recall that being a option we've discussed. But it strikes me as an excellent addition to the API, give the user all the data in one call in a tractable form, and then he doesn't have to call foreign-status-ref a bunch of times, plus it tells him all the keys available. But I see no reason not to also give him the very specific:
b) foreign-status-ref as well, or
Which is definitely still part of the API, but I'm going without the option of it "transparently" calling lambdas that happen to be values, an issue we've hashed out pretty thoroughly. Too much complexity and irregularity without enough gain, and at last count no real gain for the localization option.
Note defining localization so it can be written up is the big roadblock in front of the next SRFI 198 draft (having no dog in that hunt, I've not been following the discussion, just been told it's gone well).
c) also convenience procedures for simple cases like type (which is mandatory anyway) and numeric and alpha codes?
What would the first be?? Or is that foreign-status? Ditto for numeric and alpha codes, unless that's part of localization.
Anyway, one thing we can absolutely require in an SRFI, here the 'errno error-set for all of our POSIX SRFIs starting with 170, is mandatory key/value pairs for foreign-status objects.
That must of course include the errno, e.g. 'errno [fixnum], and except for embedded (low memory) implementations, my pet project/pain point you also want above only needs a name for the key, I've used 'symbol in the SRFI 198 document so far, and to state that the value must include the C define string, such as "ENOENT" (not that the value itself has to be a string). Otherwise I personally want to make what are probably "strong suggestions", i.e. the calling Scheme procedure name, and the name of system or library call that failed.
And they need to be part of the errno error-set convention as will be documented in the Schemeregistry, as in, you might not include them, but if you do, they have mandatory keys like 'scheme-procedure and 'foreign-interface. And both of those should be general conventions for SRFI 198 status objects.
Definitely only a "strongly suggest" is 'args, the list of arguments handed ... whichever of the previous, probably should require 'scheme-procedure. Or make two args keys, one for each. And a very optional, but also general convention 'heritage, here something like "SRFI 170", to give the user hints where to find original discussions of a procedure once it's for example been assimilated into R7RS-large.
'message is also a general convention for all error-sets, but again not mandatory, especially in the embedded/low memory domain.
- Harold
And while text for getpwuid_r is not as clear, and see Issue 6 at the bottom, but implies to me about the same thing. It's definitely not unheard of when restoring archives to get bogus for the system user and group ids, we should consider not raising an error and have the procedures return #f instead of returning a user-/group-info record.
That works great too.