Re: Definable operators

Dave Lloyd <>
27 Mar 1997 13:36:41 -0500

          From comp.compilers

Related articles
[2 earlier articles]
Re: Definable operators (1997-03-18)
Re: Definable operators (1997-03-18)
Re: Definable operators (1997-03-21)
Re: Definable operators (Henry Spencer) (1997-03-22)
Re: Definable operators (1997-03-23)
Re: Definable operators (Tony Finch) (1997-03-23)
Re: Definable operators (Dave Lloyd) (1997-03-27)
Re: Definable operators (Henry Spencer) (1997-03-31)
Re: Definable operators (1997-03-31)
Re: Definable operators (1997-04-02)
Re: Definable operators (Dave Lloyd) (1997-04-02)
Re: Definable operators (Craig Burley) (1997-04-03)
Re: Definable operators (Francois-Rene Rideau) (1997-04-03)
[30 later articles]
| List of all articles for this month |

From: Dave Lloyd <>
Newsgroups: comp.compilers,comp.lang.misc
Date: 27 Mar 1997 13:36:41 -0500
Organization: Compilers Central
References: 97-03-037 97-03-076 97-03-112 97-03-115 97-03-141
Keywords: design

Henry Spencer <> 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

(*) 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.

Dave Lloyd
Oxford and Cambridge Compilers Ltd
Cambridge, England
[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]


Post a followup to this message

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