Fortran syntax question (involving **)

Quote:

> (snip)

>> Note that this issue is not really directly relevant to the

>> original question of exponentiation. I'd still rather see

>> parenthesis required even if the exponent's value is a literal.

>> Other languages solve this by making unary signs have high

>> precedence. [...]

> C has some interesting precedence problems with the shift operators

> that confuse new (and not so new) users, but it does have both

> unary and binary + and - operators with appropriate precedence.

Well, C has all kinds of problems. The main one being 15 levels

of precedence. That's way too many. New (and not so new) users

often have lots of problems with this complexity - not just limited

to the shift operators. The fact that assignment is an operator and

has lower precedence than ?:, for example. Or the fact that the

bitwise and logical boolean operators have distinct precedences.

fortran now has 11 precedence levels (or is it 12?). That's probably

also too many. Pascal and Ada have 6 levels, which is probably too

few. The trade-off is always a compromise. Too many levels and

the rules get hard to apply correctly in complicated expressions.

Too few and the rules begin to require more parentheses than

clarity of expression would dictate. If you had only one level

you might as well just make all operations into function calls

instead.

One of Dijkstra's last papers addressed the issue of operators and

precedence. He thought that all unary operators should be prefix,

that they should all have the same precedence, and that their shared

precedence should be higher than all other operators. Also, except

for minus (-) and divide (/), he thought that no infix operators should

be used which aren't (mathematically) commutative and associative.

Subtract and divide still alowed because of universal and long-

standing familiarity with them. He didn't even mention concatenate,

which I would have added to the list of allowed exceptions (it's

associative, but not commutative). He also thought that lower

precedence operators should be visibly larger than high precedence

operators and (at least as a coding style) should be required to

be delimited with spaces - in fact, more spaces the lower the

precedence.

--

J. Giles

"I conclude that there are two ways of constructing a software

design: One way is to make it so simple that there are obviously

no deficiencies and the other way is to make it so complicated

that there are no obvious deficiencies." -- C. A. R. Hoare