Re: Definable operators

Craig Burley <burley@gnu.ai.mit.edu> writes:
> sethml@ugcs.caltech.edu (Seth LaForge) writes:
>
> int + string should mean nothing. I meant to mention this earlier: I
> think operator overloading is a fine thing (as well as overloading in
> general), but when combined with implicit conversions it becomes a
> nightmare. In a language with no implicit conversions, string +
> string is not too bad, since it's clear what it means.
>
> It's not clear to everyone what it means. Why wouldn't
>
> "1" + "2"
>
> evaluate to
>
> "3"
>
> for example?


What appears to be missing in the discussion so far is that Haskell
does not encourage the use of `+' in isolation: it comes as part of
a class definition.


class (Eq a, Text a) => Num a where
(+), (-), (*) :: a -> a -> a
negate :: a -> a
abs, signum :: a -> a
fromInteger :: Integer -> a


That is, for any data type (refered to as `a' above) that has an
equality operation, and is printable (subclasses of `Eq' and `Text')
we should define the seven operations in the class.


The precedence and associativity of the infix operators in class Num
is defined once and for all in the standard library, so we have no way
to vary that. If the user defines infix operators, either as part of a
class or as stand alone operators, then the user has a free hand with
regard to the precedence and associativity. (Though, again, this is a
one-time choice).


Let us now suppose that -- despite all the signals to the contrary --
you decide to use `+' as concatenation for strings. Here's what you do:


instance Num [Char] where
x + y = x ++ y
(-) = error "Not needed\n"
(*) = error "Not needed\n"
negate = error "Not needed\n"
abs = error "Not needed\n"
signum = error "Not needed\n"
fromInteger = error "Not needed\n"


Now we can write:


"1" + "2" and get "12"


If you want "1" + "2" to be "3" then a more sophisticated function
will be needed on the righthand side of the defining equation for (+).


> [...]
> The concept of + always meaning the mathematical sense of addition is
> useful -- not just in the sense that "addition is useful", but that "+
> means _only_ addition" is useful in designing programming languages.
> In point of fact, "+ means _only_ addition" is _substantially_ more
> useful as a language feature than "+ means whatever the programmer
> wants it to mean". The latter is useful in a tool, though too many
> tools define poorly-thought-out languages IMO, but if you're designing
> a tool syntax with an "anything-goes" attitude, you're not designing a
> good language. (Ref. TECO. ;-)


As I mentioned above, there is a signal that you should not be using
`+' as list concatenation, and that is that only one of the seven
operators in the class is being defined. Clearly this does not preclude
the possiblity that -- if you've forgotten your lithium, say -- you
could go ahead and make `+' be concatenation; but knowledge of the
numeric class structure is not something a naive user is likely to
want to delve into.


On the other hand, as you might imagine, the Obfuscated Haskell
competition is truly an art form.


> The mistake made by designers of overloading constructs is that they
> observe that + means one thing for int, another for float, yet another
> for double, and conclude that it therefore could mean anything and
> nobody would be too confused, because they somehow cope with + meaning
> so many different things already.
>
> Their initial observation is at least as wrong as their conclusion.
> In C, + (as a binary operator) means addition, and only addition. The
> interpretation of the data being added changes, so adding 32-bit
> quantities can mean "treat them as two's-complement integers" or
> "treat them as IEEE 754 single-precision floats", or whatever, but the
> crucial observation is that + means "add".
>
> I'm not saying it's totally out of the question that + be made to mean
> something other than add in certain situations.
>
> What I am saying is that, the more + can mean, the _less_ the language
> in question has to offer for the meaning of +.
>
> On the other hand, the more + can mean, the _more_ the _tool_ that
> processes the language in question has to offer for the meaning of +.
>


I think that we are (almost) in agreement on this point. Haskell permits
you to use `+' to mean anything, but makes this unpleasant (see above).
On the other hand the flexibility provided, makes it possible to overload
the entire class to deal with Matrices, Quarternions, Rings, and RealReals
(you get Int, Integer (bigints), Rational, Float, Double, Complex Float,
and Complex Double for free). I know, because I've done it.


I feel that this tension is inevitable: you want flexibility to overload
`+' in sensible ways, but you want to restrict the use of `+' only to
sensible cases. The trouble is that `sensible' is a meta-linguistic
concept, and it seems unlikely that we could code a compiler to check
that overloading is only used in acceptable places. I guess that we
disagree, in that I think that Haskell is a reasonable compromise.


---
David Lester, Computer Science, Manchester University, Manchester M13 9PL, UK.
--

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