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? 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? Lassi Kortela 14 Aug 2020 13:30 UTC

> +1 to having foreign-status-keys.  But if there is smarts inside the
> object, then f-r-ref exercises the smarts lazily, one key at a time,
> whereas f-r-plist exercises them eagerly and for all keys.

Exactly. The behavior of the lambdas needs to be independent of the
order in which they are evaluated. That's probably good policy, but
without f-r-plist we don't come up with any situations with an implicit
evaluation order: instead, the user's code must always feed keys to
f-r-ref in a specific order. We're passing responsibility to the user.

> I still haven't seen a use case for smarts except localization,

Check the Common Lisp and Gauche examples I just posted :) They delay
the strerror() call for errno-based errors.

The Windows API equivalent is FormatMessage() which also does
localization. Its calling convention is much more complicated, though I
don't know whether it's slower.

In any case, we can delay getting any expensive (in time and/or space)
information about the error this way.

> localization is simply not achievable in the
> general case when the error is raised, though it is in some special
> cases where the catalogs (or equivalent) reside locally.
True. Or when a network server sends you a localized message.