Steven H. Rogers, PhD.
Tue Feb 11 03:57:46 CET 2003
Joe Armstrong wrote:
> I entirely agree - this violates the "principle of least surprise"
> my intuitive understanding of "+" is that it is a thing that adds
> *numbers* together - nothing else.
I have different intuitions. To me, scalars, vectors, and matrices are
all numbers, differing in dimensionality. But then, as APL was my
second language after FORTRAN, perhaps I've been brain damaged ;-).
> <aside> Robert and I agonized for months over whether "+" should
> overload floats and integers - we made (of course) the wrong decision
> allowing arbitrary mixing of floats and integers with the appropriate
> coercions where necessary. This sucks since coercing a very large
> integer (bignum) into a float can fail etc. - too late now.
Perhaps Erlang needs bigger floats.
> Personally I *hate* languages where "everything is really a string"
> and + etc. are *heavily* overloaded - these a programmer's nightmare
> (because simple programs are indeed easier than in a language like
> Erlang, but complex programs are *much* more difficult and really
> subtle errors can occur. They are also a compiler writers nightmare -
> if you can't derive the type at compile time you have to check at run
> time - - there is a fine balance here, between dynamic typing (a la
> Erlang) and strong typing (a la Haskell) - knowing that things are
> strings, tuples, integers, and that the arguments to '+' are numbers
> etc. allows you to make a whole bundle of optimizations - heavier
> coercions of + etc. would upset this fine balance and result in yet
> for non-trivial applications would *not* increase, indeed we would
> introduce large classes of subtly bugs - and performance would go down
This argument is a staw horse. Overloading arithmetic to properly
handle arrays is very different from treating everything as strings. I
don't like the latter either.
> IMHO the *only* way to do overloading is of you have a strongly
> typed language, where the type system can figure out at compile time
> which particular usage the overloaded operator has - checking this at
> run-time is not a good idea - If the compiler can't figure out what
> the operator means at compile time how will the programmer know? -
> this does not aid program readability.
Strong typing would certainly make it easier on the compiler. Extending
arithmetic to tuples shouldn't place that big a burden on the compiler.
The tuples would need to have all numeric elements, and it might be a
good idea to have a flag identifing a tuple as strictly numeric.
_ Steven H. Rogers, PhD.
<_` email: steve@REDACTED
|_> Weblog http://shrogers.com/portal/Members/steve/blog
| \ "A language that doesn't affect the way you think about
programming is not worth knowing." - Alan Perlis
More information about the erlang-questions