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 Marc Nieper-Wißkirchen 18 Jan 2022 18:59 UTC

Am Di., 18. Jan. 2022 um 19:38 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:
>
> On 2022-01-18 13:28 -0500, Wolfgang Corcoran-Mathe wrote:
> > I've argued that
> > the only sensible thing here is application, so it's not a big deal:
> > lambda* is essentially defined such that it simply never returns a nullary
> > procedure.
>
> Oops, I overlooked the direct "lambda-compat" support for nullary
> procedures, which is clearly what John was referring to.  I agree
> that this should be removed so that what I wrote above can, in fact,
> be the truth.

This still doesn't solve the discontinuity when the result of an
application is returned instead of a thunk.

Haskell has no thunks (and needs no thunks), but Scheme has. Giving
them a special status in Scheme versus procedures with more than zero
arguments goes against basic principles. An even more basic principle
is that, if , the number 1, and not the number 0, should be given
special status in the domain of the non-negative integers.

One may violate this principle if that's the only viable approach to
enable something other worthwhile, of course, and that's why I have
been asking about compelling use cases that can't be solved with
standard Scheme, with cut, or with something like my "!".

PS Another difference to Haskell is that Haskell has a static type
system that gives early errors. In Scheme, we don't have much ad-hoc
overloading so the dynamic type system can catch errors early. The
lambda* goes in a different direction.