Haha, I like this example. However, if your are using ExtendedDefaultRules then you are likely to know you are leaving the clean sound world of type inference. The example of my student works on plain GHC... The other responses to my message confined to point me to "best practices" to avoid the design bugs of Haskell's type inference. However, if I want "best practices", I can go to JavaScript. To stirr action, mails on haskell-cafe seem useless. I am already biased towards Haskell. But as an unbiased decision maker, I would not consider a language with "undead code" for my projects... Cheers, Andreas On 17.07.12 10:46 AM, oleg@okmij.org wrote:
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 #-}
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).
-- Andreas Abel <>< Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY andreas.abel@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/