New draft (#4) of SRFI 232: An advanced currying form Arthur A. Gleckler (21 Mar 2022 21:04 UTC)
Re: New draft (#4) of SRFI 232: An advanced currying form Marc Nieper-Wißkirchen (23 Mar 2022 19:24 UTC)
Re: New draft (#4) of SRFI 232: An advanced currying form Wolfgang Corcoran-Mathe (24 Mar 2022 16:40 UTC)
Re: New draft (#4) of SRFI 232: An advanced currying form Marc Nieper-Wißkirchen (27 Mar 2022 18:01 UTC)
Re: New draft (#4) of SRFI 232: An advanced currying form Wolfgang Corcoran-Mathe (28 Mar 2022 04:16 UTC)

Re: New draft (#4) of SRFI 232: An advanced currying form Marc Nieper-Wißkirchen 27 Mar 2022 18:01 UTC

Am Do., 24. März 2022 um 17:40 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:
>
> On 2022-03-23 20:23 +0100, Marc Nieper-Wißkirchen wrote:
> > Wolfgang, can we check with each other whether the current behavior of
> > (curried () ...) is regular before this is finalized? Shouldn't
> > (curried () ...) return the evaluation of its body?
>
> I'm not sure I understand.  You're suggesting that (curried () 4)
> should evaluate to 4?

Yes. This will not only let you remove one case in your specification
(and this is usually a good hint that there was something fishy going
on), it will also give you more invariants for your forms.

For example,

(curried (x1 x2 ... xn) ...)

is then equivalent to

(curried (x1 ... xm)
  (curried (x[m+1] ... xn) ...)

without any restriction on 1 <= m <= n, etc.

> By the current specification, 'curried' with an empty formals list
> evaluates to a procedure which behaves like a vanilla thunk, but which
> can also be applied to one or more objects; in this case, the body
> is evaluated to a procedure which is invoked on the arguments.  Hemann
> comments: "We believe this is a natural extension of the behavior of
> [curried] for functions of other arities, and maintains the behavior
> of Scheme's λ when provided no arguments."

This still works with the more regular "apply immediately 0 arguments".

> Your comment led me to something in the implementation which I don't
> understand and which may be a bug.  Lines 34–36 of srfi-232.scm:

Isn't the implementation yours?

>     ((curried-1 () exp)
>      (lambda args
>        (if (null? args) exp (apply (exp) args))))
>
> The invocation of the procedure body before applying it to the args
> makes no sense to me, and contradicts the current semantics.  These
> lines are identical modulo naming to the paper's version, but I can't
> find any explanation of this extra application.  I *think* it's a
> mistake and the SRFI semantics are right, but I'll investigate further.

Well, by my above arguments, I think it should be:

((curried-1 () exp) exp)

When applied to args, this will become

(apply exp args)

so, indeed, the extra application in the code snippet above does not
make much sense IMO.