Quick vote about portable keyword argument syntax Lassi Kortela (01 Nov 2019 19:44 UTC)
Re: Quick vote about portable keyword argument syntax Marc Feeley (01 Nov 2019 20:12 UTC)
The name of "keyword-call" Lassi Kortela (01 Nov 2019 20:45 UTC)
Re: The name of "keyword-call" Lassi Kortela (01 Nov 2019 20:51 UTC)
Re: The name of "keyword-call" John Cowan (01 Nov 2019 20:54 UTC)
Re: The name of "keyword-call" Lassi Kortela (01 Nov 2019 20:59 UTC)
Re: The name of "keyword-call" John Cowan (01 Nov 2019 21:30 UTC)
lambda* Lassi Kortela (01 Nov 2019 21:47 UTC)
Re: lambda* John Cowan (01 Nov 2019 21:48 UTC)
Re: lambda* Lassi Kortela (01 Nov 2019 21:59 UTC)
curry/partial Lassi Kortela (01 Nov 2019 22:18 UTC)
Re: curry/partial John Cowan (01 Nov 2019 22:47 UTC)
Re: The name of "keyword-call" Marc Nieper-Wißkirchen (02 Nov 2019 16:23 UTC)
Re: The name of "keyword-call" Lassi Kortela (02 Nov 2019 23:16 UTC)
Re: The name of "keyword-call" hga@xxxxxx (01 Nov 2019 21:34 UTC)
Re: Quick vote about portable keyword argument syntax Per Bothner (01 Nov 2019 20:57 UTC)
Re: Quick vote about portable keyword argument syntax Lassi Kortela (01 Nov 2019 21:06 UTC)
Re: Quick vote about portable keyword argument syntax Marc Nieper-Wißkirchen (02 Nov 2019 16:22 UTC)
Re: Quick vote about portable keyword argument syntax Marc Nieper-Wißkirchen (02 Nov 2019 16:42 UTC)
Re: Quick vote about portable keyword argument syntax John Cowan (02 Nov 2019 16:48 UTC)
Re: Quick vote about portable keyword argument syntax Marc Nieper-Wißkirchen (02 Nov 2019 16:57 UTC)
Re: Quick vote about portable keyword argument syntax Lassi Kortela (02 Nov 2019 23:28 UTC)
Re: Quick vote about portable keyword argument syntax Lassi Kortela (02 Nov 2019 23:47 UTC)
Re: Quick vote about portable keyword argument syntax John Cowan (03 Nov 2019 02:36 UTC)
Re: Quick vote about portable keyword argument syntax Marc Nieper-Wißkirchen (03 Nov 2019 08:49 UTC)
Re: Quick vote about portable keyword argument syntax Lassi Kortela (03 Nov 2019 09:56 UTC)
Re: Quick vote about portable keyword argument syntax Marc Nieper-Wißkirchen (03 Nov 2019 10:27 UTC)
Re: Quick vote about portable keyword argument syntax Lassi Kortela (03 Nov 2019 11:17 UTC)
Re: Quick vote about portable keyword argument syntax Marc Nieper-Wißkirchen (03 Nov 2019 11:31 UTC)
Re: Quick vote about portable keyword argument syntax Lassi Kortela (03 Nov 2019 12:41 UTC)
Re: Quick vote about portable keyword argument syntax Marc Nieper-Wißkirchen (03 Nov 2019 15:20 UTC)
Re: Quick vote about portable keyword argument syntax Lassi Kortela (03 Nov 2019 15:40 UTC)
Re: Quick vote about portable keyword argument syntax Lassi Kortela (03 Nov 2019 15:50 UTC)
Re: Quick vote about portable keyword argument syntax John Cowan (03 Nov 2019 19:39 UTC)

Re: Quick vote about portable keyword argument syntax Marc Nieper-Wißkirchen 02 Nov 2019 16:57 UTC

Am Sa., 2. Nov. 2019 um 17:48 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Sat, Nov 2, 2019 at 12:42 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
>> If possible, lambda/kw should become a synonym of lambda (and the
>> syntax of define should allow keywords as well).
>
>
> I am strongly opposed to that.  Lambda is primitive syntax and deeply hardwired into most Schemes.  We should not ask implementers to change it.  We added caselambda rather than attempting to integrate multiple bodies into lambda.  (Of course the implementation of lambda/kw may expand into lambda on some systems.)

I wrote "if possible" on purpose. The reference implementation of SRFI
177 cannot do anything about the "lambda" and the "define" as exported
by "(scheme base)".

For Scheme system, implementing SRFI 177 natively, it is trivial to
amend "lambda" and "define" as exported by "(scheme base)". This has
nothing to do what the primitive version of lambda is as the version
exported by "(scheme base)" can be a macro expanding into the
primitive version.

"case-lambda" looks differently to me as the case-lambda syntax is not
a conservative extension of the usual lambda syntax.

> The same should apply for other extensions.   In particular, I think that as a matter of policy we should have keywords *or* optional arguments in any one procedure definition, not both.

By "optional" arguments you mean rest arguments?