libsodium error codes Lassi Kortela (10 Aug 2020 11:32 UTC)
Localization and a new STFI 198 draft to base it upon hga@xxxxxx (10 Aug 2020 13:12 UTC)
Re: Localization and a new STFI 198 draft to base it upon Lassi Kortela (10 Aug 2020 14:07 UTC)
Re: Localization and a new STFI 198 draft to base it upon hga@xxxxxx (12 Aug 2020 12:49 UTC)

Re: Localization and a new STFI 198 draft to base it upon hga@xxxxxx 12 Aug 2020 12:49 UTC

> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Monday, August 10, 2020 9:07 AM
>
>>> BTW, how's the localization discussion going? "I have no
>>> dog in that hunt", so I haven't been following it, but it's
>>> the blocker for the next draft....
>>
>> John's made a concrete proposal, and it's gotten me interested
>> in the lower level mechanics of making localization work.
>>
>> Since we've made a lot of concrete changes to the SRFI, and
>> have gotten it into a pretty good state that's some distance
>> from the current draft, I'm going to memorialize those changes
>> in a new draft to form the foundation for further discussion,
>> especially for adding localization.  I'm going to go with
>> 'error-set -> 'set for now, let's see how that feels vs.
>> e.g. 'status-set, a future change of that one detail will
>> be easy.
>
> Given that we haven't managed to come to a conclusion on how to do
> lambdas, should we simply have:
>
> - foreign-status? obj
> - make-foreign-status plist ...
> - raise-foreign-status plist ...
> - foreign-status-ref st property -> value or default #f
>
> for the next draft? foreign-status-ref would not transparently call lambdas.

That's what I've done, with the addition of foreign-status-keys as an
encapsulation improvement over foreign-status-plist as you suggested.

> Once we've figured out lambdas and localization we can change the
> semantics of foreign-status-ref and/or add another getter, whatever works.

That's the plan, reflected in two Issues.

- Harold