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)
|
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?