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