Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!decwrl!shelby!csli!poser
From: poser@csli.Stanford.EDU (Bill Poser)
Newsgroups: comp.lang.icon
Subject: Re: Icon Ideas? (operators)
Message-ID: <12860@csli.Stanford.EDU>
Date: 28 Mar 90 02:30:09 GMT
References: <9003271645.AA17945@megaron.cs.arizona.edu> <9003271919.AA00259@megaron.cs.arizona.edu>
Sender: poser@csli.Stanford.EDU (Bill Poser)
Reply-To: poser@csli.stanford.edu (Bill Poser)
Distribution: inet
Organization: Center for the Study of Language and Information, Stanford U.
Lines: 17

In article <9003271919.AA00259@megaron.cs.arizona.edu> gudeman@CS.ARIZONA.EDU ("David Gudeman") writes:
>
>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.

There is an intermediate approach available in object-oriented languages
as well as in languages like ML that provide disjunctive procedure
definitions. Implement operator overloading as ADDITION of methods for
new data types, but don't allow pre-defined methods (i.e. the built-in
operators) to be removed. This guarantees that an operator will have
the expected semantics when applied to built-in data types and reduces the
uncertainty to derived types.