Date: Sunday, August 09, 2020 7:40 PM
Note we need to rename the SRFI (again :-) now that it's been decided not all Foreign Interface responses are errors, and status is the least worst name we can come up with, so "SRFI 198: Foreign Interface Status Handling"??
I'd remove "Handling", since it is actually about creating and accessing foreign status objects, not handling them. "Foreign Interface Status".
OK.
[...]
BTW, for "type", do you mean what I've been calling 'error-set, with values like 'errno?
Yes.
There's no official error naming scheme either; I suppose one could be created, but it would in my implementation be at least in part duplicative of the 'foreign-procedure value. I could be swayed on this, but I think we'd then need to provide some general advice to users of the SRFI, naming is after all one of the hardest things we do if it is to be correct.
Okay, got it: no mandatory keys except 'error-set.
Which becomes 'status-set with the relaxation of this only being about errors, and Lassi and I now prefer just plain 'set.
Errr, I mean with two different names, something like like 'scheme-procedure-args and 'foreign-interface-args, although those are very long and won't make only Lassi unhappy. Probably just 'args for the ones to the Scheme procedure, and perhaps 'foreign-interface-args if you choose to go to that much trouble in providing truly excellent status objects.l
I see. I'm not sure that those even make any sense. They would have to be translated back from foreign objects to Scheme objects anyway.
True, but they might provide better insight into exactly what went wrong, without recourse to overt debugging.
[ On the 'heritage key. ]
And my position from the beginning is that humans are the primary consumers of foreign-status objects.
Even so, this is static information and will be obsolete when SRFI 170 gets incorporated into a big PDF (as has already been done for Red and ongoing for Tangerine).
But the discussions which reveal why we for example decided #f was a good value to have user-info and group-info return will still be in the SRFI 170 email list archives. Why certain decisions were made, especially why certain alternatives were discarded, can be invaluable information.
I will admit to be inspired by Lisp machines, where just about everything (although not this sort of thing) was at your fingertips.
For 'name or 'number being mandatory, we should think about a larger set including those two, in which one is mandatory. For example, in my posited use of SRFI 198 for libsodium, 'message fills this niche.
Let's keep mandatoriness out of the SRFI except for error-set.
That's what Lassi and I have homed in on.
- Harold