Fortran syntax question (involving **) 
Author Message
 Fortran syntax question (involving **)



Quote:
>What did I miss !?

That this is a reasonably common albeit ill-conceived extension?

g77 has it, PathScale added it in our 1.0 release because it was in
the g77 test suite. I lobbied against it because I didn't like the bad
result when it goes horribly wrong, but I lost...

-- greg
(employed by, not speaking for, PathScale.)



Sun, 16 Dec 2007 06:53:15 GMT  
 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



Sun, 16 Dec 2007 07:05:51 GMT  
 
 [ 17 post ]  Go to page: [1] [2]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software