|
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