> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Sunday, August 16, 2020 8:36 AM
>
>> Thus we have incompatible visions for SRFI 198.
>
> I haven't noticed a disagreement about the overall vision, just details.

This would explain our total inability to achieve a consensus.  I'm
sorry I've not been able to communicate my vision to you.

> [...]
>
>> Ditto for the collections used as inputs, and output for
>> foreign-status-plist/alist/whatever.  Shall we stick with alists, move
>> to plists, and for make-foreign-status and raise-foreign-error,
>> require one of those two, or just have the key/value pairs be optional
>> arguments, e.g. (raise-foreign-error 'set 'generic-c-lib 'subset
>> 'libsodium etc.).
>
> I'm confident we'll figure out the interface if we can only figure out
> the properties. Thankfully the more exotic properties can be added
> later; they don't need to be ready to get the SRFI finalized.

I don't see the linkage here.  What would be exotic enough that it
can't be represented by all three of the above options? They're all
lists of one sort or another.  I think it was you who pointed out
an alist and a plist take the same number of cons cells to collect
their key/value pairs (and I note alists are messier for list values).

> [ SRFI 35 ]

- Harold