Hi Marc, and thanks for commenting.

First of all, having read your thoughts, I suggest that we not throw
the baby out with the bath-water.  The current version of this form
is not fixed, of course, and I think we can improve it.

On 2022-01-08 19:26 +0100, Marc Nieper-Wißkirchen wrote:
> Guile's lambda* seems to come from SRFI 89's lambda*. I agree with
> Arne that a different name should be chosen for SRFI 232.

Yes.  As hinted in the Issues, I think lambda* is a pretty awful
name.  I'd like to hear some alternative suggestions.  Here
are a few off-the-cuff possibilities:

* lambda-c
* curry (unfortunately, used by lots of other similar macros)
* kappa (from 'Kurry')

As for the define sugar, how about define-curried ?

> (1) Do we really need to make this type of currying easier in Scheme?
> ...
> I would like to see a real-world use case where the
> proposed form actually makes the resulting code easier to understand
> (and to write).

I'm not sure I understand what you mean by "this type of currying".
Do you mean the way that lambda* allows procedures to be applied to
fewer or more arguments than they accept, as opposed to the "fixed"
currying of SRFI 219?

I agree that I'd like to see useful examples of lambda*, and I believe
that the sum/product example given in the SRFI is one, though it's
tiny.  In Haskell and other "curried languages", I very frequently
write partially-applied expressions like "foldr + 0" or "map (+ 1)";
this terseness and omitting of unneeded detail can dramatically
simplify programs, I think.  (You can do this with cut, but the
advantage of lambda* here is its extreme brevity and ordinary syntax.)

Whether this use is "real-world" is, of course, a matter of opinion.
(https://xkcd.com/1312/ applies.)  But I suggest that the "real world"
in programming is always a matter of opinion, so maybe we can find a
different criterion of significance.

> (2) My biggest complaint about the lambda* form is that the behavior
> is irregular. If I apply as many arguments as there are formals, it
> would make as much sense to return a thunk. The arbitrariness at such
> limit points is a source for future programming errors. Another
> discontinuity is at the border between returning a value and applying
> the excess arguments to the resulting values. While it looks elegant,
> the lambda* form confounds three things.

Am I understanding right that you think that lambda* is combining
several different features in a way that makes its behavior
unpredictable?  Can you identify the three things that you think
it's "confounding"?

I think that there is some oddness in the treatment of nullary
procedures and application to zero arguments, and the form may be
tricky to reason about overall: lambda* does a lot.  As for applying a
k-ary procedure to k arguments, I agree that it would make theoretical
sense to return a thunk, but, practically, there's no
question--applying the procedure makes far better sense to me.
Perhaps it's a contradiction of lambda*'s "zero arguments rule",
though.  Can we make some improvements here?

I think you meant "applying the resulting values to the excess
arguments" in the second to last sentence, but maybe I've
misunderstood.  While I wonder about possible problems that
the extra-arguments behavior might introduce, I don't see
any capriciousness here.  Regardless of whether a procedure is
invoked on extra arguments, it *does* return a value.  If there
are extra arguments, then this value is immediately invoked on
them.

> (3) We need benchmarks on whether replacing lambda by lambda* affects
> runtime (much) and whether calling the procedures resulting from
> partially applying lambda* are as fast as hand-written procedures (or
> those returned by SRFI 26).

I've attached a very basic set of benchmark tests which use
chibi's test library as a sloppy way to get execution times.  Each of
the following entails 100,000 applications of a procedure; "normal"
applies a 5-ary procedure, "hand-curried" applies a fully-curried
5-ary procedure, and the "lambda*" sets apply a 5-ary lambda*
procedure through an increasing number of partial applications.
See the attached file for details.

    normal: .
    1 out of 1 (100.0%) test passed in 0.015610933303833008 seconds.

    hand-curried: .
    1 out of 1 (100.0%) test passed in 0.09452295303344727 seconds.

    lambda* coarsest: .
    1 out of 1 (100.0%) test passed in 0.09674406051635742 seconds.

    lambda* coarse: .
    1 out of 1 (100.0%) test passed in 0.3158271312713623 seconds.

    lambda* fine: .
    1 out of 1 (100.0%) test passed in 0.728193998336792 seconds.

    lambda* finest: .
    1 out of 1 (100.0%) test passed in 0.9788308143615723 seconds.

These were executed on a machine with a 4.2 GHz x86_64 processor
and 8 GB RAM.  As usual with benchmarks, I advise not taking them
very seriously.

Best regards,

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

"As Will Rogers would have said, 'There is no such thing as a
free variable.'" --Alan J. Perlis