Am Do., 6. Mai 2021 um 23:55 Uhr schrieb Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz>:
On 2021-05-06 21:37 +0200, Marc Nieper-Wißkirchen wrote:
> Unless you can be sure that procedure can be inlined by the compiler and
> the optimizer can understand the code the match macro generates, a
> procedure of the form (lambda args ...) will be rather inefficient.
>
> Don't cons arguments (in the form of a rest argument) just to be able to
> use match to destructure them.

I don't want to belabor the point, but I think that it depends; we
can't easily write "fast" under case-lambda and "slow" under
match-lambda or the like without talking about specific
implementations.  The portable case-lambda implementation from R7RS
also expands to (lambda args ...); given the possibility that someone
will run code on a Scheme using this, I wouldn't be particularly
worried about trying to optimize argument-matching in portable code.

The portable case-lambda implementation from R7RS (I think it is the one from SRFI 16) is simple but is inefficient. Even for Schemes that do not support case-lambda natively, much better implementations are possible. Scheme implementations that want to more than toy implementations should not just copy the sample implementation.

When writing code that is supposed not to run only for demonstration purposes, one should worry IMHO. In particular, one should have the fast Schemes in mind, not only slow implementations.

I agree that one has to make some assumptions about the Scheme implementation, but luckily the reality is monotone. Case-lambda is much more easily optimizable than general match code and there are no Scheme implementations with a slow case-lambda but that know how to optimize a (lambda args (match args ...)) construct.

It would be fine if we had a generally available efficient match-lambda* (that could use case-lambda internally), but this is not true. For the time being, unnecessary use of match-lambda* and similar constructs just produces slow code.