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

Yuval Shavit yshavit at akiban.com
Fri Sep 16 06:32:45 PDT 2011


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


More information about the lambda-dev mailing list