Why is there no notation for function application?

[Brian Goetz]

This decisions is tightly coupled to two earlier decisions, one that 
preceded Lambda, and one made as part of Lambda:
  - (1995) variables and methods have separate namespaces
  - (2011) Using functional interfaces, rather than structural function 
types, for the types of lambdas.

Obviously the earlier one cannot be revisited, but I'll just point out 
that since variables and methods have different namespaces, using the 
function application syntax you suggest would render expressions like 
foo() ambiguous if there are both variables and methods named "foo". 
(People have suggested other (awful) syntaxes as a workaround for this, 
like f.().  Yuck.)

But, more importantly: we have already made the decision that lambda 
expressions are instances of functional interfaces.  And interfaces 
*already have* a well-defined way to invoke their methods -- by invoking 
their methods.  Adding a new invocation syntax simply makes it more 
confusing about what a lambda is -- and also what an object reference 
is, since this would have to work with any reference to a functional 
interface.

Adding a new and different syntax for doing something that can already 
be done, just this time with a few fewer characters, makes the feature 
more complicated for everyone.  Building on stuff people already know 
makes the feature simpler for everyone.  While you may reasonably regret 
the lack of structural function types, the next best thing is to really 
stick to the decision to embrace nominal function types, and not try to 
live in some half-here, half-there world.



On 9/17/2013 10:43 AM, Millies, Sebastian wrote:
> Hello there,
>
> just out of curiosity: why has no general notation for function application been introduced
> together with lambda expressions? Or in other words: Since there is always exactly one abstract
> method in the type inferred for a lambda expression, why should I still be forced to type that
> out myself?
>
> E. g. in
>
> Function<T, Function<U,R>> curry(BiFunction<T,U,R> f) {
>     return (T t) -> (U u) -> f.apply(t, u);
> }
>
> It would be so much nicer to be able to simply write (T t) -> (U u) -> f(t, u)
> More involved lambdas would profit even more, e. g.
>
> Function<U,R> partial(Function<T, Function<U,R>> f, T t) {
>    return u -> f (t)(u);
> }
>
> For what reason has this been decided against? (Of course, if I wanted to invoke another
> method on the reference in question, I’d still have to say so, but that wouldn’t detract from the
> utility of the shorter notation in the particular case.)
>
>
> n  Sebastian
>
> Software AG – Sitz/Registered office: Uhlandstraße 12, 64297 Darmstadt, Germany – Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Dr. Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com
>
>