I think it's unwise to have mandatory properties. What's the rationale
for them in general and for this one in particular?
The rationale for a general classification property, call it type or whatever, is that it gives the exception handler an indication of what other properties it can expect to find. If a foreign-status object is a Posix error, it will have an errno and a #define name. If it is a database engine error, it will have a SQL state and possibly a proprietary number and symbol too. If it is a libsodium-style system, it will have none of these, only a message.
My intuition says we're mandating too many things for programmers who'll
be facing situations we don't know. We should mandate the bare minimum.
The bare minimum is all properties optional with #f defaults.
I think that's subminimal. If there are no keys at all, all we know is what a baby tells us when it howls: "Something's wrong". If there are keys but no classifier key, we don't know how to interpret what we are told, because the same keys inevitably mean different things in different contexts. So again, all we know is "Something's wrong".
>> 2) The foreign-status-plist procedure guarantees that 'set is the
>> first key (which means that which set you are using is always the cadr).
> We have to decide if we're going to have a foreign-status-plist.
> There's an argument for having both it and foreign-status-keys.
I agree that we should have both.
(eq? 'errno (cadr (foreign-status-plist st))) is definitely not a good
idiom. Not only is "cadr" the kind of obfuscation they don't have in
other languages like Python, but implicitly relying on the concrete
structure of the plist is more obfuscation on top.
Even Python programmers deal with concrete types like lists, sets, dicts, etc. But I agree that it's a minor point. My reason for wanting the type to be first is so that pattern matching can provide a first-cut analysis of foreign-status objects.
I feel I've failed to clearly communicate my point about abstraction.
That's probably my fault.
We shouldn't be abstract for the sake of being abstract. We should be abstract only when there is a substantial gain from having more than one representation.
My dictionaries pre-SRFI is meant precisely to abstract over sets (in some cases, sequences) of key-value pairs. But that's useful precisely because there are nearly a dozen different such concrete sets or sequences now, and it's useful to be able to handle them uniformly. As such, if you strongly prefer alists to plists, I'm fine with that too.
Let's avoid the name 'facility for any of the core stuff in the SRFI.
That word is commonly used by external logging systems (syslog, VMS,
...). If we want to represent statuses in those systems, we should use
the 'facility property for something that maps closely to those systems'
concept of a facility.
+1