Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!rpi!crdgw1!camelback!volpe
From: volpe@camelback.crd.ge.com (Christopher R Volpe)
Newsgroups: comp.lang.c
Subject: Re: Problem with #define'd macro...
Message-ID: <18146@crdgw1.crd.ge.com>
Date: 2 Apr 91 14:47:36 GMT
References: <1991Mar20.150301.9941@evax.arl.utexas.edu> <1099@gtenmc.UUCP> <10868@ncar.ucar.edu>
Sender: news@crdgw1.crd.ge.com
Reply-To: volpe@camelback.crd.ge.com (Christopher R Volpe)
Lines: 59

In article <10868@ncar.ucar.edu>, steve@groucho.ucar.edu (Steve
Emmerson) writes:
|>In <1099@gtenmc.UUCP> ravim@gtenmc.UUCP (Vox Populi) writes:
|>
|>>In article <1991Mar20.150301.9941@evax.arl.utexas.edu>
c145gmk@utarlg.uta.edu
|>writes:
|>>>Attempting to compile the following (fragment, but displays the problem)
|>>>results in an 'invalid target for assignment' error on our VAX running
|>
|>>>#define DIV_MOD(d,r,x,y) ( y == 0.0 ? d = 0.0, r = x : d = x/y, r =
x - d*y )
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                          This is the root of the
                              precedence problem because the value "x/y" is
                              being assigned to the result of the conditional
                              operator, which is not an lvalue, and therefore
                              an illegal target for assignment. 
|>
|>>>a = 5, b = 2; DIV_MOD(quotient,remainder,a,b);
|>
|>>I think the compiler error that you were getting is because, operator
|>>precedence is not observed here correctly.
|>
|>I believe the above statement is false because 
|>
|>	1) the string in question (which is an expression):
|>
|>		a == b ? c=d, e=f : g=h, i=j
|>
|>	   can be generated from the K&R1 grammar; and

Compilers complain about plenty of other things besides strings not being
generated from the grammar. Ever hear of undeclared variables?

|>
|>	2) precedence is irrelevant in determining whether or not a string
|>	   is valid.
           
The compiler didn't punt with a parse error, did it? It parsed it
the "wrong" way of the two possible ways (given the grammar and ingoring
the precedence rules.) By "wrong" I mean in terms of what the programmer
wanted. It was right according to the precedence rules. The problem was
not that the syntax was violated, but rather that, because of the
precedence rules, an assignment was made to a non-lvalue.

|>Precedence, on the other hand, is a tool used by parsers to
|>disambiguate between two or more ways of generating the same string
|>from a given grammar.  The validity of a given string, however, is
|>determined solely on the basis of whether or not it can be generated by
|>the production rules of the grammar. 

Compilers do not compile by syntax alone. The grammar is not a complete
definition of the language.

==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com