Implict parameters and monomorphism
Thu, 03 May 2001 06:29:35 -0400
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
> or rejecting the program altogether. Type signatures should specialise
> a type -- which means that efficiency may increase, or that the program
> 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)
PS. There are better examples, but this was all I could think of right now.