> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Monday, August 10, 2020 10:14 AM
>
>> When (foreign-status-plist /foreign-status-object/) is handed something
>> that's not a foreign-status-object, what should it do?  Would raising an
>> non-continuable error always be the right thing??
>
> "It is an error" to pass something other than a foreign-status object to
> this procedure is the usual SRFI verbiage, meaning it's undefined
> behavior. Or just don't mention it -- SRFI procedures do UB on undefined
> argument types by default. Good to raise an exception, but not required.

OK, it's implicit enough in the text and examples I don't have to say
anything extra about this.  Thanks!

> What does `foreign-status-plist` do, return the whole plist?

Yes.  Except it may generate a new plist because (2nd item below):

> Does enumerating the properties need to be in the API?

My theory is no, because plists are so simple, although it would be
nice to have a plist SRFI, even as a placeholder, to direct people to
for simple utilities like that.  The foreign-status-properties you
suggest below would just duplicate one of its procedures.

> If it does, then `(foreign-status-properties st) -> list of symbols`
> would be better for encapsulation. The implementor has more choice
> re: internal representations

Plists are only a methods we use to communicate with the API, what's
done inside an foreign status object is entirely at the discretion of
the implementor.

> and we can postpone the decision about transparent lambdas.

Right now transparent lambdas are off the table, and I assume won't be
put back on it unless and until we nail down localization, and then
look at it and say, hey, this bit right here should be magical like that.

- Harold