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 18 Jan 2022 21:22 UTC

On 2022-01-18 19:59 +0100, Marc Nieper-Wißkirchen wrote:
> 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.

Theoretically I agree that we should not treat 0 as a special case.
But nullary procedures *are* a special case, I argue, in Scheme
practice.  They aren't isomorphic to constants, and we only tend to
use them as a way to get a body expression evaluated with a certain
continuation or in a certain environment.  Deriving a thunk from a
positive-ary procedure is, I think, rarely useful for this reason.
In Scheme programming, "nullary" isn't just the predecessor-ary of
"unary", but a different beast.

> ... 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 "!".

I've tried to explain why I find lambda* compelling (brevity of
notation and ease of use, especially compared to cut, convenience in
composition, etc.), and I know you haven't been similarly excited.  We
can't talk about "compelling use cases" without reference to whom is
feeling compelled.  Would you be willing to suggest the kind of
example which you'd be happy to see?

> 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.

I'm also a bit concerned about the possibility that arity mistakes
will be harder to catch.  But variadic procedures already cause plenty
of confusion here; accidentally over-apply map or some other variadic
form and you probably won't see the mistake until the program runs.
The bottom line is that arity can be tricky to keep track of with
variadic procedures, whether created with lambda* or not.

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

"In conversations with Web performance advocates, I sometimes
feel like a hippie talking to SUV owners about fuel economy."
--Maciej Ceglowski