Project Lambda: Java Language Specification draft 0.1.5

[Stefan Schulz]

On 16.02.2010 11:51, David.Moss at ubs.com wrote:
>> I don't think it's worth introducing this faulty looking syntax
>> for a really marginal gain.
>> If it cannot be made function-invocation syntax, I'd advocate
>> for making it Java style rather than going Perl-like.
>
> I disagree with this view. This is not "faulty looking syntax", it is
> "new syntax", much the same way the enhanced for loop or generics would
> be faulty syntax under java 2, but valid after being introduced in a
> later version.

I say it's faulty, because as a Java developer i expect a method name 
after a dot. The syntax
   Identifier '.'
is not new, as you imply, but is a fragment of an already existing 
syntax. It cannot be compared to generics, as these had a completely new 
syntax not raising any expectations before being introduced.

 > Furthermore, the var.() call is perfectly appropriate for
> an anonymous function, as it has no name.

I think, you are mixing the function with the way to invoke it. The 
function you refer to is stored in "var" (maybe a reference to a block 
of code or whatever works). What we are looking at here is a means to 
execute the function "var" refers to. And to me, if we cannot have 
functions as first class elements in Java (see below), the syntax for 
executing a function should be similar to operating on an object. 
(Objects are anonymous as well, but a programmer knows about their API. 
I'd expect a lambda to conform to some function type API as well.)

 > The alternative would be to
> make the named variable look like a method call, i.e. var(), which is no
> less "faulty looking syntax", but more confusing,

This syntax does not look faulty and actually would be the correct way 
of invoking a function (similar to a method), as most programmers would 
expect. The only reason it is out of discussion are the problems with 
name spaces and conflicts wrt. methods.

Cheers,
Stefan