Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #28324 > unrolled thread

verifying precedence

Back to article view | Back to comp.lang.java.programmer

Contents

  verifying precedence Roedy Green <see_website@mindprod.com.invalid> - 2014-05-01 04:50 -0700
    Re: verifying precedence leif.roar@invalid.com (Leif Roar Moldskred) - 2014-05-01 07:04 -0500
      Re: verifying precedence Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-05-01 10:35 -0500
        Re: verifying precedence Joerg Meier <joergmmeier@arcor.de> - 2014-05-01 17:40 +0200
          Re: verifying precedence Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-05-01 10:49 -0500
            Re: verifying precedence Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-05-01 17:05 -0500
              Re: verifying precedence Gene Wirchenko <genew@telus.net> - 2014-05-02 10:22 -0700
              Re: verifying precedence "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-05-04 10:53 +0100
                Re: verifying precedence Simon Lewis <simonlewis2001@gmail.com> - 2014-05-04 13:23 +0200
            Re: verifying precedence Arne Vajhøj <arne@vajhoej.dk> - 2014-05-01 18:51 -0400
            Re: verifying precedence Arne Vajhøj <arne@vajhoej.dk> - 2014-05-01 19:00 -0400
            Re: verifying precedence Roedy Green <see_website@mindprod.com.invalid> - 2014-05-01 17:48 -0700
            Re: verifying precedence Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-05-02 13:29 -0400
        Re: verifying precedence Arne Vajhøj <arne@vajhoej.dk> - 2014-05-01 18:50 -0400
          Re: verifying precedence Arne Vajhøj <arne@vajhoej.dk> - 2014-05-01 19:18 -0400
      Re: verifying precedence Roedy Green <see_website@mindprod.com.invalid> - 2014-05-01 17:46 -0700
        Re: verifying precedence Arne Vajhøj <arne@vajhoej.dk> - 2014-05-01 21:27 -0400

#28324 — verifying precedence

consider this line of code:

( Comparator<String> ) (Class.forName( comparatorName
).newInstance());

are the () around Class.forName( comparatorName ).newInstance()
necessary?

You could consult a precedence table, but you could misinterpret it.
Java's rules of precedence and association are quite complicated.

Is there a tool that will tell you:

1. which of your () are nugatory?

2. what your expression means were there no reliance on precedence,
handled purely with ()?

I think this would be a great tool for newbies.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Computers are like Old Testament gods; lots of rules and no mercy. 
~ Joseph Campbell (born: 1904-03-26 died: 1987-10-31 at age: 83)

[toc] | [next] | [standalone]

#28325

Roedy Green <see_website@mindprod.com.invalid> wrote:
> 
> You could consult a precedence table, but you could misinterpret it.
> Java's rules of precedence and association are quite complicated.
>

"Practical Programming in C" summed up the precedence rules in C
thusly:

" Precedence       Operator
      1.            * / %
      2.            + - 

  Put parantheses around everything else."
 
If the meaning of your code depends on the particulars of operator
precedence beyond the very obvious rules above, rewrite it so that it
doesn't. (The same holds for the difference between ++i and i++.)
 
-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#28333

On 5/1/2014 7:04 AM, Leif Roar Moldskred wrote:
> Roedy Green <see_website@mindprod.com.invalid> wrote:
>>
>> You could consult a precedence table, but you could misinterpret it.
>> Java's rules of precedence and association are quite complicated.
>>
>
> "Practical Programming in C" summed up the precedence rules in C
> thusly:
>
> " Precedence       Operator
>        1.            * / %
>        2.            + -
>
>    Put parantheses around everything else."
>
> If the meaning of your code depends on the particulars of operator
> precedence beyond the very obvious rules above, rewrite it so that it
> doesn't. (The same holds for the difference between ++i and i++.)

That's not quite the right rules, but probably because it's ignoring 
half the operators in the first place. I'd remember it as:
1. Unary operators [includes parentheses]
2. * / %
3. + -
4. Relational (<, >, ==, etc.)
5. Logical (&&, ||)
6. ?:
7. = and op=

The position of shift and bitwise operators is the part I can never 
remember: C (by accident of history [1]) put the bitwise below 
relational operators instead of above it (so you have to say (x & mask) 
== mask instead of x & mask == mask). Some descendants fixed the issue, 
while others did not, so as someone who regularly uses several different 
languages, I can never remember if the language I'm in fixed the 
precedence or not.

Note that the table I give glides over the binding of a few operators 
(x++ and ++x are different levels, as are < and ==), but in terms of 
remembering where I need to put parentheses, it's sufficient.


[1] Logical, short-circuit and and or came much later. That's why the 
and pseudo-keyword maps to &, not &&. Arguably, when the logical 
operators had been introduced, the bitwise operators ought to have been 
moved in precedence, but maybe the authors of C didn't want to risk such 
a breaking change at that time.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#28334

On Thu, 01 May 2014 10:35:34 -0500, Joshua Cranmer ������ wrote:

> That's not quite the right rules, but probably because it's ignoring 
> half the operators in the first place.

I believe that's the point. It's saying not to bother with the rules of the
rest and to just use parenthesis instead, and I'm inclined to agree. Even
if you perfectly know operator precedence, it's still hard to read a
complex statements without parenthesis and intuitively grasp what happens.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#28335

On 5/1/2014 10:40 AM, Joerg Meier wrote:
> On Thu, 01 May 2014 10:35:34 -0500, Joshua Cranmer ������ wrote:

^^ Ha, my use of a non-BMP character caught out a newsreader! I'm 
guessing it's trying to encode UTF-8 as CESU-8 instead from the number 
of characters?

>> That's not quite the right rules, but probably because it's ignoring
>> half the operators in the first place.
>
> I believe that's the point. It's saying not to bother with the rules of the
> rest and to just use parenthesis instead, and I'm inclined to agree. Even
> if you perfectly know operator precedence, it's still hard to read a
> complex statements without parenthesis and intuitively grasp what happens.

If you took its recommendations strictly, it would advise you to say:
x = ((a + 5) == (b + c));

I was pointing out that it's missing the implicit levels for the 
"obvious" operators. In truth, the complexity of the situation is with 
the shift and bitwise operators in comparison to everything else and to 
themselves. (And, arguably, comparison operators to themselves: a >= b 
== c <= d is something I would advocate parenthesizing).


-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#28339

On 5/1/2014 2:59 PM, Stefan Ram wrote:
> =?UTF-8?B?Sm9zaHVhIENyYW5tZXIg8J+Qpw==?=  <Pidgeot18@verizon.invalid> writes:

[ Yet more mangling ! :-P ]

>    The learning capabilities of students of Java must be by
>    orders of magnitude smaller than those of students of
>    natural languages, when the students of Java can't memorize
>    the precendence of 37 operators.

Your analogy isn't quite right here. I don't know Italian, but I do know 
some French, so I'll use that here instead in my analogy. French, like 
Italian, has a load of different variants [neglecting accents here 
because this IME doesn't let me do it easily):
* infinitive (etre),
* 6 present indicative (suis, es, est, sommes, etes, sont)
* 6 simple future (ser + ai, ai, a, ons, ez, ont)
* 6 conditional (ser + ais, ais, ait, ions, iez, aient)
* 6 imperfect (et + ais, ais, ait, ions, iez, aient)
* 6 simple past (fus, fus, fut, fumes, futes, furent)
* 6 present subjunctive (sois, sois, soit, soyons, soyez, soient)
* 6 imperfect subjunctive (fusse, fusses, fut, fussions, fussiez, fussent)
* 3 imperative (sois, soyons, soyez)
* Present participle (etant)
* Past participle (ete)

That's a total of 48 forms (if my math is correct), although if you want 
to be a little more precise, 5 of them are repeated. There is a bit of 
structure to it (and etre is an unusually complex verb), but I was 
unable to list the simple past and imperfect subjunctive without 
checking my dictionary. Why? Because I've never had to use them, and 
(with the exception of "il fut"), I've never even *seen* them before.

It's like that with operator precedence: sure, there may not be all that 
much to learn/memorize, but if you never use it, it's going to leave 
your head as quickly as it came in.



-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#28356

On Thu, 01 May 2014 17:05:28 -0500, Joshua Cranmer ?
<Pidgeot18@verizon.invalid> wrote:

>On 5/1/2014 2:59 PM, Stefan Ram wrote:
>> =?UTF-8?B?Sm9zaHVhIENyYW5tZXIg8J+Qpw==?=  <Pidgeot18@verizon.invalid> writes:
>
>[ Yet more mangling ! :-P ]
>
>>    The learning capabilities of students of Java must be by
>>    orders of magnitude smaller than those of students of
>>    natural languages, when the students of Java can't memorize
>>    the precendence of 37 operators.
>
>Your analogy isn't quite right here. I don't know Italian, but I do know 
>some French, so I'll use that here instead in my analogy. French, like 
>Italian, has a load of different variants [neglecting accents here 
>because this IME doesn't let me do it easily):
>* infinitive (etre),
>* 6 present indicative (suis, es, est, sommes, etes, sont)

     Just for fun, "je suis" also means "I follow."

     Quand je cour, je suis le premier.

     When I run I [am|follow] the first.

[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#28360

Joshua Cranmer ?? wrote:

> It's like that with operator precedence: sure, there may not be all that
> much to learn/memorize, but if you never use it, it's going to leave
> your head as quickly as it came in.

One difference here is that, in a natural language, unused forms die out or 
acquire new meanings.  In a programming language (with current tech, anyway ;-) 
that doesn't happen.

So someone using an obscure form doesn't get a "huh?" from the compiler as 
would happen with real speech.  The compiler is quite happy -- /it/ is an 
expert in the language -- but the code may still not be fit for purpose.

Hence the /recommendation/ to use brackets.  It could be seen as dumbing down, 
it could be seen as "common sense".  Another way of seeing it is as 
retroactively "fixing" a discovered flaw in the design of the language -- that 
it has too many precedence levels (even if they aren't scambled).

    -- chris 

[toc] | [prev] | [next] | [standalone]

#28361

"Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> writes:

> Joshua Cranmer ?? wrote:
>
>> It's like that with operator precedence: sure, there may not be all that
>> much to learn/memorize, but if you never use it, it's going to leave
>> your head as quickly as it came in.
>
> One difference here is that, in a natural language, unused forms die out or 
> acquire new meanings.  In a programming language (with current tech, anyway ;-) 
> that doesn't happen.
>
> So someone using an obscure form doesn't get a "huh?" from the compiler as 
> would happen with real speech.  The compiler is quite happy -- /it/ is an 
> expert in the language -- but the code may still not be fit for purpose.
>
> Hence the /recommendation/ to use brackets.  It could be seen as dumbing down, 
> it could be seen as "common sense".  Another way of seeing it is as 
> retroactively "fixing" a discovered flaw in the design of the language -- that 
> it has too many precedence levels (even if they aren't scambled).
>
>     -- chris 

For anyone wanting any maintainability then bracket it. It takes the
guessing out. I wouldn't dumb down the language use in terms of generics
etc but bracketing is a simple thing to so that removes any doubt.

[toc] | [prev] | [next] | [standalone]

#28341

On 5/1/2014 11:49 AM, Joshua Cranmer 🐧 wrote:
> On 5/1/2014 10:40 AM, Joerg Meier wrote:
>> On Thu, 01 May 2014 10:35:34 -0500, Joshua Cranmer ������ wrote:
>>> That's not quite the right rules, but probably because it's ignoring
>>> half the operators in the first place.
>>
>> I believe that's the point. It's saying not to bother with the rules
>> of the
>> rest and to just use parenthesis instead, and I'm inclined to agree. Even
>> if you perfectly know operator precedence, it's still hard to read a
>> complex statements without parenthesis and intuitively grasp what
>> happens.
>
> If you took its recommendations strictly, it would advise you to say:
> x = ((a + 5) == (b + c));

Yes.

I think that is how it should be written.

Arne

[toc] | [prev] | [next] | [standalone]

#28342

On 5/1/2014 3:59 PM, Stefan Ram wrote:
> =?UTF-8?B?Sm9zaHVhIENyYW5tZXIg8J+Qpw==?=  <Pidgeot18@verizon.invalid> writes:
>> I was pointing out that it's missing the implicit levels for the
>> "obvious" operators. In truth, the complexity of the situation is with
>> the shift and bitwise operators in comparison to everything else and to
>> themselves. (And, arguably, comparison operators to themselves: a >= b
>> == c <= d is something I would advocate parenthesizing).
>
>    When one is learning a language such as Italien, there are
>    hundreds and hundreds of individual verb forms one has to
>    memorize. Let us just have a look at « essere » (=»to be«):
>
>    The individual forms of this single verb are: « ente »,
>    « era », « erano », « eravamo », « eravate », « eri »,
>    « ero », « essendo », « essere », « fosse », « fossero »,
>    « fossi », « fossimo », « foste », « fosti », « fu »,
>    « fui », « fummo », « furono », « sarai », « saranno »,
>    « saranno », « sarebbe », « sarebbero », « sarei »,
>    « saremmo », « saremo », « sareste », « saresti »,
>    « sarete », « sarà », « sarò », « sei », « sia », « siamo »,
>    « siano », « siano », « siate », « siete », « sii »,
>    « sono », « sono », « stato », « stati », and « è ».
>
>    The learning capabilities of students of Java must be by
>    orders of magnitude smaller than those of students of
>    natural languages, when the students of Java can't memorize
>    the precendence of 37 operators.

Not really.

It takes people 15 years or so to learn to master their primary
language.

I am sure that if Java developers were allowed to study Java for
15 years, then they could be very good in Java syntax and semantics.

(let us ignore the little practical issue of the language changing
over 15 years)

Java developers typical get maybe 2 years to learn the language.

People also learn second and more languages. But many people keep
making small mistakes in their use of a foreign language. Some people
have talent for languages and can become as good as a native speaker,
but that privilege is not given everyone.

But it is not a big problem. If an Italian hear a foreigner use a wrong
form of a verb it will typically not be a problem as the meaning would
still be obvious.

Programming languages are different. A wrong order of execution result
in a bug.

Arne

[toc] | [prev] | [next] | [standalone]

#28346

On 1 May 2014 19:59:09 GMT, ram@zedat.fu-berlin.de (Stefan Ram) wrote,
quoted or indirectly quoted someone who said :

>when the students of Java can't memorize
>  the precendence of 37 operators.

When you are coding Java, even the tiniest misunderstanding of code
can be catastrophic.  Natural language is much more forgiving.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Computers are like Old Testament gods; lots of rules and no mercy. 
~ Joseph Campbell (born: 1904-03-26 died: 1987-10-31 at age: 83)

[toc] | [prev] | [next] | [standalone]

#28357

On 5/1/2014 3:59 PM, Stefan Ram wrote:
>[...]
>    The learning capabilities of students of Java must be by
>    orders of magnitude smaller than those of students of
>    natural languages, when the students of Java can't memorize
>    the precendence of 37 operators.

     Precendence iz easie; itts spellign thatts harde.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#28340

On 5/1/2014 11:35 AM, Joshua Cranmer 🐧 wrote:
> On 5/1/2014 7:04 AM, Leif Roar Moldskred wrote:
>> Roedy Green <see_website@mindprod.com.invalid> wrote:
>>> You could consult a precedence table, but you could misinterpret it.
>>> Java's rules of precedence and association are quite complicated.
>>>
>>
>> "Practical Programming in C" summed up the precedence rules in C
>> thusly:
>>
>> " Precedence       Operator
>>        1.            * / %
>>        2.            + -
>>
>>    Put parantheses around everything else."
>>
>> If the meaning of your code depends on the particulars of operator
>> precedence beyond the very obvious rules above, rewrite it so that it
>> doesn't. (The same holds for the difference between ++i and i++.)
>
> That's not quite the right rules, but probably because it's ignoring
> half the operators in the first place. I'd remember it as:
> 1. Unary operators [includes parentheses]
> 2. * / %
> 3. + -
> 4. Relational (<, >, ==, etc.)
> 5. Logical (&&, ||)
> 6. ?:
> 7. = and op=

I think it is a pretty good rule.

Use the precedence rules known from very basic math that everybody
knows and use () for the rest.

That reduces the risk of errors. That is good practice.

Arne

[toc] | [prev] | [next] | [standalone]

#28343

On 5/1/2014 6:50 PM, Arne Vajhøj wrote:
> On 5/1/2014 11:35 AM, Joshua Cranmer 🐧 wrote:
>> On 5/1/2014 7:04 AM, Leif Roar Moldskred wrote:
>>> Roedy Green <see_website@mindprod.com.invalid> wrote:
>>>> You could consult a precedence table, but you could misinterpret it.
>>>> Java's rules of precedence and association are quite complicated.
>>>>
>>>
>>> "Practical Programming in C" summed up the precedence rules in C
>>> thusly:
>>>
>>> " Precedence       Operator
>>>        1.            * / %
>>>        2.            + -
>>>
>>>    Put parantheses around everything else."
>>>
>>> If the meaning of your code depends on the particulars of operator
>>> precedence beyond the very obvious rules above, rewrite it so that it
>>> doesn't. (The same holds for the difference between ++i and i++.)
>>
>> That's not quite the right rules, but probably because it's ignoring
>> half the operators in the first place. I'd remember it as:
>> 1. Unary operators [includes parentheses]
>> 2. * / %
>> 3. + -
>> 4. Relational (<, >, ==, etc.)
>> 5. Logical (&&, ||)
>> 6. ?:
>> 7. = and op=
>
> I think it is a pretty good rule.
>
> Use the precedence rules known from very basic math that everybody
> knows and use () for the rest.
>
> That reduces the risk of errors. That is good practice.

Or to quote the Java coding convention:

<quote>
Parentheses
It is generally a good idea to use parentheses liberally in expressions 
involving mixed operators
to avoid operator precedence problems. Even if the operator precedence 
seems clear to you, it
might not be to others—you shouldn’t assume that other programmers know 
precedence as
well as you do.
</quote>

Arne

[toc] | [prev] | [next] | [standalone]

#28345

On Thu, 01 May 2014 07:04:56 -0500, leif.roar@invalid.com (Leif Roar
Moldskred) wrote, quoted or indirectly quoted someone who said :

>  Put parantheses around everything else.

That would do for your own code, but will not help you understand
somebody else's code.

In my scid essay, I figure you should configure just how well you
understand the precedence rules and have your IDE remove excess ()  or
put in extra () to suit without actually changing the code, just the
way it is displayed.

You should also be able to tidy the code to some corporate standard
level of () before checkin.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Computers are like Old Testament gods; lots of rules and no mercy. 
~ Joseph Campbell (born: 1904-03-26 died: 1987-10-31 at age: 83)

[toc] | [prev] | [next] | [standalone]

#28349

On 5/1/2014 8:46 PM, Roedy Green wrote:
> On Thu, 01 May 2014 07:04:56 -0500, leif.roar@invalid.com (Leif Roar
> Moldskred) wrote, quoted or indirectly quoted someone who said :
>
>>   Put parantheses around everything else.
>
> That would do for your own code, but will not help you understand
> somebody else's code.
>
> In my scid essay, I figure you should configure just how well you
> understand the precedence rules and have your IDE remove excess ()  or
> put in extra () to suit without actually changing the code, just the
> way it is displayed.

That could create some small surprises when two developers are
discussing code or if a developer is trying to find the code associated
with a compile error showing source code.

Arne

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web