Actually, both examples show that the problem isn't type inference, it's defaulting mechanism. Отправлено с iPhone Jul 17, 2012, в 12:46, oleg@okmij.org написал(а):
1. Haskell's type inference is NON-COMPOSITIONAL!
Yes, it is -- and there are many examples of it. Here is an example which has nothing to do with MonomorphismRestriction or numeric literals
{-# LANGUAGE ExtendedDefaultRules #-}
class C a where m :: a -> Int
instance C () where m _ = 1
instance C Bool where m _ = 2
main = do x <- return undefined let y = x print . fst $ (m x, show x) -- let dead = if False then not y else True return ()
The program prints 1. If you uncomment the (really) dead code, it will print 2. Why? The dead code doesn't even mention x, and it appears after the printing! What is the role of show x, which doesn't do anything?
Exercises: what is the significance of the monadic bind to x? Why can't we replace it with "let x = undefined"?
[Significant hint, don't look at it]
Such a behavior always occurs when we have HM polymorphism restriction and some sort of non-parametricity -- coupled with default rules or overlapping instances or some other ways of resolving overloading. All these features are essential (type-classes are significant, defaulting is part of the standard and is being used more and more).
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe