Definable operators 
Author Message
 Definable operators

Quote:


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

Quote:
> [...]
> 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.

- Show quoted text -

Quote:
> 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.
--




Sun, 03 Oct 1999 03:00:00 GMT  
 Definable operators


Quote:
> It's not clear to everyone what it means.  Why wouldn't
>   "1" + "2"
> evaluate to
>   "3"
> for example?

> 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".

How about "+" meaning the mathematical "+" defining a (semi?) group?
For "+" as string concatenation, that almost makes sense, although I
will admit that coming up with an inverse under "+" for string
concatenation is rather difficult.

Actually, under those constraints, the quasi-numerical implementation
of strings makes a lot of sense...

I don't know if I'm agreeing or disagreeing, here. But I think that
"+" denotes a behavior that "makes sense" only in relationship to
other behaviors applicable to a given type. I geuss I come in with a
little weaker constraint than Craig, but in basic agreement.

        happy hackin'

        david rush

--




Thu, 07 Oct 1999 03:00:00 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. operator overloading and user definable operators.

2. Definable operators

3. Definable operators (was: Problems with Hardware, Languages, and Compilers)

4. User definable operators

5. User Definable Runtime Report Formater/Wizard-CPD2x

6. User definable field name?

7. user definable browse box

8. User Definable Reports

9. Adding a User Definable Logo to an app

10. Overloading logical operators and bitwise operators

11. OPERATOR (was: Why no ** operator in Modula2?)

12. Aliases for operators, creating new operators

 

 
Powered by phpBB® Forum Software