Implict parameters and monomorphism

[Lennart Augustsson]

Simon Peyton-Jones wrote:

> |       a) That adding a type signature can change the dynamic semantics
> |           of the program.  This would be the first and only
> | occurrence of
> |           such behaviour.
> |
> | At present, adding a type signature changes both the static
> | semantics and the cost of running a program
>
> That's true: but adopting (B) means that adding a type signature
> may cause the program to print a different answer!  That seems
> qualitiatively different to giving the same answer only slower or
> faster;
> or rejecting the program altogether.  Type signatures should specialise
> a type -- which means that efficiency may increase, or that the program
> may
> no longer be typable, but surely it shouldn't change the answer!

Try this program:
-- Try commenting out this type signature.
fun :: (Num a) => a -> Int
fun 0 = if fun 1 == 1 then fun 2 else fun (3::Int)

g :: (a -> b) -> b
g f = f undefined

ii = g fun

class C a where
    m :: a -> String

instance C Int where
    m _ = "You have a type signature"

instance C Integer where
    m _ = "You forgot the type signature"

main = putStrLn (m ii)


    -- Lennart

PS.  There are better examples, but this was all I could think of right now.