Decision on foreign-status constructor and accesor syntax Lassi Kortela 16 Aug 2020 14:44 UTC

>> 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, for the simple reason that keyword
argument lists look just like plists. In Scheme implementations with
keyword objects, we can convert keywords to symbols when they are plist
keys. That lets us transparently switch these procedures to a
keyword-based syntax in case keywords are ever standardized in Scheme.

As for whether `foreign-status-keys` or `foreign-status-plist` or
`foreign-status-alist` should exist, that's less important still. The
main concerns are that 1) returning all values at once forces the
evaluation of all lazy lambdas if we have such things; 2) alists have
`assoc` in RnRS whereas plists don't.

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

They are :)