A syntax option (function types versus arrays)

[Jesse Kuhnert]

I think both the "new" and "lambda" keywords sound kind of ridiculous
for obvious reasons. They should be viewed as "blocks" and blocks
currently use {} to denote their boundaries.

This isn't as complicated to understand as everyone seems to think.
I'd imagine a lot of java developers have done some web development at
some point, and of those that have I'd guess that a good number have
had to program in javascript or similar.

Introducing them as "blocks" with special behavior probably makes some
sense, outside of calling them closures. All this hand wringing may
really be for naught.

On Thu, Mar 11, 2010 at 7:52 AM, Reinier Zwitserloot
<reinier at zwitserloot.com> wrote:
> Lambda sounds pretty good to us but does Joe Average like it? Java doesn't
> use the terms co/contravariance anywhere in the syntax either. Is Joe
> Average going to call these things "lambdas"? Why would they know the term?
> Why should they know the term? "Closure", even if its somewhat of a misnomer
> perhaps, is a far more commonly used term in the java community outside of
> the Project Lambda mailing list. Of course, it _is_ a bit of a misnomer so
> using a (limited) keyword "closure" is not the right answer either.
>
> >From a parser perspective, any keyword such as "lambda" needs special
> treatment; in something like:
>
>
> int lambda = lambda;
>
> The term 'lambda' is a standard identifier and *NOT* a keyword, lest
> backwards compatibility is lost, which is a capital offense. I fear that
> this is going to lead to the parser generating obscure and generally wildly
> off-base errors when you mistype a lambda expression and it ends up looking
> like you are using 'lambda' as identifier and not a keyword.
>
> You'd have to weigh all these issues against the "this feels a bit like perl
> cartoon swearing syndrome" that introducing the "#" gives us, and to me its
> starting to look like the # is going to win this particular battle. Yes,
> perl cartoon swearing syndrome is bad, but the other side of this equation
> is worse.
>
> Gut instinct reaction to <> syntax: Not too bad actually. It is indeed a bit
> more consistent in that currently grouping types together is done with <> in
> generics and never with (). There are casts, but that's not really
> 'grouping' types.
>
>
>
> --Reinier Zwitserloot
>
>
>
> On Thu, Mar 11, 2010 at 10:55 AM, Jakob Praher <jp at hapra.at> wrote:
>
>> Alex Blewitt schrieb:
>> > On 11 Mar 2010, at 08:52, Jakob Praher wrote:
>> >
>> > OK, I'll point out the obvious. any 'some letters' are currently a valid
>> identifier in Java, and you can't guarantee that there's no-one in the world
>> who hasn't used the identifier 'lambda' before. So pretty much any construct
>> needs to be either one of the unused keywords in the existing Java language
>> spec (e.g. goto) or something that currently isn't semantically correct in
>> an existing Java program as an identifier (hence the #).  That's not to say
>> that necessarily # has to be the only other choice, but introducing a new
>> keyword based on existing (potentially common) words is likely to cause
>> issues.
>> >
>> Sure that is clear. This was a sentiment to favor a readable letter
>> (this is why I am still convinced that adding declaration-site variance
>> would be best, since then you do not need any keyword at all), not a
>> demand to carelessly introduce a new keyword.
>>
>> If we use an identifier/keyword it MUST convey the right semantics.IMHO
>> the type of a lambda is a function/callable. In computer science theory
>> lambda is a concept for expressing computation, but in Java in its
>> current form it is a synonym for anonymous function with variable
>> capture from the enclosing lexical scope.
>>
>> Remeber that a lambda is the project name:
>> http://blogs.sun.com/mr/entry/closures_qa#comment-1259799344000
>>
>> I do want to use methods as functions too without having to call them
>> lambdas. Sure most of them end up capturing instances away, but in the
>> formal parameters it should called a function or callable or invokable.
>>
>> <T> void filter (Function1<Boolean, T> x);
>> <T> void filter (lambda<bool (T)> x);
>> <T> void filter (func<bool (T)> x);
>>
>> In function based on the typed lambda calulus (e.g. Haskell) on also
>> uses lambda expressions to create anonymous functions. The type of a
>> lambda expression is a function.
>>
>> See also FCM: http://docs.google.com/Doc?id=ddhp95vd_6hg3qhc
>>
>> -- Jakob
>> >
>> >
>>
>>
>>
>
>