> From: "Marc Nieper-Wißkirchen" <xxxxxx@nieper-wisskirchen.de>
> Date: Sunday, August 16, 2020 10:31 AM
>
> Am So., 16. Aug. 2020 um 17:19 Uhr schrieb <xxxxxx@ancell-ent.com>:
>
>>> From: Lassi Kortela <xxxxxx@lassi.io>
>>> Date: Sunday, August 16, 2020 9:44 AM
>
>> [ We agree plists will be used for arguments, but not yet on explicit
>>   vs. implicit. ]
>>
>>> 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.
>
> I think this would be okay. See SRFI 125, for example. Constructors
> like "hash-table" take plists (for the reasons Lassi gave); while the
> accessor "hash-table->alist" returns an alist (and the other accessors
> like "hash-table-keys", ... also return lists of the same length as
> the alist).
>
> You could even use the same naming convention:
>
> (foreign-status ...) takes a plist
> (alist->foreign-status .) takes an alist
> (foreign-status->alist .) returns an alist
>
> I think nothing more is needed.

It's "OK", but ... well, all things considered, including assq (we
*are* requiring all keys be symbols, right?  I think we made that
decision, but I want to double check.) alists are OK for the
procedure(s) that dump multiple key/value pairs.

To answer your previous question, when you look at raw alists that
have lists as values, they aren't '(key . (value1 value 2)), the
dotted pair just becomes a list, '(key (value1 value 2)).  This is
confusing unless or until you remember the building blocks of lists.
assq et. al. work just fine, but I dislike this quirk a lot more
for constructions, which is avoided by having make-foreign-status
and raise-foreign-error take plists.

Any strong arguments for making the argument(s) an implicit plist,
e.g. (make-foreign-status 'key1 'value1 'key2 'value2), vs. an
explicit one, e.g. (make-foreign-status '(key1 value1 key2 value2))?

- Harold