Re: Definable operators (Seth LaForge)
31 Mar 1997 22:21:15 -0500

          From comp.compilers

Related articles
[4 earlier articles]
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)
Re: Definable operators (Jerry Leichter) (1997-04-06)
Re: Definable operators (1997-04-11)
[28 later articles]
| List of all articles for this month |

From: (Seth LaForge)
Newsgroups: comp.compilers,comp.lang.misc
Date: 31 Mar 1997 22:21:15 -0500
Organization: California Institute of Technology, Pasadena
References: 97-03-037 97-03-076 97-03-112 97-03-115 97-03-141 97-03-162
Keywords: design

On 27 Mar 1997 13:36:41 -0500, our esteemed moderator wrote:
>[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.

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.

On the other hand, I do think it is a good idea to use some other
symbol for string concatenation for clarity. I think Haskell has a
good solution: ++ is used to append lists, and by exension strings
(since strings are just lists of characters).

In general, I think that well thought out use of operators can be a
good thing, as long as their meaning is either obvious from the
operator name, or the operator is used often enough that the reader
doesn't forget what it does. Good use of operators is aided by a
language that allows lots of flexibility in choice of operator name
but restricts overloading such that the meaning of operator
application is clear. Haskell is by far the best language I've seen
on both counts - in particular, by avoiding implicit casts and by its
use of type classes, Haskell manages to keep operator overloading


Post a followup to this message

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