Is recieve macro from base implementation of SRFI-1 in fact SRFI-8? Jakub T. Jankiewicz (22 Aug 2021 16:51 UTC)
Re: Is recieve macro from base implementation of SRFI-1 in fact SRFI-8? Marc Nieper-Wißkirchen (23 Aug 2021 15:58 UTC)
Re: Is recieve macro from base implementation of SRFI-1 in fact SRFI-8? Marc Nieper-Wißkirchen (23 Aug 2021 20:19 UTC)
Re: Is recieve macro from base implementation of SRFI-1 in fact SRFI-8? Marc Nieper-Wißkirchen (23 Aug 2021 21:15 UTC)
Re: Is recieve macro from base implementation of SRFI-1 in fact SRFI-8? Marc Nieper-Wißkirchen (24 Aug 2021 07:34 UTC)
Re: Is recieve macro from base implementation of SRFI-1 in fact SRFI-8? Daphne Preston-Kendal (24 Aug 2021 06:45 UTC)
Re: Is recieve macro from base implementation of SRFI-1 in fact SRFI-8? Marc Nieper-Wißkirchen (24 Aug 2021 07:51 UTC)
Re: Is recieve macro from base implementation of SRFI-1 in fact SRFI-8? Daphne Preston-Kendal (24 Aug 2021 08:37 UTC)
Re: Is recieve macro from base implementation of SRFI-1 in fact SRFI-8? Marc Nieper-Wißkirchen (24 Aug 2021 09:26 UTC)
Re: Is recieve macro from base implementation of SRFI-1 in fact SRFI-8? Marc Nieper-Wißkirchen (24 Aug 2021 17:28 UTC)
(missing)
(missing)
Fwd: Is recieve macro from base implementation of SRFI-1 in fact SRFI-8? Marc Nieper-Wißkirchen (24 Aug 2021 18:38 UTC)
Re: Is recieve macro from base implementation of SRFI-1 in fact SRFI-8? Marc Nieper-Wißkirchen (24 Aug 2021 17:56 UTC)
Re: Is recieve macro from base implementation of SRFI-1 in fact SRFI-8? Marc Nieper-Wißkirchen (24 Aug 2021 17:59 UTC)

Re: Is recieve macro from base implementation of SRFI-1 in fact SRFI-8? Daphne Preston-Kendal 24 Aug 2021 08:37 UTC

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