Re: Definable operators

Henry Spencer <henry@zoo.toronto.edu> wrote:
> I heard an interesting rule of thumb recently -- although my leaky
> memory is now refusing to tell me who said it -- to the effect that
> operator overloading works very well so long as the data objects are
> *numbers* of some sort, or very close analogs of numbers, and very
> poorly otherwise. I think there's a lot of truth in that.


I can only agree with this up to a point. I have found operators to
be invaluable in other domains as well (and I will let the interested
reader decide where these are merely isomorphisms to numbers!):


(*) Anywhere where comparison is natural, "=" and "/=" should be
defined. These may have no analog with numbers at all. Similarly where
there is a natural ordering relation (even a partial one) "<", ">",
etc., should be defined. The analog with numbers may not be at all
obvious with some of these - sets are often a better concept to work
from.


(*) Strings are an obvious case of above - it still beggars belief that
the widespread programming language of our era cannot compare strings
without recourse to a library *function*. There are other good string
operations to define operators for: concatenation ("+" is acceptable in
my mind, F90 uses "//"), simple inclusion tests and substring selection
(remember Basic!). Regexps are much easier to manipulate with separate
operators than the usual highly escaped string - with our A68 compiler
we provide a pattern matching library more akin to SNOBOL than
grep-style regexps.


(*) The manipulation of lists, trees and graphs can also benefit from
similar definitions. Another style of operator that is useful here is
an 'iterator': within the compiler I have a set of "WALK" operators that
take a top node and a function over a node that is to be applied to
all children of the top node.


(*) I/O can be written quite elegantly with a small collection of
operators: assignment-like operators between file and value or variable
and file can make putting and getting cleaner; and formatting operators
which replace the library-defined syntax of the format string in C's
printf or the language-defined syntax of Fortran formats. (Holdsworth
(?) had a nice alternative to the Algol 68 formatted transput which
used operators extensively).


(*) Operators can also be used to construct structured data values in a
more seamless fashion than the language often allows. E.g., 3 I 4
instead of COMPL (3, 4). Haskell makes a useful and clear distinction
between constructors and other operators.


(*) You can even use them (but now greater care is required) to
construct a sublanguage. Following Allison, I have a Prolog-like library
which allows Prolog-like rules and facts to be defined without excessive
functional syntax.


Regards,
----------------------------------------------------------------------
Dave Lloyd mailto:Dave@occl-cam.demon.co.uk
Oxford and Cambridge Compilers Ltd http://www.occl-cam.demon.co.uk/
Cambridge, England http://www.chaos.org.uk/~dave/
[Plus for string concatenation? Yuck. Too much tiny basic. More to
the point, it's a poor choice since concatenation and addition are not
the same thing. What does a+b mean if a is a string and b an int?
There's lots of possible interpretations, none of which leaps out as
the obviously correct one. Fortran 77's // at least makes it clear
that it's not doing arithmetic. -John]






--

Return to the comp.compilers page.
Search the comp.compilers archives again.