Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!amdahl!pyramid!hplabs!hp-pcd!hplsla!jima
From: jima@hplsla.HP.COM (              Jim Adcock)
Newsgroups: comp.lang.c++
Subject: Re: User defined operators
Message-ID: <6590048@hplsla.HP.COM>
Date: 27 Apr 88 21:35:40 GMT
References: <1206@its63b.ed.ac.uk>
Organization: HP Lake Stevens, WA
Lines: 23

From the little bit I've messed around with writing "C" language compilers,
I'd guess the restrictions put on overloading operators [IE you're not 
allowed to defined new operators, just to overload existing ones ] 
were chosen to allow C++ to remain compatible with the traditional "C"
compiler approach -- with fixed definitions of what it is we need to lex and
parse [other that the traditional "C" hack of passing typedef info back to the
"lex" part of the compiler]

As your example points out, allowing the user to define his/her own operator
symbols greatly changes how we must interpret a string of non-alphanumerics
in the input file.  Which makes it potentially very difficult for the
reader of that input file to figure out what was meant.

Plus you'd have to give the user means to specify the new operator's precedence
and binding relationships......

Thus, the design of the compilers, the tools used to design the compilers,
and the way C++ users go about trying to read and interpret C++ program
sources would have to change considerably to be able to handle defining new
operators.

I believe the restrictive C++ approach to operator overloading is a good 
practical choice.  To give more flexibility in this area would cause C++
to diverge too greatly from C.