f(x) syntax sugar in Lambda

[Rémi Forax]

On 02/10/2012 05:27 PM, Yuval Shavit wrote:
> This question seems to me to be orthogonal to lambdas. It would apply just
> as well to JDK 7. Basically, the request (if I understand it correctly) is
> that if you have a reference whose type is an interface that defines just
> one method, you should be able to omit the method name in invoking it.
> There's a certain symmetry that establishes with lambdas, sure -- but the
> call site doesn't know if the Exponent it got in was defined as a standard
> class, anonymous class, lambda, proxy, whatever.

The syntax '.()' was already proposed as '.do()' and was rejected for 
several reasons.
As I recall, the main argument was that Java is an OOP language so the idea
is to try to integrate lambdas in the plain old OOP syntax, hence use a 
method call.
JavaScript by example choose the other way, all is functions and methods
are functions stored in objects.

cheers,
Rémi

>
> On Fri, Feb 10, 2012 at 7:33 AM, Brian Goetz<brian.goetz at oracle.com>  wrote:
>
>> I think, ultimately, this is just discomfort with the committment to
>> functional interfaces instead of function types, and an attempt to
>> backpedal towards a wishy-washy middle ground.  I don't see this as
>> offering a compelling enough benefit.
>>
>> On Feb 10, 2012, at 3:42 AM, Spot Al wrote:
>>
>>> What I want to do is just answer on the question:
>>> If it is possible to create a functional interface without using the
>> method name, why it needs to mention the method name using the functional
>> interface?
>>> The most serious objection against using the f(x) invocation is the
>> separate namespaces for methods/fields.
>>> In this case just an another syntax which does not mention the method
>> name can be used. For example
>>> double e = exp.(1);  // or any other better syntax
>>>
>>> What about the last case which use the default methods, creating the
>> lambda expression and using it without mentioning the method name are the
>> same things. So
>>> ------------------------------------------
>>> interface Exponent {
>>>     double calculate(double x);
>>>     void foo() default { ... }
>>>     void bar() default { ... }
>>> }
>>>
>>> Exponent exp = (x) ->  1 + x + x * x / 2;  // which method is defined?
>>> double e = exp.(1) // which method is invoked?
>>>
>>> In both cases we should care about default methods.
>>>
>>> Thanks,
>>> Alexander.
>>>
>>>
>>> 09.02.2012, 13:46, "Maurizio Cimadamore"<maurizio.cimadamore at oracle.com
>>> :
>>>> Hi,
>>>> I think there might be few problems with this approach when unleashed in
>>>> a more widespread way:
>>>>
>>>> *) Java has two separate namespaces for methods/fields - so the
>>>> following would be ambiguous:
>>>>
>>>> Exponent exp = (x) ->  1 + x + x * x / 2;
>>>> void exp(int x) { ... }
>>>>
>>>> exp(3) //?
>>>>
>>>> *) The language does not have such a thing as 'type of a lambda' so,
>>>> there is no way to distinguish between:
>>>>
>>>> SAM s = ()->  { ... }
>>>>
>>>> and
>>>>
>>>> SAM s = new SAM() { ... }
>>>>
>>>> This means that your proposal will apply to all expressions whose type E
>>>> is a functional interface.
>>>>
>>>> *) What if E is a method call? You end up with things like:
>>>>
>>>> Exponent makeExp() { ... }
>>>>
>>>> makeExp()(5);
>>>>
>>>> *) If you have a functional interface with default methods:
>>>>
>>>> interface Exponent {
>>>>      double calculate(double x);
>>>>      void foo() default { ... }
>>>>      void bar() default { ... }
>>>> }
>>>>
>>>> then the fact that the syntactic sugar will rewire the method call to
>>>> 'calculate' (as that's the only abstract method in Exponent) might
>>>> result a bit surprising since there is more than one method available in
>>>> the functional interface.
>>>>
>>>> Maurizio
>>>>
>>>> On 09/02/12 07:41, Spot Al wrote:
>>>>
>>>>>   Hi,
>>>>>
>>>>>   For example if there is an interface
>>>>>   -----------------------------------------------
>>>>>     interface Exponent{
>>>>>         double calculate(double x);
>>>>>     }
>>>>>   -----------------------------------------------
>>>>>
>>>>>   and I have a lambda expression:
>>>>>   -----------------------------------------------
>>>>>   Exponent exp = (x) ->   1 + x + x * x / 2;
>>>>>   -----------------------------------------------
>>>>>
>>>>>   would it be possible to get a value like:
>>>>>      double e = ep(1);
>>>>>   instead of
>>>>>      double e = exp.calculate(1); ?
>>>>>
>>>>>   Where exp(1) just a syntax sugar for the exp.calculate(1).
>>>>>
>>>>>   So if variable a has a lambda type (interface with one method) than
>> a(val1,.., valN) means a.methodName(val1,.., valN)?
>>>>>   Thanks,
>>>>>   Alexander.
>>
>>