Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!CS.ARIZONA.EDU!gudeman From: gudeman@CS.ARIZONA.EDU ("David Gudeman") Newsgroups: comp.lang.icon Subject: Icon Ideas? (operators) Message-ID: <9003271919.AA00259@megaron.cs.arizona.edu> Date: 27 Mar 90 19:19:21 GMT References: <9003271645.AA17945@megaron.cs.arizona.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: inet Organization: The Internet Lines: 32 Date: Tue, 27 Mar 90 09:45:16 MST From: "Kenneth Walker" ]I don't necessarily think being able to arbitrarily redefine operators ]is a good idea. It leaves you with too few features in the language ]whose meaning you can "trust" while reading a program. Ken is doing research that involves optimization of Icon programs by doing static analysis of the programs. Obviously this gets harder as more things become dependent on run-time conditions. Perhaps this is slightly effecting his opinion? ;-) There is an important advantage to overloading operators, though. Suppose you write a calculator program. Of course, inside this program you use mathematical operators. Now suppose you decide to upgrade the program to use complex numbers. You can't just define a new type and write functions to operate on complex numbers, you have to go through the entire program and replace every arithmetic expression such as ``a + b'' with ``add(a,b)'' (if it is in a position to take complex values for ``a'' and/or ``b''). Ick. If you could overload Icon's built-in operators, all you would have to do is overload the arithmetic operators so that they understood complex numbers. I can think of similar examples for non-numeric applications. Someone objected that this lets you do strange things like define + to do subtraction. True enough. But honestly, if a programmer is that determined to make write an unreadable program, he can do it just as easily without operator overloading. There is nothing the language designer can do about obtuseness of programmers, and it seems pointless to try.