Extending arithmetic

[Steven H. Rogers, PhD.]

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
> another  basic/javascript/TCL/.. with processes  - convenience  of use
> 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.

Regards,
Steve
-- 
  _    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