As I still firmly believe that lambda* has no place in Scheme, I vote
for no name. :)

Am So., 6. März 2022 um 18:16 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:
>
> Hi all,
>
> Since SRFI 232 is nearing the 60-day mark, I'd like to start wrapping
> it up.  There are a few outstanding issues under discussion, most
> prominent being a better name for lambda*.  So far, I have the
> following suggestions:
>
> * hl-lambda (Daphne)
> * schönfinkel (Marc, semi-serious)
> * lambda/curried (Wezl via IRC)
> * kappa (me)
>
> If there are any others, please let me know.  I'd be happy to do a
> quick naming poll, similar to what Adam did with SRFI 214, if there is
> enough interest.  I tend to think that 'define-curried' is a pretty
> good name for the define wrapper, but this is not set in stone; were
> hl-lambda selected, e.g., I'd probably opt for hl-define.
>
> On another topic, John Cowan has suggested that support for "polyadic"
> (the dotted-tail case of the lambda* semantics, called "polyvariadic"
> in Hemann & Friedman's paper) procedures be removed.  He believes this
> would simplify lambda* and remove a source of potential confusion.  At
> the moment, I'm not in agreement.  Three reasons: I haven't seen any
> polyvariadic examples that I find especially confusing, it's not easy
> to simulate this behavior otherwise, and providing it makes lambda*
> syntactically more similar to lambda.
>
> As for providing the lambda** or lambda*** forms discussed in earlier
> messages, I'm inclined to say that they're too far afield from lambda*
> to be packaged in the same specification.  As alternatives, I'd be
> happy to see them presented in a related SRFI.
>
> Best regards,
>
> --
> Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>