Great, we're getting down to specifics really well!

> Exactly so.  The issue, I think, is how an exception handler finds out
> what set it has: by looking at a named key, or by searching the list of
> properties to see if it can find a property it knows is unique to a
> given set.  For one thing, if it fails the first case is clearer to
> report upwards: "I don't know how to deal with group Baz status objects"
> rather than simply "I'm lost here."

A practical exception handler would be written something like this:

(define (winapi-status? x)
   (and (foreign-status? x) (foreign-status-ref 'winapi-error-code)))

(define (errno-status? x)
   (and (foreign-status? x) (foreign-status-ref 'errno)))

(guard (err
         ((winapi-status? err)
          ...)
         ((errno-status? err)
          ...))
   (do-some-os-stuff))

So the guard tests for known classes of errors in a particular order and
takes the first match. It doesn't matter how a match is determined; only
the order given in the guard matters.

This has the disadvantage that it doesn't distinguish between
winapi-native-errors-posing-as-errno vs
errno-native-errors-posing-as-winapi. If we had a 'convention master key
that said 'errno or 'windows, that would settle the question. I don't
know whether it matters.

> Because the master key only guarantees a subset of what might be
> present, it *is* like an interface, but it's an interface with a name.
> Even in Go, where a class implements an interface iff it has the
> properties the interface expects, interfaces have names.

But if a Go object fits into more than interface, none of those
interfaces is the main one. They have equal standing.

Naming an interface may be useful. But again, there can be several
properties that give names of some kind. For example, a 'c-library
property could give 'libc, 'libsqlite3, 'libvorbis, etc.

>     I think we should ask "can I use this status object as a Foo kind of
>     status?".
>
> I've been thinking about that too.  I think that can be solved within
> the Harold/John framework as follows:  Allow the master key to be a
> nonempty list of symbols and let a symbol be equivalent to a list of
> length 1.  This means that the union of properties guaranteed by each
> symbol in the list will be present.  (I have not talked to Harold about
> this idea; he may hate it for all I know.)

That would definitely work. However, it adds complexity that isn't
opt-in for the people examining status objects they got from somewhere.

My approach is "by their properties shall ye know them". I don't vouch
for it because I know it's the right one, but because it's the simplest
one. "I know I'm dumb; if I do as little as I can, I have the best
chance of doing as little damage as I can."

> What I want to name is this: a specific interpretation of certain
> property keys.  If 'convention is 'baz or '(baz), then property 'foo
> means this and property 'bar means that.  That is, if the value of 'foo
> is 'XYZZY we can look in the tables associated with the 'baz convention
> and know that means "That is an old, worn-out version of the LAB-8
> protocol you are using.  Nothing happens."  But from another device
> using a different interpretation of the same keys, it might mean "This
> instrument will self-destruct in five seconds."

That probably makes sense. I would solve that by naming a little cluster
of 2-3 properties by putting the cluster's name in one more proprety.

> This knowledge is of course not in the status object; it's in the
> registry in a natural language, or it's in the program code that
> interprets the objects.  All the status object has is that the
> interpretation in use (or one of them) is named 'baz.  If the maker of
> lab instruments changes the keys and/or values it uses to talk to a
> program in later models, that is a new interpretation for our purposes
> and needs a new name.

Agreed (if the new interpretation is incompatible with the old).

>     You talk about pinning a status
>     down to one group that describes it; I see many statuses as naturally
>     belonging to many groups, and superficially similar statuses (which
>     you'd think all belong to the same group) coming from different sources
>     and plausibly belonging to different groups (perhaps one status belongs
>     to many groups, or "has many traits"; you'd test for the particular
>     trait(s) you want and ignore the other traits).
>
>
> Does the above idea help resolve this concern, which I admit is
> perfectly legitimate?  It allows a specific status object to belong to
> many groups.

If 'convention can be a list, that solves it.

But doesn't testing for the existence of specific properties relating to
the desired convention also solve it? If you have a non-#f 'errno
property, you can do errno-related stuff to it; a non-#f 'c-library and
you can do c-library-related stuff to it, etc.

The advantage of this is that it's simpler, and doesn't pin down what
belongs to a particular convention. I doubt that conventions are simple
to design in practice.

To be sure, it's simple to design a convention that _looks_ reasonable,
just as we designed the set/code/symbol convention at the start. But
when we started thinking about it more, all kinds of problems showed up.
I advocate for convention-less objects because I expect similar problems
to show up for most conventions we design.

>     To me it sounded like you were saying "we clearly need a master key
>     property" and I didn't get the "clearly" part. I understood why you'd
>     _want_ one, and agreed with that reasoning, but I didn't understand why
>     you'd _need_ one, or why other alternatives couldn't provide the same
>     functionality in a simpler and more flexible way.
>
> I agree that we don't _need_ one.  But things in registries (in this
> case, explanations of the use of different properties in different
> contexts) are simpler to deal with if they have names.

That's true.

> Another point is that I disclaim any interest in hierarchies or even
> heterarchies of interpretations.  I am content with a flat list of them
> (which the Registry can organize or index however it likes), such that
> any object (not just any property) may belong to more than one class.
> The organization of classes, if any, should be left to a higher level
> than this SRFI.

Fully agreed. If we have a list of traits, I also prefer a flat list.