New

[Howard Lovatt]

You could introduce a class called Lambda (or Function) into java.lang then
you could write:

Lambda<int()> l = new Lambda<>(42);

Something similar is proposed for MethodHandles by JSR 292.

However I guess this discussion also falls under Alex's ruling that syntax
discussions aren't to be considered. I am unclear as to whether semantic
discussions are to be considered.

On 30 March 2010 15:29, Pavel Minaev <int19h at gmail.com> wrote:

> On Mon, Mar 29, 2010 at 10:11 PM, Paul Benedict <pbenedict at apache.org>
> wrote:
> > On Mon, Mar 29, 2010 at 8:51 PM, Howard Lovatt <howard.lovatt at gmail.com>
> wrote:
> >> I think the strongest argument that anyone has made against using 'new'
> is
> >> your "economy of expression" argument, it then comes down to trading off
> >> conciseness against consistency and clarity. I go with consistency and
> >> clarity and you go with conciseness. I guess Alex or someone at Sun will
> >> decide :)
> >
> > At one time, the "lambda" keyword was thrown around as an option. Any
> > thoughts to floating that idea around again? I suppose it was supposed
> > to function in the language like the "new" keyword:
> >
> > #<int()> foo = lambda #<int()>(42);
>
> If you already have # there, then "lambda" serves no purpose
> whatsoever. # alone is enough to indicate the start of the lambda.
>
> If you don't use #, then you have to add it as a new reserved keyword
> - meaning that any existing Java code which uses "lambda" as
> identifier won't compile anymore. Nor can you make it an unambiguous
> context keyword, because, when generics are involved, you can get
> something like:
>
>   lambda <A<B>(C<D> e)> (e + 1)
>
> which is a perfectly valid expression as far as they go:
>
>  (((lambda < A) < B) > ((C < D) > e)) > (e + 1)
>
> Of course, it'll never type-check, but that doesn't stop it from being
> valid grammar for an expression, which is enough to confuse the
> parser.
>



-- 
 -- Howard.