Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!brl-adm!adm!rbbb@rice.EDU
From: rbbb@rice.EDU
Newsgroups: comp.lang.c
Subject: Re: C and Floating Point (really parentheses)
Message-ID: <6748@brl-adm.ARPA>
Date: Tue, 7-Apr-87 22:31:37 EST
Article-I.D.: brl-adm.6748
Posted: Tue Apr  7 22:31:37 1987
Date-Received: Sat, 11-Apr-87 03:24:54 EST
Sender: news@brl-adm.ARPA
Lines: 41


   We who use your compilers would create our product cheaper and better
   if you who design the languages would spend more time worrying about
   readability, writeability, intuitiveness, and maintainability, and less
   time worrying about the efficiency of execution of the language.  It is
   not a _minor_ matter when a piece of code doesn't execute the way it
   reads, and it is not a _minor_ matter when someting like the proposed
   unary plus override on parenthesis evaluation order is added to a
   language.  It is a utility destroying set of blunders by the language
   designers.

Agreed.  Respecting parentheses will not BREAK any existing programs,
though they may run more slowly.  (People have been harping on and on
about taking potential optimizations away from the compiler; are there
really any C compilers that are that gung-ho about reordering
expressions?)

Suppose instead that some other form of parentheses (what I don't know) be
designated as the optional parentheses.  These could be used in macro
definitions, thus taking care of the argument about "macros introducing
tons of parentheses" while leaving ordinary code about as readable as it
ever was.  Of course, this will make expanded macros less readable, but
this is not a day-to-day concern.

Note that this approach requires more effort to make code go fast.  The
other approach (unary + to indicate order of evaluation) requires more
effort to make code robust.  Guess which one I favor.

Before you pooh-pooh the "+() is more effort than ()", consider what is
usual in other uses of parentheses, and consider the arguments put forth
in K&R (p.17) for "="/"==" instead of ":="/"=".

Another approach is to follow the current approach strictly.  If it
happens that the operators are not commutative and associative, then
respect the parentheses.  If this is truly the case, then I have no
problem with the current approach.  Of course, floating point arithmetic
is not associative, and machine arithmetic is not associative in general
in the presence of overflow exceptions.  Too bad--I guess parentheses must
be respected after all.

David