Extending arithmetic

[Joe Armstrong]

On Sat, 8 Feb 2003, Robert Virding wrote:

> Steven H. Rogers, PhD. wrote:
> > Excellent idea.  I like array oriented languages like APL/J/K for their 
> > overloading for arrays of arbitrary depth (actually lists of lists for 
> > K).  Not to seem greedy, but if Erlang were to be extened to apply 
> > arithmetic operators to tuples, what about lists?  Even better would be 
> > to handle any conformal data structures composed of lists and tuples.
> > 
> > Steve
> 
> Yes, Basic!! This would be real progress.
> 
> Seriously though this would mean that "ABCD" + 32 -> "abcd". If we are 
> going to do this we might as well go all the way and be consistent (I am 
>   big beliver in consistency*) and always coerce arguments into 
> something which can be operated on. The results might be confusing.
> 
> Sorry for being a little sarcastic here but I think it is a very bad idea.

  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.

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

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

  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.

</aside>

> 
> On a serious note though when Jonas Barklund and I were discussing BIFs, 
>   replacing imports with synonyms and determining which function gets 
> called (Proposal 16) we came up with an idea that would solve this 
> problem very elegantly (even Richard O'K would approve). +-*/ etc would 
> be synonyms for number:'+'/2 etc (they are this today for erlang:'+'/2) 
> and thye could instead be made synonyms for say matrix_arith:'+'/2 etc. 
> This would allow using the operators, leave the originals alone and be 
> clean and explicit about what they call.
> 

  Yes - this is the *opposite* of overloading - under-loading :-)

  If we allowed infix ops then you could have who families of +'s

  Id *much* prefer one + for integers and another for floats.

         1.0 f+ X.


	{1,2,3} m+ {2,3,4} 

etc.



> Robert
> 
> *At my age I value consistency, I haven't enough time to look up in a 
> manual every time I use something to see what arguments it can handle today.
>