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)

Re: SRFI 232: An advanced currying form Wolfgang Corcoran-Mathe 18 Jan 2022 18:28 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