Re: SRFI 232: An advanced currying form

Show/hide message thread

SRFI 232: An advanced currying form Arthur A. Gleckler (08 Jan 2022 02:21 UTC)

Re: SRFI 232: An advanced currying form Dr. Arne Babenhauserheide (08 Jan 2022 17:24 UTC)

Re: SRFI 232: An advanced currying form Marc Nieper-Wißkirchen (08 Jan 2022 18:26 UTC)

Re: SRFI 232: An advanced currying form Wolfgang Corcoran-Mathe (09 Jan 2022 18:45 UTC)

Re: SRFI 232: An advanced currying form Marc Nieper-Wißkirchen (09 Jan 2022 21:56 UTC)

Re: SRFI 232: An advanced currying form Wolfgang Corcoran-Mathe (13 Jan 2022 22:37 UTC)

Re: SRFI 232: An advanced currying form Marc Nieper-Wißkirchen (14 Jan 2022 07:24 UTC)

Re: SRFI 232: An advanced currying form Wolfgang Corcoran-Mathe (18 Jan 2022 19:30 UTC)

Re: SRFI 232: An advanced currying form Marc Nieper-Wißkirchen (19 Jan 2022 00:44 UTC)

Re: SRFI 232: An advanced currying form John Cowan (16 Jan 2022 18:29 UTC)

Re: SRFI 232: An advanced currying form Marc Nieper-Wißkirchen (16 Jan 2022 18:52 UTC)

Re: SRFI 232: An advanced currying form Marc Nieper-Wißkirchen (16 Jan 2022 19:01 UTC)

Re: SRFI 232: An advanced currying form John Cowan (20 Jan 2022 06:21 UTC)

Re: SRFI 232: An advanced currying form Wolfgang Corcoran-Mathe (18 Jan 2022 18:28 UTC)

Re: SRFI 232: An advanced currying form Wolfgang Corcoran-Mathe (18 Jan 2022 18:38 UTC)

Re: SRFI 232: An advanced currying form Marc Nieper-Wißkirchen (18 Jan 2022 19:00 UTC)

Re: SRFI 232: An advanced currying form Wolfgang Corcoran-Mathe (18 Jan 2022 21:22 UTC)

Re: SRFI 232: An advanced currying form Marc Nieper-Wißkirchen (18 Jan 2022 22:18 UTC)

Re: SRFI 232: An advanced currying form Marc Nieper-Wißkirchen (19 Jan 2022 07:47 UTC)

Re: SRFI 232: An advanced currying form Marc Nieper-Wißkirchen (19 Jan 2022 20:55 UTC)

Re: SRFI 232: An advanced currying form Wolfgang Corcoran-Mathe (24 Jan 2022 23:08 UTC)

Re: SRFI 232: An advanced currying form Marc Nieper-Wißkirchen (26 Jan 2022 13:29 UTC)

Re: SRFI 232: An advanced currying form Wolfgang Corcoran-Mathe (31 Jan 2022 21:42 UTC)

Re: SRFI 232: An advanced currying form Dr. Arne Babenhauserheide (09 Jan 2022 01:35 UTC)

Re: SRFI 232: An advanced currying form John Cowan (16 Jan 2022 18:15 UTC)

Re: SRFI 232: An advanced currying form Wolfgang Corcoran-Mathe (09 Jan 2022 18:47 UTC)

Re: SRFI 232: An advanced currying form Wolfgang Corcoran-Mathe 24 Jan 2022 23:07 UTC

Hi Marc, thanks for all of this work.  I'll try to reply more quickly
in the future.

On 2022-01-19 08:46 +0100, Marc Nieper-Wißkirchen wrote:
> So... a more regular, more expressive, and not hard-to-use version of
> lambda* would look like
>
> (lambda** (<var> ...) (<var> ... . <var*>)
>   <body>)
>
> If this form is applied to no more than as many arguments as there are
> variables between the first set of parentheses, a procedure is
> returned. If there are more actual arguments, any excess arguments are
> distributed over the second set of formals (and it is an error if
> there are not enough excess arguments) and then the body is evaluated.

I appreciate that this seems to fix the ambiguity of lambda*
while also (I believe) letting you do everything the current form
does.  It provides a lot of flexibility, while still being pretty
direct to implement with syntax-rules.  I doubt an implementation
of lambda** would be much longer or more complicated than that of
lambda*.

However, I think the form is syntactically much heavier, and
complicated syntax is the nemesis of currying macros.  It's easy to
imagine many programmers ignoring lambda** simply because of the
"weird" double formals.[*]  I don't mean to put ergonomics above
correctness, but I believe that a clunkier syntax should seem
warranted.  That's not how it seems to me, as I'm not yet convinced
that this new form fixes any significant problems with lambda*.

I'd like to get some more input as to what other reviewers think of
lambda* vs. lambda**.

[*] I recall a disscussion about the receive and let-values macros
in which one distinguished Schemer said he'd never used let-values
"because three parens is too many".

> There is another possible syntax for lambda** besides the one I gave
> that has two formal argument lists and which may be more convenient:
>
> (lambda*** (a b c | d e . f) <body>)
>
> would be (lambda** (a b c) (d e . f) <body>), where "|" is some
> keyword-like datum.

This is a bit more convenient, I think, and I'd prefer this form
over the double-formals version.  I also much prefer the version
that doesn't extend lambda, which I think would require standardized
keywords(?).

But, again, I'm not yet sold on lambda** or its variants.  Hopefully
we can get some more opinions.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"All this currying's just a phase, though it seldom hinders."
--Fritz Ruehr