> John and I very strongly desire what I'm now calling the 'convention > key, you refuse to explain your allergy to having one mandated key, > why it ... /ruins???/ your vision of the SRFI. > > I think he _has_ explained it, and I'm willing to put in more time on > it. It's not a blocker really, since the use of 'convention is only, > er, a convention. It's just a question of how hard SRFI 198 pushes it, > which is a tiny change to the SRFI and a tiny change to the > implementation to check it or not at creation time. Thanks. Agree: - What if an object conforms to more than one convention? - What if it doesn't conform to any? I view the properties like a language that should let people say vague things in addition to precisely contextualized things. Precise claims should sound precise, vague claims should sound vague. If we have 'code but not 'set, that sound as vague as it is. If we have both 'code and 'set, that sounds as precise as it is. I don't see a problem if there is no mandatory coupling. I'd prefer to amass a set of properties where each property is defined so robustly that it is in effect its own convention, or forms an obvious convention together with a few other properties without us having to explicitly divide large numbers of properties into groups. E.g. the triplet of 'set and 'code and 'name forms a little island of related properties, but that island doesn't need to put restrictions on other unrelated or only loosely related properties. I agree with Harold that being able to ask questions like "did this error come from libsodium?" is very important. However, an '(origin libsodium) property, independent of other properties, ought to do the job as well as a master key. As usual, the name is up for debate.
