On 24 Aug 2021, at 09:50, Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:

> Thanks for sharing this.  As for the name:  After having rethought it, the name "opt-lambda" (or a similar one) is the better name because we already have case-lambda (and match-lambda in SRFI 204).

Yeah, I’m not totally fixed on the name. I think a suffix is slightly better because there is, to my knowledge, no tradition of forms of ‘define’ with prefix names. But I’m happy to bikeshed it later — this is just a proof of concept, really.

> Do you think that a version where the values of the previous arguments are not bound is that much useful?  Of course, it is a nice symmetry with let and let*, but does this already warrant this (slight) complication of an optionals spec?

One might well ask why we have both let and let* to begin with. (Clojure, I believe, has only one let form which is essentially our let*.)

The slight efficiency gain from only having one extra procedure call internally when possible seems potentially worth it to me.

> As for the surface syntax, the rest argument should be detectable even without any optionals specified.  For otherwise, the behavior becomes irregular.  So
>
> (opt-lambda (x y (z a) . rest)
>   ...)
>
> and not
>
> (opt-lambda (x y (z a) rest)
>   ...)

That’s how it’s meant to work, but I think at present the latter will match as well, and do something weird, because controlling what patterns match what input like that in syntax-rules is moderately tricky. An implementation in SRFI 148 or syntax-case would a lot shorter and more robust against foibles like this.

> Incidentally, the first syntax does not clash with the normal lambda syntax, so it can be used as a drop-in replacement for lambda.  So as part of a standard, both can become the same, simplifying the language.

Yes, the second clause of the top-level lambda-optional[*] form implementation shows that it expands to a regular lambda in the degenerate case with no optional parameters.

> Marc

Daphne