> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Sunday, August 16, 2020 9:44 AM
>
>>> By exotic properties I meant ones related SQL, HTTP, IRC and various
>>> others that are not urgent for SRFI 170.
>>
>> But those are items *collected* in the three different types of lists,
>> right?  Alists, plist, optional arguments at the end of a procedure's
>> signature are just equivalent ways to collect key/value pairs.  Except
>> for the trickiness lists as values for alists.
>
> Ah, I didn't realize you were talking about which constructors and
> accessors we should have. I agree that they are equivalent.
>
> I strongly recommend that `make-foreign-status` and
> `raise-foreign-status` take a plist....

Great, we're back in agreement for argument collections, except for
implicit plist vs. explicit.

> As for whether `foreign-status-keys` or `foreign-status-plist` or
> `foreign-status-alist` should exist, that's less important still.

If foreign-status-[whatever] is part of the API, and plists are used
for arguments, then the surface of the API might be smaller if we
make it foreign-status-plist.  Users won't have to grok both plists
and alists.

> [ Let's nail down the collection type of it's return before getting
>   into exactly what it does?? ]
>
> [...] 2) alists have `assoc` in RnRS whereas plists don't.

Plists don't have *anything*; John has a pre-SRFI, but it's too
immature to even think about referencing it in SRFI 198.

The concern about all users consing up their own plist utilities
is the argument against using them for arguments or returns.

>> Not sure about the args at the end of a procedure's
>> arguments option, it looks like an implicit plist to me.
>
> They are :)

But there's a difference in usability if I can't actually hand
those procedures a plist as an arg, right?  Plus the mirroring
concept if we make the helper procedure return a plist, it makes
the API much more regular.

- Harold