What to do for bad arguments to foreign-status-plist? hga@xxxxxx (10 Aug 2020 15:10 UTC)
Re: What to do for bad arguments to foreign-status-plist? Lassi Kortela (10 Aug 2020 15:14 UTC)
Re: What to do for bad arguments to foreign-status-plist? Lassi Kortela (10 Aug 2020 15:38 UTC)
Re: What to do for bad arguments to foreign-status-plist? hga@xxxxxx (12 Aug 2020 12:39 UTC)
Re: What to do for bad arguments to foreign-status-plist? Lassi Kortela (14 Aug 2020 13:31 UTC)
Promise objects Lassi Kortela (14 Aug 2020 13:46 UTC)
Re: Promise objects Lassi Kortela (14 Aug 2020 14:04 UTC)

Re: What to do for bad arguments to foreign-status-plist? hga@xxxxxx 12 Aug 2020 12:38 UTC

> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Monday, August 10, 2020 10:38 AM
>
> [...]
>
>>> What does `foreign-status-plist` do, return the whole plist?
>>
>> Yes.  Except it may generate a new plist because (2nd item below):
>
> Good.
>
>>> 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.
>
> It doesn't just duplicate a generic plist procedure, it maintains
> encapsulation.

That's a good argument.  It could be addressed by for example changing
foreign-status-plist to foreign-status-keys, providing a list of all
the keys in the status object.

I've made this change to the SRFI.

> Our keys are dumb objects - just symbols. Values may be smart
> (transparent lambdas), as may the container type (can use something else
> instead of plist). A procedure that enumerates just the dumb parts more
> easily handles the abstraction as it evolves.
>
> A `foreign-status-plist` will have to fetch values for all keys, even
> such keys that are not of interest to the caller. If we add transparent
> lambdas, then *all* of them will be called in a non-deterministic order
> whenever the user does `foreign-status-plist`.
>
> Forcing the user to explicitly call `foreign-status-ref` as the sole
> value accessor makes it explicit to the user when they are resolving a
> property value.

More good arguments, and this makes it cleaner to defer the decisions
about transparent lambda calling to the next draft.

> >> 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.
>
> Please at least consider my points above. It's not good to pin things
> down too early.

Well, we went back and forth, and I think now back on this.  It's now
one of the Issues.  I want a concrete example of their utility, this
might be addressed as we add localization.

- Harold