On 2022-01-14 08:24 +0100, Marc Nieper-Wißkirchen wrote:
> I don't want to say that I like the new forms very much, but I like
> the old lambda* even less. There's certainly room for improvement for
> lambda-c and lambda-x.

I'm not convinced that these forms are likely to yield much from
further consideration.  The consistency of what we've called
lambda-c in always returning a procedure is precisely what makes it
clumsy in comparison with lambda*; making it more ergonomic would,
I think, require sacrificing this consistency, and then we're right
back to lambda*.

As I tried to say (rather muddle-headedly) in my response to John,
I think the best thing is for lambda* to be specified to never evaluate
to a nullary procedure, and to never create a nullary procedure through
partial application.  Thus (lambda* () ...) is simply a syntax error.

(You could, of course, write a lambda* procedure whose body is a
thunk (created with lambda).  But I don't think this causes any
problems for lambda*.)

I'm afraid that you won't be enthusiastic about this idea.  I'm open
to other ways to improve the form, but I want to preserve the ability
to write something like

    (((lambda* (a b c) ...) x) y z)

and to have that evaluate to the body of the procedure without further
application or syntax.

> The case of fold, which can take an arbitrary number in its original
> form, above shows that sometimes you want the invocation of the
> resulting procedure and that sometimes you don't want the invocation.
> Thus it is best to be explicit here. The question is what is the best
> way to make it explicitly.

lambda* supports variadic (or what Hemann & Friedman call
"polyvariadic") procedures.  A fold variant that's closer to
(scheme list)/SRFI 1 is

    (define fold*
      (lambda* (kons knil lis1 . rest)
        (apply fold kons knil lis1 rest)))

    (define sum (fold* + 0))

    (sum '(1 3 5))          ; => 9
    (sum '(1 3 5) '(2 4 6)) ; => 21

It's true that you can't explicitly request invocation vs.
"accumulation" (of arguments), but we can't do that in vanilla Scheme,
either.  cut provides a sensible way to do this.

> What would work better in your example above is an approach where
> currying/uncurrying does not become a property of the procedure (which
> leads to the problem that all standard procedures don't do it and you
> would have to double them) but where it becomes part of the
> application operation (see also below).

It seems like you're arguing that lambda*-style currying is a poor
fit for Scheme since it can only be used with standard procedures by
creating a wrapper for each.  I agree that it's clumsy to wrap
everything were you to want to make extensive use of curried versions
of standard forms, but this is an extreme case, and wrappers are
already very common in Scheme (for better or worse).  In practice, I'd
expect programs using lambda* to primarily use it in new forms, along
with just a couple of wrapped standard forms.

In short, I don't think we should throw out a currying form because
the standard doesn't use it.

> It would be something like:
>
> (compose (! map make-pair-sum) (! filter prime-sum?) (! append-map pair-up))
>
> Here, ! is cut but with an implicit <...> at the end. Even better
> would be to overload the syntax (map make-pair-sum ...) (with a
> literal ellipsis), but this cannot be done portable. (It can be done
> with Racket's #%app and identifier properties, but we don't have #%app
> standardized in Scheme.)

This is a pretty straightforward wrapper around cut, I think.  As I
want to make clear, SRFI 232 isn't intended to replace cut, so
I'd be happy to see this form added as an extension to SRFI 26.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"More than half of the history of computer science has been lived
under the shadow of our inability to manage the complexity of the
artifacts we have created." --Mike Spivey