schmidt@green.cs.wisc.edu (Perry Schmidt) (10/12/89)
In Ada, when building boolean expressions you must put ANDs and ORs (and
OR ELSES, etc) in parents IF you use them in mixed combination.
Ex. (A and B or C) -- is not legal. You must write it as...
(A and (B or C))
So the question is -- WHY?
Does this remove some semantic ambiguity? Or is it just the "Ada style!"
Thanks for any responses...
Perry Schmidt
(schmidt@green.cs.wisc.edu)aldona@pyr.gatech.EDU (STEPHEN D. STRADER) (10/12/89)
In article <8834@spool.cs.wisc.edu> schmidt@green.cs.wisc.edu (Perry Schmidt) writes: >In Ada, when building boolean expressions you must put ANDs and ORs (and >OR ELSES, etc) in parents IF you use them in mixed combination. >Ex. (A and B or C) -- is not legal. You must write it as... > (A and (B or C)) >So the question is -- WHY? BECAUSE! No, actually it is to remove ANY ambiguity as to how the expression should be evaluated. Saright? S
firth@sei.cmu.edu (Robert Firth) (10/12/89)
In article <8834@spool.cs.wisc.edu> schmidt@green.cs.wisc.edu (Perry Schmidt) writes: >In Ada, when building boolean expressions you must put ANDs and ORs (and >OR ELSES, etc) in parents IF you use them in mixed combination. >So the question is -- WHY? There is no problem of semantic ambiguity, any more than with, say, A + B*C. The reason for the restriction is that one of the language designers believed the relative priorities of the Boolean operators were sufficiently unfamiliar to the general run of programmers that expressions such as A and B or C could cause confusion or, worse, be misinterpeted.
stt@inmet (10/13/89)
Ada tried to use the "conventional" precedence rules when defining operators. However, it has never been entirely clear where XOR belongs relative to AND and OR, nor how regular AND and short-circuit AND THEN should fare relative to one another. The net result was that they "punted" in this area and said use parentheses when using two logical operators in sequence. It might have been ideal in some people's mind if at least AND had clearly higher precedence than OR so that your example could be coded without parentheses, but Ada has always tried to err on the side of readability over writability. S. Tucker Taft Intermetrics, Inc. Cambridge, MA
karl@grebyn.com (Karl Nyberg) (10/13/89)
I had a friend call yesterday after spending five hours trying to figure out why some C code didn't work based on this expression: if (variable & MASK == VALUE) He mistook the rules of precedence, just as Robert Firth expressed it in his response. The K&R book explains this reasoning: Note that the precedence of the bitwise logical operators &, ^ and | falls below == (test for equality) and != (test for inequality). This implies that bit-testing expressions like if ((x & MASK) == 0) ... must be fully parenthesized to give proper results. [p. 49] Seems like it was kind of the Ada designers to preclude this from the language. Getting an error during compile time would have saved my friend immense difficulty. Getting a manual might have helped him, too... -- Karl --
horst@pcsbst.UUCP (horst) (10/13/89)
In article <8834@spool.cs.wisc.edu> schmidt@green.cs.wisc.edu (Perry Schmidt) writes: > >In Ada, when building boolean expressions you must put ANDs and ORs (and >OR ELSES, etc) in parents IF you use them in mixed combination. >... >Does this remove some semantic ambiguity? Or is it just the "Ada style!" Yes, there is an ambiguity. The precedence of 'and' and 'or' is not so commonly agreed as that of '*' and '+'. So the designers chose to require parenthesis. Regards, horst
simpson@trwarcadia.uucp (Scott Simpson) (10/16/89)
In article <8910122337.AA06188@grebyn.com> karl@grebyn.com (Karl Nyberg) writes: >I had a friend call yesterday after spending five hours trying to figure out >why some C code didn't work based on this expression: > > if (variable & MASK == VALUE) Your buddy didn't use lint. It would have caught this. Scott Simpson TRW Space and Defense Sector usc!trwarcadia!simpson (UUCP) trwarcadia!simpson@usc.edu (Internet)