Am Do., 18. Juni 2020 um 11:34 Uhr schrieb Alex Shinn <xxxxxx@gmail.com>:

> The other case is handling backwards compatibility.  (srfi 69) and
> (srfi 128) both make use of hash functions, but the former accepts
> an optional bound, whereas the latter takes only a single argument.
> To allow for hash functions following either convention we check
> the arity, and wrap the single arg version with a procedure to discard
> any second arg.

This can be no more than an optimization because a trivial
implementation of SRFI 191 is always possible.

> I was fishing, hoping to find more interesting use cases.  The more
> general question is, "will I get a domain error applying procedure f
> to argument list ls?"

What is a "domain error" in the Scheme semantics?

> This gets interesting in the presence of typed
> dialects, as the domain can include type information.  One application
> of this would be generics - apply the first method which accepts an
> argument list.

For typed dialects, arity information should be an expand-time, not a
runtime concept.

>> I am not sure about the usefulness of the example, though. We have
>> already case-lambda for an optimized version (given that the
>> underlying Scheme has case-lambda as a core form):
>>
>> (define (complement fn)
>>   (case-lambda
>>     (() (not (fn)))
>>     ((x) (not (fn x)))
>>     ((x y) (not (fn x y)))
>>     (x* (not (apply fn x*)))))
>
>
> Not all Schemes have case-lambda as a core form, and we should
> not be in the business of discouraging axiomatic Scheme.  In the
> absense of special support for this, your definition is slower than
> no optimization at all.

Schemes like Chez that really care about fast execution have special
support for case-lambda (and prove through it that case-lambda is a
reasonable addition to the Scheme language). On the other hand,
Schemes that use the sample implementation of the report actively
discourage the use of case-lambda. So when you care about fast code
and case-lambda, you won't be able to get away with cond-expand.

While I agree that my code may or may not be an optimization (beyond
that I would like my implementation to optimize things like complement
automatically), I won't subscribe to what you have said about
discouraging axiomatic Scheme. While some forms like letrec* can be
expressed in terms of the "primitive forms", the transformation does
not capture the full semantics in so far as it introduces mutable
state, which can prevent a lot of optimizations in the actual
compiler.

Being a mathematician, I am certainly not against an axiomatic Scheme.
But adding, say `case-lambda` or `letrec(*)` to the axiomatic forms
wouldn't necessarily hurt.