Date: Wednesday, June 24, 2020 9:39 AM
Based on what I now understand, there will be *mostly* just one SRFI 198 implementation, except for errno-string and errno-name. Your version will be Chibi-specific but should work on any OS that supports strerror(). My version will work on any Scheme but only on OSes for which I have a formatted version of errno.h. We'll put both of them in the SRFI 198 repo.
OK, although Linux is in the category of not having a formatted version of errno.h, and even OpenBSD has the real content in sys/errno.h.
Your SRFI 170 should of course use SRFI 198 with your implementation.
"Sample implementation" is a technical term of standard-writing: it means that if the implementation doesn't agree with the documentation, the documentation wins. A sample implementation is opposed to a "reference implementation", which means that in case of disagreement the implementation wins: in a real sense the implementation *is* the standard. (This is true for Perl 4 and Python, for example.)
Ah, I see, I should have been using another term for my Chibi Scheme SRFI 170 implementation to signal its non-production quality.
A certain 1-kg platinum-iridium cylinder in Paris used to be the reference implementation of the kilogram; now it's a sample implementation. Lots of people get this wrong and call them all reference implementations, including older SRFIs, but all SRFI implementations are samples in this technical sense. There is no implication that sample implementations are inferior, even if the cylinder and its copies elsewhere are gaining about 50 micrograms per century.
Instead of, you know, paying attention to the actual data and thinking hard about how the universe might be slowly changing on us (seriously, this is "science" by consensus, ignoring the data).
I've added and pushed the syscall-name argument to make-syscall-error and the corresponding accessor
syscall-error:syscall-name, and merged your latest repo.
SRFI 198 looks good, although I now notice I need to handle errno-names as symbols (not visible to SRFI 170, but should be fixed and added). However, your repo of SRFI 170 hasn't yet been updated to include it. After doing some other queued up stuff for a while, I'll work on the assumption SRFI 170 will be updated in due course, and upgrade my SRFI 170 implementation of SRFI 198 to be in full compliance, then create a focused version for SRFI 198.
- Harold
The Chibi Scheme sample implementation of SRFI 198 I supply won't be different, except it'll be complete and in sync with that SRFI.
I thought one of the implicit points of SRFI 198 is that it can create a disjoint type that can be included and shared by SRFI 170 and other POSIX interface implementations. The interim SRFI 198 I just created for my Chibi Scheme SRFI 170 sample implementation does just that, so I guess the answer to my question is that the latter should continue to import SRFI 198, and then export the below mentioned names.
- Harold
----- Original message -----
Date: Tuesday, June 23, 2020 12:35 PM
I think because of the sample implementations being different, SRFI 170 should export its own implementations. So no, people should not import both 170 and 198.
All of syscall-error?, syscall-error:errno, syscall-error:message, syscall-error:procedure-name, and syscall-error:data are mentioned in the current SRFI 170 draft, but they come from SRFI 198, and are easy accessed by importing it. Should they also be exported by SRFI 170??