Difference between revisions of "Type signature"
(short explanation) |
(add more examples) |
||
(One intermediate revision by one other user not shown) | |||
Line 3: | Line 3: | ||
inc :: Num a => a -> a |
inc :: Num a => a -> a |
||
</haskell> |
</haskell> |
||
− | that tells, what is the type of a variable. |
+ | that tells, what is the [[type]] of a [[variable]]. |
− | In the example <hask>inc</hask> is the variable |
+ | In the example <hask>inc</hask> is the variable, <hask>Num a =></hask> is the context and <hask>a -> a</hask> is its type, namely a [[function]] type with the kind <hask>* -> *</hask>. |
+ | |||
− | namely a function type. |
||
+ | A very simple example looks like this |
||
+ | |||
+ | <haskell> |
||
+ | title :: String |
||
+ | </haskell> |
||
+ | |||
+ | which restricts the variable <hask>title</hask> to the the type <hask>String</hask>. Binding a value of any other type will lead to a type missmatch. For example binding <hask>42</hask> to <hask>title</hask> by writing <hask>title = 42</hask> will lead to an error looking like this in ghc 7.10 |
||
+ | |||
+ | <haskell> |
||
+ | No instance for (Num String) arising from the literal ‘42’ |
||
+ | In the expression: 42 |
||
+ | In an equation for ‘title’: title = 42 |
||
+ | </haskell> |
||
+ | |||
+ | To better understand the error message, take a look at the types, in ghci you can use the `:t ` command which will show you the type for a given expression |
||
+ | |||
+ | <haskell> |
||
+ | >:t title |
||
+ | title :: String |
||
+ | >:t 42 |
||
+ | 42 :: Num a => a |
||
+ | </haskell> |
||
+ | |||
+ | If instead declaring the types like in this example |
||
+ | |||
+ | <haskell> |
||
+ | title :: String |
||
+ | value :: Integer |
||
+ | |||
+ | value = 42 |
||
+ | title = value |
||
+ | </haskell> |
||
+ | the error message becomes clearer |
||
+ | <haskell> |
||
+ | Couldn`t match type ‘Integer’ with ‘[Char]’ |
||
+ | Expected type: String |
||
+ | Actual type: Integer |
||
+ | In the expression: value |
||
+ | In an equation for ‘title’: title = value |
||
+ | </haskell> |
||
+ | but there is still room for confusion because the first lines mentiones the type `[Char]` which does not appear in the type signatures in the example. This comes form the fact that <hask>String</hask> is just a renaming for <hask>[Char]</hask>. The compiler only typechecks the expressions after resolving the renaming. |
||
It is considered [[Type signatures as good style|good style]] to add a type signature to every [[top-level variable]]. |
It is considered [[Type signatures as good style|good style]] to add a type signature to every [[top-level variable]]. |
Latest revision as of 10:49, 8 November 2016
A type signature is a line like
inc :: Num a => a -> a
that tells, what is the type of a variable.
In the example inc
is the variable, Num a =>
is the context and a -> a
is its type, namely a function type with the kind * -> *
.
A very simple example looks like this
title :: String
which restricts the variable title
to the the type String
. Binding a value of any other type will lead to a type missmatch. For example binding 42
to title
by writing title = 42
will lead to an error looking like this in ghc 7.10
No instance for (Num String) arising from the literal ‘42’
In the expression: 42
In an equation for ‘title’: title = 42
To better understand the error message, take a look at the types, in ghci you can use the `:t ` command which will show you the type for a given expression
>:t title
title :: String
>:t 42
42 :: Num a => a
If instead declaring the types like in this example
title :: String
value :: Integer
value = 42
title = value
the error message becomes clearer
Couldn`t match type ‘Integer’ with ‘[Char]’
Expected type: String
Actual type: Integer
In the expression: value
In an equation for ‘title’: title = value
but there is still room for confusion because the first lines mentiones the type `[Char]` which does not appear in the type signatures in the example. This comes form the fact that String
is just a renaming for [Char]
. The compiler only typechecks the expressions after resolving the renaming.
It is considered good style to add a type signature to every top-level variable.