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