Am Di., 18. Jan. 2022 um 20:29 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:
>
> 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*.

This probably tells that both are not good forms.

> 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.

It would be consistent to apply the body directly, e.g. that

(lambda* () ...)

would be equivalent to ((lambda ()). As this is hardly useful, it see
why you would like to ban it. In my view, we just see a symptom of
that lambda* as defined is not a good form.

That said if we stick with lambda*, I am not sure whether it is
actually a good idea to ban it; if "lambda*" is interpreted as an
applying lambda (once it has enough arguments), it should stay from
theoretical grounds.

More problematic seems to be

(lambda* a ...)

Correct me if I am wrong but it seems that this has to be evaluated
immediately as well and a just becomes dummy argument.

With a normal lambda, the procedure

(lambda* (a b)
  (values a b))

is equivalent to

(lambda (a . b*)
  (values a (car b*))

(over the domain of the first procedure); with lambda* and its current
special thunk handling, we lose that invariant. (Again, correct me if
I am wrong.)

> (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.

Yes, I am not enthusiastic. :/

In Scheme, a type of kind "(Void) -> T" is not equivalent to a type of
kind "T" as in Haskell because Scheme procedures have side effects.
Here, we muddle the types in an ad-hoc fashion.

> > 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

But you can't do:

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

E.g. you are stuck with one interpretation and again it is not clear
why this and not the other.

> 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.

Together with the fact that, rather randomly, one the arguments from
the rest can be curried, the applicability of lambda* is rather
limited.

> > 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.

Which new forms do you have in mind? Do you expect post-SRFI 232
libraries to export both, say, foo-fold and foo-fold*?

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

I didn't mean that. What I meant is that we can't make currying
procedures the default. But when we need explicit currying versions, I
don't see any advantage compared with a "!" anymore.

> > 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.

I didn't mean that "!" would be equivalent to what SRFI 232 can do;
but in all (few) practical examples of lambda* we have seen so far,
the "!" version wouldn't be less elegant or concise and wouldn't need
any special currying versions of procedures.