> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Thursday, August 13, 2020 1:58 AM
>
> Sorry, I have to disagree with all these proposals on technical grounds.
>
>>> While in principle 'set is just another key in the plist, I suggest
>>> the following two rules:
>>>
>>> 1) If 'set isn't present in the constructor, an error is signaled.
>>
>> That's fine; this already happens in raise-foreign-error, and it's easy
>> to have make-foreign-status do that.  Only issue I see is that servers
>> making foreign status objects will have to be careful if they don't want
>> to crash in such situations.
>
> I think it's unwise to have mandatory properties. What's the rationale
> for them in general and for this one in particular?

set/probably no longer facility is unique in "dividing the universe of
statuses."  I'm anticipating this corner of the Schemerepository will
use sets to divide conventions, very possibly one file per set.  Note
it's the *only* mandatory property, it's entirely legal to make a
status or raise an error using only it, as I do in a couple of examples.

BTW, it's occurred to me that we should add a 'sub-set key.  Maybe for
'sqlstate as you and John have explored, where SQL RDBMSes that follow
it would naturally have that as the 'set, and e.g. 'postgresql as a
subset.  Just checked and it even covers connection failures.

And I've identified what I'm currently naming "generic-unix-lib" for
libraries like libsodium that return only a sentinel value like -1 on
error, 0 on success.  It has no structure beyond that, except of
course for what's naturally covered by the standard keys of
scheme-procedure, foreign-interface, and 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.

But at least one properly, whatever it is?

> If a system can return only the error message, that's better than
> nothing. Absent properties are the same as #f, so (eq? 'errno
> (foreign-status-ref st 'set)) can still be used to test it even if it's
> #f. A set of #f means unknown, but other useful information like the
> message can still be known.

I can see scheme-procedure and message, for example, or as you say,
even message alone providing useful error reporting....

So while we have to require least one key (?), you say we shouldn't
enforce our will by insisting all uses of SRFI 198 be neatly
subdivided into sets...?

That's a legitimate argument, I don't think your intuition is broken.

>>> 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).
>>
>> That's a very good idea.
>>
>> 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.
>
> (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.

Presumably if you really care about this will check for 'set, or
whatever you expect to be there using foreign-status-ref, I am
requiring status objects be an abstract type.  Extracting every key
and value so a programmer, especially an end user, can do whatever
he needs with the whole "set" of them except for mutating the list is
the objective of foreign-status-plist.  Otherwise he has to call
foreign-status-keys to get them as a list and then iterate over that
with foreign-status-ref.  Very possibly creating his own plist,
alist, whatever.

> I feel I've failed to clearly communicate my point about abstraction.
> That's probably my fault.

We think this is a useful utility which does indeed destroy the
abstraction, especially if 'set is no longer required.  I guess John
has failed to sufficiently communicate to you the virtues of
foreign-status-plist.  He for example said:

> I continue to prefer foreign-status-plist.  For one thing, it means
> that if you have searched for the key you want, you get the value in
> O(1) time.  If the internals of the object actually are a plist
> (which is a reasonable implementation strategy), it takes O(n^2)
> operations to get all the key-value pairs.
>
> Encapsulation is fine when there is something to encapsulate, but
> when the object is immutable there's no real reason for it.  We can
> say that it is an error to modify the list returned by -plist so
> that it can can be handed out in O(1) time if the internal format is
> also a plist.

Back to you:

> As a separate issue, the concrete representation of a plist doesn't have
> standard tools in R6RS or R7RS-small. If we return a list it should be
> an alist.

plists are very, very simple.  Without an SRFI for them, I just say:

> This SRFI uses property lists (plists).  They are simple lists of
> alternating keys and values, such as:
>
> ('key1 "value1" 'key2 "value2")

Alists introduce messiness when the value is a list, although that's
not the end of the world.  But you have a point about their not being
supported in the standards, and without an SRFI, each user creating
statues and errors, and consumer of foreign-status-plist will have to
come up with his own routines.  Although we could either suggest some
very simple ones, maybe include their code in the SRFI (???) without
making them a real standard???

>>> Note from previous email, I'm tentatively changing 'set to 'facility.
>
> 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.

Good point.  Let me spend some time with a thesaurus after I get some
more sleep.

- Harold