Extending arithmetic

[Peter-Henry Mander]

 From what I've been hearing on this discussion, I don't think tuples 
are the proper vehicle for multidimentional math, they're just too abstract.

Why not introduce new *numeric* types instead of contriving tuples to 
act like numbers? Then there will be less scope for surprises and 
exceptions occuring. The overloaded operators will be *little* more 
specific too, as I don't see how to determine what TupleA + TupleB does 
by simply looking at the statement; what happens when either one or both 
represent neither scalors, vectors nor matricies? Do I have to catch a 
potential exception? My brain begins to hurt! It's beginning to have the 
same problems as you can get with C++, yuk!

Please reconsider.

Pete.


Steven H. Rogers, PhD. wrote:
> 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