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-26 14:29 +0100, Marc Nieper-Wißkirchen wrote: > I don't find the lambda** form particularly beautiful either. > "Syntactically *much* heavier" seems to me to be a gross exaggeration, > though. It is also not quite clear to me what you refer to when you write > "nemesis of currying macros". We don't have any currying macro > standardized in Scheme yet, do we? I meant "currying" rather loosely; in this context, I think it's important that syntax be kept as light as possible, since otherwise people will simply ignore the form and curry/specialize procedures "by hand". (I'm reminded again of Al Petrofsky's comment[1] that cut is only convenient because "lambda" is five letters.) > If we want to turn C into a true Scheme operator (that is a higher-order > procedure), we have to amend it by giving it a second argument, namely n. > > We would then have the following recursive definition: > > (C 0 f) => f > (((C n f) x) y ...) => ((C (- n 1) f) x y ...) > > [snip] > > The fold example would be then become something like (modulo the naming of > "C"): > > (let ((sum ((C fold) + 0)) > (product ((C fold) * 1)) > (lis '(1 2 3 4 5))) > (values (sum lis) (product lis))) I'm confused, since I see C used with and without the natural number argument. Is there some syntactic sugar here that I'm missing? > > But, again, I'm not yet sold on lambda** or its variants. Hopefully > > we can get some more opinions. > > > > Can you explain why you would prefer lambda* over lambda***? > > lambda*** is more expressive and doesn't have obscure corner cases while > syntactically as light-weight. I'm in favor of lambda* because it seems more convenient in the most obvious case (when you have a k-ary procedure and want partial application up to exactly k arguments): (define foo (lambda* (a b c) BODY)) If I understand correctly, with lambda*** you'd write: (define foo (lambda*** (a b | c) BODY)) to get the same definition. The usefulness of lambda*** seems to me to lie in its flexibility in returning thunks or in specifying exactly how many arguments are expected when reduction occurs, but I think those are somewhat obscure features in practical use. But, I'm not sure. We could possibly provide both; I think lambda*** is similar enough to lambda* to plausibly cover both in SRFI 232. [1] https://srfi-email.schemers.org/srfi-26/msg/2783121/ -- Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz> "Scientific theories are judged by the coherence they lend to our natural experience and the simplicity with which they do so. The grand principle of the heavens balances on the razor's edge of truth." --Commissioner Pravin Lal (Sid Meier's Alpha Centauri)