Something simpler?

[Knox, Liam]

I dont want to drag this on, but basically if this

[:int] two = (:2);

assert two[] == 2;

Is the 'simplest' proposal of syntax I would fundamentally disagree and yes even your other demonstrated syntax, though not great, is more readable.

________________________________
From: reinierz at gmail.com [mailto:reinierz at gmail.com] On Behalf Of Reinier Zwitserloot
Sent: Friday, March 19, 2010 10:35 PM
To: Knox, Liam (IDEAS)
Cc: Joshua Bloch; lambda-dev
Subject: Re: Something simpler?

On Fri, Mar 19, 2010 at 6:20 AM, Knox, Liam <Liam.Knox at morganstanley.com<mailto:Liam.Knox at morganstanley.com>> wrote:
1. Look at wild cards and Generics and say they are easy to read/understand. They do add complexity

The complexity added by generics is inherent in the code. Since 1.5 it has been made visible. When you see a List you need to know what you can put in it, and what you can expect when you take objects out of it. Making complexities visible makes things easier to understand and less complex to read.

The difference between Levart Brackets and Reinhold Strawman is a completely different story. The semantic complexity is the same, it's just a matter of what's easier to look at.


2. Look at this

[:int] two = (:2);

assert two[] == 2;

a. is it easy to understand?

Yes, once you've been told you're looking at closures. As I've also said ad nauseam, especially the invocation (assert two[] == 2) would look better to me as assert two.() == 2. You're also asking entirely the wrong question. The right question is:

Is it eas*IER* to understand than:

#int() two = ()(2);

assert two.() == 2;

and the answer to me is clearly: Just as difficult, though the one with the brackets is easier to read at-a-glance once you're familiar with the concept. What would possibly cause someone to jump to the conclusion that the empty pair of parens in front of the (2) is a parameter listing? I grant you that {} will most likely suggest 'code block', but parens are used in far too many places to suggest parens list.

b. Does it look like Java ?

No more, and no less, than Reinhold Strawman closures. Which is mostly to say: Less. The following WOULD 'look more like Java' to me, though I'll just call it without the euphemisms: I have a personal preference for:

public interface Producer<T> {
    T produce();
}

Producer<Integer> two = (:2);
assert two.produce() == 2;



3. I did not say I was very concerned if  () was used, do not invent what I said. I said I was concerned with introducing ambiguity.
Of course I know where else () is used, that is not the point.

You defended the use of () as not introducing ambiguity, and/or being intuitive, and I pointed out that the idea that () is intuitive doesn't work, because its already used everywhere and thus has become mostly meaningless.

If you are expressing blocks of behavior use { } as it is most familiar, if you are expressing params use (), if you want to express something else, use something else

The Levart Brackets proposal does use {}. Its alternative colon-based syntax for param usage is specifically as a response to concerns about readability, and to differentiate function types from the closures themselves, something Reinhold Strawman is bad at.


Basically I am coming from a perspective of someone who uses this language everyday for year on end

Just like me then.

Given that I am still using this language and not another one probably says a lot of what a success Java is and paramount to this succes is its simplicity.

Sure. Please define Simplicity. I'd say being able to easily differentiate between a function type and a closure is part of whatever definition you end up with. So is being able to read intent of code at a glance which is harder when a parade of parentheses is involved. Brains are bad at matching parens.


I don't want Java++

Brackets instead of parens means Java turned into Java++? That feels like overstating the case just a tad.


Based on this debate clearly Gosling was right (or lucky) not to add them from the start.

Where is this conclusion coming from? If java used [] for closures from the start you wouldn't be making this complaint, and this mailing list wouldn't be bending itself backwards to attempt to come up with some sort of syntax that is readable, somewhat intuitive, and doesn't conflict with existing java syntax. That last one wouldn't have been a concern if it had been in java from day 1.


--------------------------------------------------------------------------
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.