"Ch. A. Herrmann" wrote:
>
> the problem is that we loose much of the strength the Haskell type
> system provides and a lot of programming errors will remain
> undetected.
Moreover, it is completely incompatible with polymorphic typing and type
inference, because you overload notation. Consider for example a
definition like
f x y = x y
How do you want to type this if actually application syntax can mean
many different things? Using your rules, f could be typed
f :: (a -> b) -> a -> b
f :: (a -> b) -> (c -> a) -> (c -> b)
f :: (a -> b, c -> d) -> (a,c) -> (b,d)
f :: (a -> b -> c) -> (a,b) -> c
f :: (a -> b) -> [a] -> [b]
...
all of which are incompatible. Also note that operators like (+) usually
have no special status in functional languages, they are ordinary
functions. So giving them special typing rules is a bad idea. Similarly,
types like [] should have no special meaning besides being predefined.
It's better to say what you mean, overloading is your enemy! (Well, not
counting Haskell style "overloading" through type classes, which I
wouldn't call overloading in the first place.) BTW, this sort of
notational overloading used in maths has always been a good source of
confusion for students, IMHO.
All the best,
- Andreas
--
Andreas Rossberg, [EMAIL PROTECTED]
:: be declarative. be functional. just be. ::
