Henning Thielemann wrote:
Mathematical notation has the problem that it doesn't distinguish between things that are different but in turn discriminates things which are essentially the same.
I used to think that too. And while that is sometimes true, it is actually quite rare! When common mathematical usage makes 2 things the same, it is usually because either they really are the same, or context is always sufficient to tell them apart. When it keeps things separate, usually it is because there is something subtle going on.
If your design goal is to keep as close as possible to common notational habits you have already lost! As I already pointed out in an earlier discussion I see it the other way round: Computer languages are the touchstones for mathematical notation because you can't tell a computer about an imprecise expression: "Don't be stupid, you _know_ what I mean!"
No, you misplace the problem: you seem to want all your mathematical expressions to be 100% meaningful in a context-free environment. Computers really do love that. Humans mathematicians are much more sophisticated than that, they can deal with a lot of context-sensitivity without much difficulty. The goal here should be to allow computers to deal with context sensitivity with as much ease. In fact, type classes in Haskell is a *great* way to do just that!
More specific: You give two different things the same name. You write A*B and you mean a matrix multiplication. Matrix multiplication means finding a representation of the composition of the operators represented by A and B. But you also write A*x and you mean the matrix-vector multiplication. This corresponds to the application of the operator represented by A to the vector x. You see: Two different things, but the same sign (*). Why? You like this ambiguity because of its conciseness. You are used to it. What else?
This is called operator overloading. It is completely harmless because you can tell the two * apart from their type signatures. It is a complete and total waste of time to use two different symbols to mean the same thing. <sarcasm>Next thing you know, you'll want a different 'application' symbol for every arity of function, because they are ``different''. </sarcasm> Seriously, the unification of the concept of application, achieved through currying and first-class functions, is wonderful. Operator application is no different!
But you have to introduce an orientation of vectors, thus you discriminate two things (row and column vectors) which are essentially the same! What is the overall benefit?
Someone else already answered this much better than I could.
It seems to me like the effort of most Haskell XML libraries in trying to have as few as possible combinator functions (namely one: o) which forces you to not discriminate the types for the functions to be combined (the three essential types are unified to a -> [a]) and even more it forces you to put conversions from the natural type (like a->Bool, a->a) in every atomic function!
Here we agree. Too much polymorphism can hurt too - you end up essentially pushing everything into dynamic typing, which is rather anti-Haskell. The problem that the authors faced was that Haskell doesn't yet have enough facilities to eliminate *all* boilerplate code, and I guess they chose dynamic typing over boilerplate.
I don't see the problem. There are three very different kinds of multiplication, they should also have their own signs: Scalar product, matrix-vector multiplication, matrix-matrix multiplication.
You see 3 concepts, I see one: multiplication. Abstract Algebra is the branch of mathematics where you want to abstract out the *unimportant* details. Much progress was made in the late 1800's when this was discovered by mathematicians ;-).
I have worked with Maple and I have finally dropped it because of its design. I dropped MatLab, too, because the distinction of row and column vectors, because it makes no sense to distinguish between e.g. convolving row vectors or column vectors. Many routines have to be aware of this difference for which it is irrelevant and many routines work only with one of these kinds and you are often busy with transposing them.
The core design of much of Maple and Matlab were done in the early 80s. That core design hasn't changed. That it turns out to be sub-optimal is to be expected!!! Note that the one giant try at a statically typed mathematics system (Axiom w/ programming language Aldor) never caught on, because they were way way too hard to use by mere mortals. And Aldor has a type system that makes Haskell's look simple and pedestrian by comparison. Aldor has full dependent types, recursive modules, first-class types, just to name a few. There is a 50-long (recursive) dependency chain in Aldor's algebra library!
If translating all of existing idioms is your goal, then this is certainly the only design. But adapting the sloppy (not really convenient) mathematical notation is not a good design guideline.
I should know better than to get into a discussion like this with someone who believes they singlehandedly know better than tens of thousands of mathematicians... Rather reminds me of my days as a PhD student... Jacques