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
> >
> >>> 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.

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.

Marc