Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!uw-beaver!cornell!rochester!PT.CS.CMU.EDU!IUS1.CS.CMU.EDU!edw
From: edw@IUS1.CS.CMU.EDU (Eddie Wyatt)
Newsgroups: comp.lang.c
Subject: Yes me again
Message-ID: <1340@PT.CS.CMU.EDU>
Date: 7 Apr 88 16:06:41 GMT
Sender: netnews@PT.CS.CMU.EDU
Organization: Carnegie-Mellon University, CS/RI
Lines: 41


  I recieved a letter by email in regards to the *a+=*b ambiguaty.
I thought would be nice to post a response to it on the net since it
sums up *my* sentiment on this issue.

> It is ambiguous because "*=" used to be written "=*" and
> lexation wants to take the longest matching string (in a
> left-to-right scan).

But isn't the larget token posible += as it scans left to right, not
=* ?

Actually I'm inclined to believe that += is tokenized as two token and
when =* is seen, it is tokenized as a single token.  So the lexer
reads the input stream as follows.  

	stream		token
  	*a+=*b
	a+=*b		*
	+=*b		a
	=*b		+
	b		=*
			b

To which I've made the statement that tokenizing =* as a single token
is a hack!  I invoke the policy of orthogonality to justify this
statement.  If *= consists of two tokens (implying *= and * = are
equivalent expressions) then =* should be parsed as two tokens.
However, if =* and = * became equivalent then both *a+=*b and 
*a+= *b would become equivalent statements.  Kind  of good
in the sense that the same behaviours will be observed in both
insistance.  Bad in the sense that *a = *b would be interpetted
as what 'a' points to gets what 'a' points to times b.  Probably not
what was intended.

So my overall conclusion is to kill the =(op) construct and quit trying
to support an archaic construct at the expense of "exceptions to the
rule".

-- 

Eddie Wyatt 				e-mail: edw@ius1.cs.cmu.edu