Ultra-basics -- could re-wording these definitions at least partially reduce widespread confusion?

[Jesse Silverman]

From the Sybex 815 Glossary:
operator precedence The order in which operators are evaluated.
order of operation See operator precedence.

I am not sure on this, but I think some significant degree of confusion on what these mean is from their brief descriptions.

Longer presentations, correctly I think (even I sometimes get this muddled, and just prefer to liberally clarify my expressions with parentheses) describe it as just placing implicit parentheses before evaluation, as if to re-write:
z = ++x * a - b;

into:
z = ( (++x)  * a ) -  (b);

etc.

The short descriptions as seen above (just picking on them because I am using those books to review) seems to lure many people into thinking that huge complex expressions get scanned, and then it picks out all the highest precedence operations and completes them, then it goes thru and performs all the next-highest precedence operations, and so on, down and down and down.  The whole notion of left-to-right goes out the window, as well as short-circuit.

I am not sure I have a good solution I am presenting, but when I look at those brief descriptions which everyone reads everywhere, and imagine myself not knowing anything already, that's what it indeed sounds like.

Precedence and associativity (in the case of equal precedence) tell you who will win the battle for an operand stuck between two of them.  In every case they can just be thought of as implying parentheses.

In some languages, we can't say what the order of operand evaluation is, but in Java we are in easy town because it is guaranteed to be left-to-right.

I'm just saying this in the hopes of reducing the amount of confusion in the world on these issues.

When I see Campbell and Company answering the questions for the eighteen millionth time, I am reminded of the line from the John Entwistle song on "Who By Numbers", "Success Story"...

Take two hundred and seventy SIX -- you know this used to be fun??

Note: I've written full expression parsers when I was a kid, both in C many times and once in a four-hour long 8085 Assembly Language Closed-Book Final.  Flashing back to the latter makes me wonder if it is true that men can never really understand the experience of childbirth...I still experience shudders on flashbacks...I am not sure suggesting people write these to understand precedence and associativity better is a solution that scales well to address the problem in the general population.

[Campbell Ritchie]

Jesse Silverman wrote:. . . operator precedence The order in which operators are evaluated. . . .

Agree you could write, “Decides which of two operators appiled to the same operand is executed first.”

z = ++x * a - b;

What about reversing that expression?
z = b - a * ++x;
What about changing that expression to use only one variable?
z = x - x * ++x;

. . . picks out all the highest precedence operations and completes them . . . left-to-right goes out the window . . .

I see what you mean, yes.

. . . questions for the eighteen millionth time . . . .

I have never answered the same question more than a million times.

[Jesse Silverman]

Both Roel, whom I don't think I have ever met "live", and Henry Wong, who went to Engineering School with me if I am not mistaken, have many wonderful suggestions here:
https://coderanch.com/t/640520/certification/Evaluating-boolean-expression-assignments-short

The very fact that there are so many threads on the same topic leads me to recall a phrase Howard Lyman used to love repeating:
"To get out of a hole, first, stop digging!"

I am totally not ragging on Jeanne and Scott, I love their books and treat them with a respect rarely seen in the Secular World, but I think those pat statements translate to a high degree of the misunderstandings we keep fighting (tho, as I always say, if one follows style guidelines to avoid complex expressions in production code that require remembering precedence and associativity tables to interpret correctly, less important in real life)...

I think even if someone understands the whole story as explained by Roel somewhere in that thread, and even if someone has coded an expression parser a really long time ago, that those neat definitions violate the rule:

Make all explanations as simple as possible, but not simpler.

I can never explain everything as well as Roel has, but I think that these very common, very brief definitions are inadvertently contributing to the rampant misunderstandings.

[Stephan van Hulst]

Jesse Silverman wrote:operator precedence The order in which operators are evaluated.

You are correct. This description is absolutely wrong. Operator precedence has NOTHING to do with order of evaluation.

Campbell Ritchie wrote:Agree you could write, “Decides which of two operators appiled to the same operand is executed first.”

This is also not correct. If you can say that two operators apply to the same operand (meaning you can put parentheses around just the operand and it wouldn't change the expression), it means you've already decided which operands the operators apply to, and operator precedence no longer matters to anything anymore.

The entire point of operator precedence is determining which operands belong to which operators.

Phrases like 'evaluation' and 'executed first' should never be mentioned in the same sentence as 'operator precedence', except when you say "Operator precedence has NOTHING to do with order of evaluation".

[Mike Simmons]

Regarding the idea that left-to-right goes out the window... it's important to distinguish between evaluating operands, and evaluating operators.  The operand evaluation is often trivial, so it's easy to overlook, but it's there, and it's always left-to-right... with the possibility of skipping some elements due to short circuiting.  This can be seen in Campbell's examples, with a little helper method.  

    public static void main(String[] args) {
        int x = 1, y = 2, z = 3, a = 10, b = 20;
        System.out.println("first");
        z = show("x", ++x) * show("a", a) - show("b", b);
        System.out.println("second");
        z = show("b", b) - show("a", a) * show("x", ++x);
        System.out.println("third");
        z = show("x1", x) - show("x2", x) * (show("x3", ++x));
    }

    private static <T> T show(String label, T t) {
        System.out.println(label + ":" + t);
        return t;
    }

Note that I couldn't find a way to use that helper method inside the argument to a ++ operator - if you write

++show("x", x)

it just doesn't work.  But other than that, you can see that for the operands, they are all evaluated left to right.  It's when you evaluate the operators where precedence and parentheses become important.

[Stephan van Hulst]

Mike Simmons wrote:It's when you evaluate the operators where precedence and parentheses become important.

No. Evaluation is a runtime operation. Operator precedence only figures in at compile time to create an expression tree out of an expression.

[Mike Simmons]

And yet, the order it occurs in, at run time, is affected by the precedence, which was determined at compile time.  In expression like  x + y * z, we know that the runtime evaluation of the multiplication occurs before the evaluation of the addition, because if it didn't, we wouldn't get the results we do.  I'm not sure how you can say these things have nothing to do with each other.

[Mike Simmons]

Stephan van Hulst wrote:Phrases like 'evaluation' and 'executed first' should never be mentioned in the same sentence as 'operator precedence', except when you say "Operator precedence has NOTHING to do with order of evaluation".

Well, you're welcome to argue with the authors of the JLS about that...

15.7. Evaluation Order
 15.7.1. Evaluate Left-Hand Operand First
 15.7.2. Evaluate Operands before Operation
 15.7.3. Evaluation Respects Parentheses and Precedence
 15.7.4. Argument Lists are Evaluated Left-to-Right
 15.7.5. Evaluation Order for Other Expressions

 
 

JLS 15.7.3 wrote:15.7.3. Evaluation Respects Parentheses and Precedence

   The Java programming language respects the order of evaluation indicated explicitly by parentheses and implicitly by operator precedence.

[Stephan van Hulst]

And I will.

Notice that the entire paragraph has nothing to do with operator precedence, and only (erroneously) mentions operator precedence in the one sentence that you quoted. Even then, it is clear that is written as an offhand introductory text, and not as a technical definition.

Operator precedence does not imply order of evaluation, explicitly or implicitly. Not even operator associativity implies order of evaluation.

The only thing that paragraph really says is that if an operator is mathematically associative, a Java implementation may not make use of that fact to rewrite expressions. Mathematical associativity is a completely separate concept from Java's concept of left-/right-associativity.

This is a wonderful example of how mathematicians and programmers are both terrible at naming things, but both in their own way.

[Jesse Silverman]

I think the best description of this stuff (outside of the appropriate threads here) that I'd read was in the preparation book for the now-discontinued 815 by Hanumant Deshmukh of Enthuware.

It seems clear that the way the World commonly describes these things, at least when they write in brief, contributes to ongoing waves of misunderstanding among new generations of developers.

I'd say more than that, even among long-term developers.  I'm not sure it shows here, but I have been able to explain to actual developers why their actual code wasn't behaving in the way they thought scores, or possibly hundreds of times.

I wish I had said this neat sentence:

The entire point of operator precedence is determining which operands belong to which operators.

I tried to get at that in my original post, but fell short.

Notably, when I did do expression processing code, I believe it was always in interpreters, so there was no distinction between compile-time and run-time.  I either evaluated or pushed onto the stack each thing as I came to it.  Also, Ronald Reagan or George H. W. Bush were President.  Java didn't exist yet...some of the details might have gotten fuzzy.  Lex and Yacc existed and I knew about them, but didn't use them, even in C.

A small number of very clear-headed developers actually have this all straight in their heads, but not many.

I think it was the thread that I referenced that included the advice that if you could correctly understand what happens in their three or six or nine examples, you should probably be good for the certification exams and could safely move on, but years later we are still commonly providing both new people and those reviewing sub-optimal brief definitions of the terms, and reinforcing misunderstandings.

If we came up with better ultra-brief and brief descriptions of the terms and principles I think it would help, some will never read beyond that and others will forget the more detailed explanations and be refreshing (or contaminating) their mental model from those later.

[Mike Simmons]

I completely agree with

Stephan van Hulst wrote:The entire point of operator precedence is determining which operands belong to which operators.

And I very much disagree with

Stephan van Hulst wrote:Operator precedence has NOTHING to do with order of evaluation

This sentence can however be salvaged by adding "of operands" at the end.  Then it's fine:

Operator precedence has NOTHING to do with order of evaluation of operands

But without that, it sounds a lot like saying that precedence has no effect on the order of evaluation of expressions.  And that's frankly nonsense.   Consider:

        int x = 3, y = 4, z = 5;
        System.out.println(x + y * z);

If someone asks why this prints 23, rather than 35, you really can't explain it without the fact that because multiplication has precedence over addition, the multiplication happens first.  You can use other words if you want, but at some point, at run time, the processor is going to compute 4 * 5, and it's going to do that before it computes 3 + 20.   If the precedence had been different, it might have computed 3 + 4 first, then 7 * 5.  But it didn't.  The precedence of the operators has a real, tangible effect on whether a multiplication or an addition is executed first.  That's the order of evaluation of the operations.  Not of the operands, but of the operations.

Stephan van Hulst wrote:Notice that the entire paragraph has nothing to do with operator precedence, and only (erroneously) mentions operator precedence in the one sentence that you quoted. Even then, it is clear that is written as an offhand introductory text, and not as a technical definition.

It was mentioned in the sentence I quoted, which was the very first sentence.  It's also mentioned as the title of that section.  You may label it an error, but it makes sense enough to me.  The rest of the section does, indeed, talk about some of the consequences of operator precedence.  Not all of them necessarily, but some specific issues that are not covered elsewhere.

You are correct that it doesn't define the term. I believe the JLS doesn't define the term precedence at all.  As we've discussed previously, it's mostly addressed implicitly through the expression production rules.  It does sort of define "evaluated", as a synonym of "executed".  But that's neither here nor there.  Neither of us have provided formal definitions of most of what we're saying, yet here we are.  Jesse is looking for simple ways to explain these concepts that won't mislead people.  In that context, "Operator precedence has NOTHING to do with order of evaluation" is badly misleading.

Stephan van Hulst wrote:Operator precedence does not imply order of evaluation, explicitly or implicitly.

Sure it does.  See code example above.  Maybe you mean order of evaluation of operands.  That's why I previously suggested making this distinction.   Order of evaluation of operands and order of evaluation of operations are not the same thing.

Stephan van Hulst wrote:The only thing that paragraph really says is that if an operator is mathematically associative, a Java implementation may not make use of that fact to rewrite expressions.

It says both more than that, and less (i.e. your restatement is too restrictive).  But that's just getting further into the weeds.  I agree that the primary JLS statements about precedence are elsewhere, and implicit rather than explicit.  I just isolated a quote that most directly contradicted you, even if the real meat is mostly elsewhere.

@Jesse, thanks for starting this topic; I do agree it would be useful to find short simple ways to explain things without misleading people.  But as you see, that can be easier said than done.  As Einstein allegedly said (maybe apocryphal, too lazy to research carefully), everything should be as simple as possible - but no simpler.

[Paul Clapham]

I think one of the things that beginners tend to overlook is what it means to "evaluate" an operand. Let's take your example 3 + 4 * 5.

The first thing that happens is that the first operand, 3, is evaluated. The result of that of course is 3. Now right away the beginner is saying "What? There's no evaluation going on there!" Now if you're old enough to remember assembly language, that "evaluation" used to involve putting 3 into a register of some kind. Now in Java it includes (conceptually) putting 3 somewhere so that it can be used later when the "+" operator's operands have been identified and it's applied to those operands. But to the beginner it looks like evaluating 3 and getting 3 doesn't count as doing anything and so it can be left unconsidered.

So I think that the instruction guides which describe "order of operations" ought to be spelling this out for beginners. And who knows, maybe some of them do that. The JLS doesn't, I see, but then it isn't meant to be a document for training beginners.

[Mike Simmons]

Yup.  From my first post:

The operand evaluation is often trivial, so it's easy to overlook, but it's there, and it's always left-to-right...

[Campbell Ritchie]

Paul Clapham wrote:. . . what it means to "evaluate" an operand. . . . spelling this out for beginners. . . . The JLS doesn't . . .

I thought it has a section about, “evaluate operands before operators.”

[Jesse Silverman]

In the first person, I can say that I personally expect to be consulting the JLS more than I had been.

I had noted in other threads, that in "Old" certification prep books, one was exhorted, urged and most strongly recommended to consult the JLS early and often, and to not over-rely on just the Javadocs.  Some also pushed becoming familiar with the JVM specs, which seem to be even less commonly considered required reading for "average" developers nowadays.

While some people often still exhort JLS-Consultation, (I'm thinking of you Campbell), and I have been finding it eminently readable compared to similar authoritative sources for say, C++ or SQL, which can be so difficult to read that one can't even expect authors to have successfully digested them...

it seems that tho book authors and creators of mock exam materials should all be regularly consulting it, the community no longer expects the majority of people trying to work in Java to be regularly reading it.  When the answer to a question being posed can be determined by an average reader from some section of the JLS, it seems quite appropriate to refer to it in an a reply to a query.

My original point still stands, in that it seems not just for people trying to learn but even a fair number who are providing the tutorial materials, the scope of RTFM does include the API docs, but includes reading the JLS less often than it did historically.

If the most popular entry-level materials, FAQ's, glossaries, etc. can be made to mislead fewer people learning from them, everyone answering questions can spend more time reading and debating JLS materials, and perhaps more importantly contributing to discussions regarding the details of future changes to Java before they get set in stone, as well as doing their day jobs.

I want to take a moment to write a sentence I've only implied in other posts:
At the moment, I think "Because JavaRanch/CodeRanch" has moved to near the very top of the "Pros" list of "Pros and Cons Of Working In Java Versus Other Platforms" for me.
The simultaneous combination of high levels of expert knowledge and an open, friendly attitude towards visitors with all sorts of different prior experience levels seems near unparalleled.

[Campbell Ritchie]

Jesse Silverman wrote: . . . "Old" certification prep books . . . strongly recommended to consult the JLS early and often, and to not over-rely on just the Javadocs. . . .

The JLS and API descrtibe different things with very little overlap; people should read both.

. . . eminently readable compared to similar authoritative sources for say, C++ or SQL . . .

My, those resources must be really badly written!

. . . the community no longer expects the majority of people trying to work in Java to be regularly reading it. . . .

Don't now about that; I hope people still are reading the API and JLS as appropriate.

. . . for . . . a fair number who are providing the tutorial materials, the scope of RTFM does include the API docs, but includes reading the JLS less often than it did historically.

Which tutorials? Some I have seen are so bad, I wonder whether the providers have read anything.

. . . high levels of expert knowledge and an open, friendly attitude towards visitors . . . .

Thank you.

[Paul Clapham]

Campbell Ritchie wrote:

Paul Clapham wrote:. . . what it means to "evaluate" an operand. . . . spelling this out for beginners. . . . The JLS doesn't . . .

I thought it has a section about, “evaluate operands before operators.”

Well, yes, it does, but it focuses on situations where evaluation of an operand has side effects. It doesn't bring out Captain Obvious's Hammer.

[Mike Simmons]

Paul Clapham wrote:

Campbell Ritchie wrote:

Paul Clapham wrote:. . . what it means to "evaluate" an operand. . . . spelling this out for beginners. . . . The JLS doesn't . . .

I thought it has a section about, “evaluate operands before operators.”

Well, yes, it does, but it focuses on situations where evaluation of an operand has side effects. It doesn't bring out Captain Obvious's Hammer.

Yeah, that section in particular says a bit about when operand evaluation occurs.  Nothing about what it actually is.  That stuff was spread around earlier in chapter 15, but it's, you know, the JLS, so not exactly beginner-friendly.