Am Fr., 3. Juli 2020 um 22:15 Uhr schrieb Panicz Maciej Godek
<xxxxxx@gmail.com>:

> I'm not sure which extensions you're talking about. But if you're suggesting
> that SRFI-201 should propose e.g. "match-let" instead of "let", then it would
> no longer be an "extension to the core Scheme binding', or would it?
>
> Similarly, one could insist not to use the (define (f . args) . body)
> to desugar to the core form (define f (lambda args . body)),
> and insist to have a form "define-procedure" (or "define-lambda",
> or whatever) that would be used as (define-procedure (f . args) . body).
> But this would not be in the spirit of my proposal.

I think one major point is that each syntactic extension of the core
syntax will make other possible and likewise well-grounded syntactic
extensions impossible. Thus, a conservative approach makes sense to
me.

For example, we have been discussing keywords in SRFI 177 at length.
In the end, we may get a `lambda/keywords', which creates a procedure
accepting optional keyword arguments. Maybe there is a way to sensible
merge the syntax of `lambda/keywords' with the usual `lambda' (as your
`define-procedure' merges easily with `define'). But that syntax may
be incompatible to the `match-lambda' syntax, so one can choose at
most one way to extend `lambda'.

Thus, it may look a bit premature to extend `lambda' to the syntax of
SRFI 201 already now. If (at all), it shouldn't happen before
R7RS-large is being finalized because then we have an overview of all
candidates for syntactic extensions. And, maybe, it shouldn't even
happen for R7RS-large but for R8RS because a core form is affected.