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)
|
John, thanks for commenting. On 2022-01-16 13:29 -0500, John Cowan wrote: > On Sat, Jan 8, 2022 at 1:26 PM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> > wrote: > > the existence of SRFI > > 26 is not really an argument in favor of SRFI 232. > > > > I think it is cited as related work, not as an argument in favor. It's > common for "related work" to be quite different from the work that cites it. Yes. I think I'll mention in the document that SRFI 232 is not intended as a replacement for SRFI 26. > (2) My biggest complaint about the lambda* form is that the behavior > > is irregular. If I apply as many arguments as there are formals, it > > would make as much sense to return a thunk. The arbitrariness at such > > limit points is a source for future programming errors. > > I agree. I think the correct resolution is to disallow nullary procedures > altogether, with or without tail arguments, since it is entirely unclear > whether to return the procedure or to invoke it. > > In Hemann's terms, this means supporting up to Variant 5 but not 6 or 7, > but including 8, which is independent of the rest and simply provides for > multiple expressions in the body. I think (but I'm not sure) that this is orthogonal to what Marc is referring to; lambda*'s semantics are still somewhat ambiguous when it comes to applying vs. returning a procedure: (define foo (lambda* (a) a)) (foo) ; => procedure (foo 4) ; => 4 (but possibly a procedure?) Here, (foo 4) *could* evaluate to a thunk instead of the result of evaluating its body; it's exactly the same ambiguity that you refer to in the case of directly-created nullary procedures. 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. With this guarantee, the support for nullary procedures added in Hemann & Friedman's Variants 6 & 7 is not a problem; applying a thunk to zero arguments must result in application, because lambda* doesn't return thunks. I might complain about this special-casing of nullary procedures, but it fits nicely. (Another lambda-compatibility feature added by Variant 7 is support for arg-list procedures, e.g. (lambda args ...). I can't see any problems arising from this addition.) On the whole, I think Jason and Daniel put a lot of careful thought into this design. -- Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz> "The Algol compiler was so poorly implemented that we dared not rely on it, and working with assembler code was considered dishonorable. There remained only Fortran." --Niklaus Wirth