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)
|
>> Lambda is primitive syntax and deeply hardwired into most Schemes. We should not ask implementers to change it. > > 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. That could be done, but I'm not sure whether it's a wise decision. Though 177 is designed with the principle of distilling what others have already done and not inventing new semantics, we still don't have much experience using it. The semantics ought to be OK (they've been used for decades in Common Lisp and in many Schemes). But the syntax (lambda/kw and call/kw) is something we just invented. The Common Lisp lambda-list syntax as well as SRFI 89 `lambda*` and `define*` have also been in use for a long time, but they are quite complex and it's not clear that the complexity justifies itself. I've used CL a lot and gradually came to view most excesses of the lambda list syntax as probably design errors (similar to the baroque syntax of the `loop` macro). This is just a long-winded way to say that I'm not confident we have the right lambda-list syntax, and therefore it's probably better not to put it in `lambda`. Alternative operators like `lambda/kw`, `case-lambda` etc. allow us to experiment without burdening ordinary `lambda` with any design mistakes we make. >> 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? Probably optional positional arguments that are implemented by destructuring the rest argument. The manual destructuring of optional arguments could be wrapped into a convenient macro like `lambda/opt`. Indeed, the SRFI 89 `lambda*` macro already supports it. I agree that the combination of optional positional arguments and keyword arguments is confusing.