Date: Monday, June 22, 2020 2:11 PM
I changed the argument name. Is there any reason why it should not be a symbol? Granted, it will need to be translated to a string by errno-error.
Only that if so, you should change the name back, change argument name and accompanying text in errno-error,
Done.
and syscall-error:procedure should be that, along with its explanation.
I'm not sure what you are saying here. I'm renaming syscall-error:procedure to syscall-error:procedure-name; is that what you meant?
I was mistaken: I think it should be syscall-error:procedure-name and a string, or drop the "-name" for all cases and keep it the symbol of the called procedure. Which should always print as something useful, and is generally all around more useful.
Note for implementors, this SRFI requires access to POSIX errno and strerror, so all implementations will be system specific.
It actually doesn't require errno, just strerror, because both errno-error and make-syscall-error accept an errno argument.
I suppose so....
For us, I'll note it's trivial to add the specification of an API for those to the SRFI, thus making what's above portable. errno takes no arguments and returns an integer,
I don't much like exposing this, as it is easy to misuse if there is in fact no error.
I don't get this at all. Who do you expect might misuse it, and how?
Normally this SRFI would only be used by people who are writing POSIX interfaces. In any case, any user could put any number he wants for the errno into errno-error and raise a bogus exception.
[...]
Your ideas sound good, and you're of course right about implementations, which should hide however this [errno to C define name] lookup is implemented.
In the sample implementation it's going to be done with cond-expand, so that to add a new version of errno.h, you just add another cond-expand clause to 189.sld that includes my-os.inc (rather than linux.inc, freebsd.inc, etc. etc.) So it is a package-time issue rather than involving stubs of any sort. This provides the data needed for the errno-string and errno-name procedures, on which everything else is built.
So the developer of an implementation can use any means he wants to extract the numbers and define names from the include files. Yeah, that's a better idea, and isn't there a whole lot of machinery available to do that sort of thing? In that case, it would be nice to include script(s) that call a C preprocessor, and use standard UNIX text manipulation tools to generate .inc files.
I've also rewritten the 3.1 section of SRFI 170 to link to SRFI 198, to briefly summarize the parts that should be exposed (predicate and accessors) to the SRFI 170 user, and to document srfi-170-error? and the associated accessors.
Modulo the above mentioned -name string vs. symbol, it looks good. Nits: would replace the period at the end of the first sentence with a colon. The dash making "errno-based" a compound word strikes me a gratuitous. I'd change "The accessors return ... and a list of relevant objects, possibly the arguments of the system call." to "... objects, ideally including the arguments of the system call." I want to nudge implementers to make their errors as useful as possible.
Will look at the updated SRFI 198 later.
- Harold