Tue Feb 11 12:36:25 CET 2003
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
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.
> 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.
> > Regards,
> > Steve
More information about the erlang-questions