Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!umnd-cs!umn-cs!herndon
From: herndon@umn-cs.UUCP (Robert Herndon)
Newsgroups: comp.lang.c
Subject: Re: Disregarding parentheses in C
Message-ID: <1504@umn-cs.UUCP>
Date: Tue, 21-Apr-87 23:54:19 EST
Article-I.D.: umn-cs.1504
Posted: Tue Apr 21 23:54:19 1987
Date-Received: Thu, 23-Apr-87 04:01:12 EST
References: <7019@brl-adm.ARPA>
Organization: University of Minnesota, Minneapolis
Lines: 58
Summary: ARG!!


  ARG!!  I feel I must applaud the efforts of X3J11 for their
heroic efforts to supply a solution to the problem of expression
rearrangement in C.  I doubly applaud them if they've been
suffering through all the nonsense posted so far in this group.
  First:  In programming in C, I almost invariably write
expressions in what I think is THE MOST EASILY UNDERSTOOD
manner.  Thus I may write

#define PI 3.14159265
...
   x = (PI / 4) * (hairy expression, perhaps with a multiplier of 2 or 8);

and ignorantly expect the compiler to rearrange the expression
at its whim.  And happily so.
  Often-times, I also use C as a "machine independent assembly
code".  When I do so, I often define macros for performing
various operations, e.g.,
#define ABS(x) ((x) < 0 ? -(x) : (x))
and again, hope the C compiler doesn't literally evaluate x
repeatedly if it's a macro or expression that can be rearranged.
  Those of us who have a hammer called C available and insist
on looking at numerically critical nails have generally had
to suffer with temporaries.  Those who insist that C should
honor parentheses "because the programmer knows what he means"
obviously don't.  This kind of thinking brings us true behemoths
like {pick your favorite humongous language} that nobody uses.
  X3J11 has tried to satisfy these people without destroying
the reasonable rearrangements C compilers often make.  As a solution:
    1) Unary + is a kluge, but a reasonable, workable
       one that may help some people.
    2) If a solution is REQUIRED, then it or one of the other
       solutions proposed should be used.
    3) If a solution is NOT required, then conforming compilers
       should be allowed to either:
        a) cause the compiler to issue a warning that the expression
           may be rearranged and proceed; or
        b) report a syntax error on encountering the syntax; or
        c) cause the compiler to honor the parentheses
       AT THE COMPILER'S DISCRETION.
  C has a 'minimalist' tradition.  Unfortunately, with the
standardization efforts, creeping featurism is setting in.
This is to be expected to some extent, but obviates many
of the advantages of C -- small, fast, portable...
  My opinion is that neither unary + NOR an explicit primitive
to force associativity should be included in the C standard.
Keep our compilers simple!  They're ALREADY complicated enough.
While I feel that unary + or an equivalent syntax may help
me occasionally, I am not thoroughly convinced that the
added complexity is worth it.  As an author of occasional
translators, I'm sure it's not worth it.  I therefore feel that:
   1. UNARY PLUS SHOULD BE THROWN OUT.
   2. NO EQUIVALENT SYNTAX SHOULD BE PROVIDED.
-- 
Robert Herndon				Dept. of Computer Science,
...!ihnp4!umn-cs!herndon		Univ. of Minnesota,
herndon@umn-cs.ARPA			136 Lind Hall, 207 Church St. SE
herndon.umn-cs@csnet-relay.ARPA		Minneapolis, MN  55455