Actually, both examples show that the problem isn't type inference, it's
defaulting mechanism.
Отправлено с iPhone
Jul 17, 2012, в 12:46, o...@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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
