> On Mon, Aug 3, 2020 at 2:12 PM Lassi Kortela <xxxxxx@lassi.io> wrote:
>
>>> [Me]
>>>
>>> Or just drop the ". args" convenience feature, and always return
>>> whatever's there, lambda or not.  Based on whatever is specified
>>> in the SRFI's use of lambdas for localization, or the conventions
>>> of the error-set collection, the user, IDE, whatever then calls
>>> the lambda with the correct arguments, if any.
>>
>> That may end up being the best idea in the end. Thanks for being an
>> advocate of simplicity.
>>
>>> Making the API regular is more important than a bit of
>>> convenience, especially given how fundamental lambdas are to
>>> Scheme.
>>
>> That's true, and regularity is a particular virtue of Scheme as
>> compared to most other languages, even to other Lisps.
>>
>> However, the ubiquity of lambdas also means that they are quite
>> cheap both syntax- and efficiency-wise so we shouldn't worry too
>> much about sprinkling them around.
>
> From: John Cowan <xxxxxx@ccil.org>
> Date: Tuesday, August 04, 2020 10:52 AM
>
> All right, I'm okay with foreign-status or anything similar to that,
> just not with foreign-error, as some statuses are success rather
> than failure statuses, like HTTP 200 or VMS error code 2 (analogous
> to 0 as a Posix process status).

Let me spend some quality time with a thesaurus while you are nailing
down localization, the biggest unknown left for the API.

> But I don't see how foreign-status-ref can be both convenient
> (lambdas are forced) and transparent.  Two access methods are
> needed, one for each purpose.

Nor do I, which is why for simplicity and regularity I advocated only
one access method.  If you know based on the conventions of
localization or the error-set collection that the value is going to be
a lambda, you call it with the appropriate number of arguments, 0 to
many.  If it may be a lambda, or you're paranoid for either the
previous case, or in general, your first test its type.

I claimed that (foreign-status-ref-be-convenient fstatus key . args)
provided so little convenience it's not worth the extra complication
of including it in the API.  But I could be convinced otherwise, it's
a small enough thing, especially if it bundles the above paranoia,
behavior we'd need to define.

So, who's going to be calling it?

I see a user manually working on the object, or a somewhat automated
debugging environment.  The latter can Do The Right Thing whatever the
accessor is.  It's the former in a simple REPL where adding paranoia
and correct handling to foreign-status-be-convenient may provide
enough of a payoff to justify including it in the API.

- Harold