Mismatch between the order of the type variable and the order of the SAM method formal parameters

[Howard Lovatt]

The method handle api allows binding to any position as does C++. It is
feasible that java post 7 will come up with some syntax for binding as
opposed to the subset of binding, currying. Therefore I would suggest not
worrying about currying [rhyming deliberate!].

On 16 September 2011 23:32, Yuval Shavit <yshavit at akiban.com> wrote:

> I realize Java 8 won't have currying, but it's conceivable that Java N > 8
> may. If Java does get there, it'd be unfortunate if existing code has args
> are in the "wrong" order for natural currying. Though I wonder if one could
> work around it in various ways (optionally curry from the right, curry by
> named params (if those exist at some point), etc).
>
> Anyway, at this point I'm just kind of firing up the "what-if" machine. I
> was originally just wondering if there's a particular reason to put lambdas
> at the end of the args list, and the answer is yes, so I'm satisfied. :)
>
> On Fri, Sep 16, 2011 at 8:54 AM, Rémi Forax <forax at univ-mlv.fr> wrote:
>
> >  On 09/16/2011 02:44 PM, Yuval Shavit wrote:
> >
> > That makes sense, thanks Remi. Of course, if Java had currying *and*
> named
> > parameters, we could have the best of all possible worlds... :-)
> >
> >
> > Java 8 will have no function type so I have some trouble to imagine
> > what you want exactly when you say that Java should have curry.
> > For named parameters, it's a good idea to see if the community want
> > something like that
> > and propose it as an item of Coin2 (the flip side).
> >
> > Rémi
> >
> >
> >
> > On Fri, Sep 16, 2011 at 4:26 AM, Rémi Forax <forax at univ-mlv.fr> wrote:
> >
> >>  On 09/16/2011 01:09 AM, Yuval Shavit wrote:
> >>
> >> Why should the lambda usually come last? I admit I'm fairly new to
> >> functional programming, but it seems that functions/lambdas often come
> first
> >> in methods, which can be useful when currying. I realize that currying
> isn't
> >> part of this project, but it's conceivable that Java would have it in
> the
> >> future.
> >>
> >>
> >>  We talk about function that takes a lambda,
> >> because the lambda can have a body split on several lines,
> >> it's usually more readable to put the lambda at the end.
> >>
> >> You can compare:
> >>   int sum = list.reduce(0, (sum, s) -> {
> >>     if ("".equals(s)) {
> >>       return 0;
> >>      }
> >>      return 1;
> >>   });
> >>
> >> with:
> >>   int sum = list.reduce((sum, s) -> {
> >>      if ("".equals(s)) {
> >>       return 0;
> >>      }
> >>      return 1;
> >>   }, 0);
> >>
> >> The argument after the lambda is too far from the beginning of
> >> the method call.
> >>
> >> Rémi
> >>
> >>
> >>
> >> On Thu, Sep 15, 2011 at 12:00 PM, Rémi Forax <forax at univ-mlv.fr> wrote:
> >>
> >>> On 09/15/2011 05:56 PM, Brian Goetz wrote:
> >>> > In general, it is best if methods that have a single lambda parameter
> >>> have the lambda parameter last.
> >>>
> >>>  I agree for Iterable.reduce, but here it's Reducer.reduce().
> >>>
> >>> Rémi
> >>>
> >>> >
> >>> >
> >>> > On Sep 15, 2011, at 12:30 AM, Rémi Forax wrote:
> >>> >
> >>> >> Hi all,
> >>> >>
> >>> >> Here is the declaration of a Reducer:
> >>> >>
> >>> >>    interface Reducer<T, U>  {
> >>> >>        U reduce(U base, T t);
> >>> >>    }
> >>> >>
> >>> >> and how to use it:
> >>> >>
> >>> >>    Reducer<String, Integer>  reducer = (Integer i, String s) ->  i +
> >>> >> s.length();
> >>> >>
> >>> >> As you see the order of the type argument<String, Integer>  is not
> >>> >> the same as the order of the type of the formal parameter of the
> >>> lambda
> >>> >> (Integer i, String s).
> >>> >> I think it will be simpler if the signature of reduce() was changed
> to
> >>> >> swap the two
> >>> >> formal parameters.
> >>> >>
> >>> >> Rémi
> >>> >>
> >>> >>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
>
>


-- 
  -- Howard.