Path: csiph.com!usenet.pasdenom.info!news.albasani.net!news.luga.at!not-for-mail From: "Peter J. Holzer" Newsgroups: comp.lang.java.programmer Subject: Re: Assigning void Date: Mon, 22 Oct 2012 10:18:43 +0200 Organization: LUGA Lines: 56 Message-ID: References: <1gsagb5e23bgw.1v1kss3azi0d7$.dlg@40tude.net> <1uzdh4wgruckd.17j0ybexezx6n$.dlg@40tude.net> <10ly294mtg6oq$.8c1dav63rhaz.dlg@40tude.net> NNTP-Posting-Host: 2001:1418:100:825e::5 X-Trace: cherenkov.luga.at 1350893923 12163 2001:1418:100:825e::5 (22 Oct 2012 08:18:43 GMT) X-Complaints-To: abuse@luga.at NNTP-Posting-Date: Mon, 22 Oct 2012 08:18:43 +0000 (UTC) User-Agent: slrn/pre1.0.0-40 (Linux) Xref: csiph.com comp.lang.java.programmer:19471 On 2012-10-22 06:43, Peter J. Holzer wrote: > On 2012-10-21 23:25, Peter Duniho wrote: >> The given example in Java is crystal clear, given that only one >> interpretation of the expression can even compile. >> >> That it's ambiguous in C without knowing of operator precedence is >> irrelevant. It's not ambiguous in Java. > > It could still be an error in Java. Java syntax is fixed. The compiler > doesn't go back and try some other other parse tree if the code violates > some semantic constraint. > > Yes, the code is unambiguous. But it is unambiguous because the syntax > is what it is. And the syntax is what it is because it was the same way > in C. If it had been different in C, it would (probably) also be > different in Java and then the code *wouldn't* compile. Here's an example which (hopefully) illustrates what I mean: C got the relative precedence of the bitwise operators and the comparison operators wrong: & has lower precedence than ==, although that's usually not what you want. That could have been fixed in Java, but it wasn't. So given three int variables a, b, and m, consider this expression: a & m == b & m This is parsed as (a & (m == b)) & m which then produces the error message The operator & is undefined for the argument type(s) int, boolean The compiler can't go back and parse it as (a & m) == (b & m) even though that would make sense and is almost certainly what the programmer meant. That's just not how Java (or any other language with a context free grammar) works. So even though one of the interpretations doesn't even compile, the one which doesn't compile is actually the correct one and the the one which would compile is wrong. hp -- _ | Peter J. Holzer | Deprecating human carelessness and |_|_) | Sysadmin WSR | ignorance has no successful track record. | | | hjp@hjp.at | __/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org