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 Lassi Kortela 02 Nov 2019 23:28 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.