Path: utzoo!mnetor!uunet!tektronix!zeus!teklds!daniels
From: daniels@teklds.TEK.COM (Scott Daniels)
Newsgroups: comp.lang.c++
Subject: Re: User defined operators
Message-ID: <3047@teklds.TEK.COM>
Date: 27 Apr 88 18:51:24 GMT
References: <4444@ihlpf.ATT.COM> <1206@its63b.ed.ac.uk>
Reply-To: daniels@teklds.UUCP (Scott Daniels)
Organization: Tektronix, Inc., Beaverton, OR.
Lines: 33

In article <1206@its63b.ed.ac.uk> db@itspna.ed.ac.uk (Dave Berry) writes:
>...I'm not proposing user defined operators should be added to C++; I'm just
>attempting to show that it could be done and to point out some of the problems
>that would need to be resolved.  Please follow up if I've missed anything.

Most of the explained non-problems with operators have to do with lexical 
analysis, solvable easily if by nothing else than whitespace rules.  The 
other problems with operators is determining their precedence.  This is 
a substantial problem to the code reader as well as the compiler.
How does the following associate?:

	a + b operator c * d;

If the answer is not obvoius to the code reader as well as the translator,
you have a nightmare.  One possible solution is to take advantage of an
observetation about precendence in grammars:
	The vast majority of expressions do not require precendence to
	resolve them.
Therefore, you could restrict user operators to use in contexts that provide
unambiguous groupings.  This would make the above illegal, requiring:
	a + (b operator c) * d;
   or   (a + b) operator (c * d);
   or ...

However, you might not be too happy with:
	a = b op c; // illegal
	a = (b op c); // legal
Since '=' is itself an operator.

Perhaps all user-operators are a fixed precedence?  All in all, I think 
the can of worms is larger than the benefit.

-Scott Daniels  (daniels@teklds.UUCP)