Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!haven!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: n && m *= n-- (was programming puzzle)
Message-ID: <16378@mimsy.UUCP>
Date: 14 Mar 89 14:30:37 GMT
References: <24820@amdcad.AMD.COM> <218@umigw.MIAMI.EDU>
Distribution: na
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 33

In article <218@umigw.MIAMI.EDU> steve@umigw.MIAMI.EDU (steve emmerson) writes:
[derivation deleted]
>Precedence rules are needed only when there is more than one way to 
>generate a given expression and (consequently) more than one way to parse 
>it.

This is, of course, correct ...

>They appear to be unnecessary for the above expression.

... but this depends on exactly what grammar you use.  If (e.g.) your
grammar subsumes all `lvalue's under `expression's (arguably a legal
thing to do, as not all identifiers are lvalues and a semantics test is
required anyway), the parse

	e<0> :: e<1> binop<0> e<2>
	e<1> :: e<3> binop<1> e<4>
	e<3> :: identifier = `n'
	<binop>1 = `&&'
	e<4> :: identifier = `m'
	e<1> = `n && m'
	binop<0> :: asgnop = `*='
	<e2> :: ... = `n--'
	<e0> = `n && m' `*=' `n--'

So the question is whether the grammar in question happens to allow
the token sequence `ID && ID' as the lhs of a `*=' assignment operator.

The `correct' C grammar is the one in the pANS, of course; I do not
have a copy, so I cannot say whether it does allow this.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris