Tue Feb 11 09:04:58 CET 2003
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!
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
>> 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.
More information about the erlang-questions