Extending arithmetic

[Joe Armstrong]

On Tue, 11 Feb 2003, Peter-Henry Mander wrote:

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

  Ok, ... reconsidering ....

  Ok  if we add  a feature  X to  the language  we should  also remove
something.

  If we just add things the  system will get more and more complicated
- so every time we add something we should take something away.

  Wirth  said  that the  difficult  thing  about  language design  was
deciding what  to leave out  - it's *easy*  to think of things  to add
(this group  comes up with  several ideas per  month) - but  much more
difficult to decide what to leave out.

  If we want the language to remain simple we have to remove things as
well as add things.

  If we're going  to add anything this should be in  the area where it
is *impossible* (or very difficult)  to do things with the language as
it is today.

  That  means  I'd like  to  see  additions  for things  like  process
migration and safe agent programming etc.

  /Joe



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