3 'div' 4 ERROR: Improperly terminated character constant The problem here is the use of the wrong sort of quotes. To turn a function, which is written before its arguments, into an operator, which is written between its arguments, you need to enclose it in backquotes. The backquote is round on the same key as the tilde on US keyboards (commonly the top left hand corner of the main block, just above TAB).

data BTree a = EmptyBTree | Node a (BTree a) (BTree a)
					  card :: BTree a -> Integer
					  card EmptyBTree = 0
					  card (Node x) lt rt = (height lt) + (height rt) + 1

ERROR: Equations give different arities for "card" Incorrect bracketing causes the problem here. It looks as though card is a one argument function (arity 1) from the first equation in the definition, and as though it's a three argument function from the second. The misplaced closing bracket is the culprit, and a correct version of the code says card (Node x lt rt) = (height lt) + (height rt) + 1

>maxFour :: Int -> Int -> Int -> Int -> Int
					  >maxFour
					  >| a >= b && a >= c && a >= d = a
					  >| b >= c && b >= d= b
					  >| c >= d  = c
					  >| otherwise  = d

ERROR "test.lhs" (line 3): Undefined variable "a" The definition of maxFour has its variables missing. The second line should read maxFour a b c d.

>exOr :: bool -> bool -> bool
					  >exOr b1 b2
					  >= (b1 && not b2) || (b2 && not b1)

ERROR "test.lhs" (line 3): Declared type too general *** Expression: exOr *** Declared type : a -> a -> a *** Inferred type : Bool -> Bool -> Bool The problem here is with the bools in the type. The Boolean type is written Bool and so the first line should read exOr :: Bool -> Bool -> Bool What does the error message mean? The bool is taken to be a type variable, and so the declaration asserts that the function has a polymorphic type (which of course it doesn't). >ex = (2==3)) ERROR "test.lhs" (line 1): Syntax error in input (unexpected `)') The presence of an extra closing parenthesis is signalled as an unexpected piece of input. Other `unexpected' symbols can be more enigmatic....

>fun x
				      >fun 2 = 34

ERROR "test.lhs" (line 2): Syntax error in input (unexpected `;') The problem here is that the first line is incomplete. Formatting means that the symbol fun in the second line signals by layout that the construct in the first line is finished. The explicit Haskell symbol for the end of a construct is `;'; hence the message. Another peculiarity of the system is given by

>fun x
				      > fun 2 = 34

which is not erroneous. It means the same as >fun x y 2 = 34 because the second use of fun is treated as a variable!

>module Junk where
					  >
					  >a = (True, [1,2,3,4]

ERROR "Junk.lhs" (line 4): Syntax error in expression (unexpected `}') This problem happens because there is a closing bracket missing at the end of the line. The } symbol is used to group definitions together, and also to define records with named fields. An error like this occurs when grouping is incorrect or, if you are using records, in record syntax.

>f :: Int -> [Int] -> [Int]
					  >f a x = (a:x

ERROR "test.lhs" (line 4): Syntax error in expression (unexpected `}', possibly due to bad layout) The problem here is not so much bad layout as a missing closing parenthesis!

>fun x = 17
					  >type Fred = Int

>fun x = 17
					  >type Fred = Int

ERROR "test.lhs" (line 2): Syntax error in input (unexpected keyword "type") This problem happens because of the indentation of the second line is incorrect; it should be indented to the same level as the first line. >Fun x = 17 ERROR "test.lhs" (line 1): Undefined constructor function "Fun" The syntax of the language dictates that names for functions and other defined values begin with a small letter. Names beginning with capitals are reserved for constructors (of data types) and for types and type classes. Here the use of a capital letter in Fun is seen to be the use of a constructor which is not defined.

>fun x = 17
					  >where
					  >type Fun = Int

ERROR "test.lhs" (line 2): Syntax error in input (unexpected keyword "type") The problem here is that type definitions are not allowed in where clauses. >fun x x = 17 ERROR "test.lhs" (line 1): Repeated variable "x" in pattern A variable can only occur once on the left-hand side of a definition. You can get the same effect with

>fun x y
					  >| x==y = 17

double - 4 ERROR: Illegal Haskell 98 class constraint in inferred type *** Expression : double - 4 *** Type: Num (Int -> Int) => Int -> Int where double is of type Int -> Int. The problem is that -4 needs to be parenthesised, as in double (-4). >fun x = x + abs -2 ERROR "test.lhs" (line 1): a -> a is not an instance of class "Num" In the definition here, the function abs is supposed to be applied to -2; what happens instead is that 2 is subtracted from the function abs. Negative literals need to be enclosed in parentheses, as in >fun x = x + abs (-2) In Hugs98 a different error message is generated by the same script. ERROR "text.lhs" (line 1): Illegal Haskell 98 class constraint in inferred type *** Expression : fun *** Type: (Num (a -> a), Num a) => (a -> a) -> a -> a

Are two integers in ascending order?
					  >ascendingOrder :: Int -> Int -> Bool
					  >ascendingOrder x y = (x<=y)

ERROR "test.lhs" (line 2): Program line next to comment The message here is slightly misleading: the program line is immediately below a comment, and that is not acceptable syntax.

>test :: (Bool,Bool) -> Bool
				>test (b1,2b) = b1

"test.lhs" (line 2): Illegal pattern syntax The illegality is to have mistyped b2 as 2b.

>predecessor n :: Num a => a -> a
					  >predecessor n
					  >| n>0 = n-1
					  >| n==0 = 0

Syntax error in input (unexpected `|') The problem here is the argument n which appears in the type declaration. This should read:

>predecessor :: Num a => a -> a

which states that the type of the predecessor function is a -> a for any type ain the Num class.

>Any Haskell code in literate form ERROR "test.hs" (line 3): Syntax error in input (unexpected symbol ">") This is due to having a literate script in a .hs file. >Any Haskell code in non-literate form ERROR "test.lhs" (line 8): Empty script - perhaps you forgot the `>'s? As the message implies, this results from having a non-literate script in a .lhs file. >fred :: Int -> Int ERROR "test.lhs" (line 1): Missing binding for variable "fred" in type signature The problem here is that the function fred has its type declared, but it is not actually defined in the module.

>elem :: Int -> [Int] -> Bool
					  >elem x xs = [y | y<-xs, y==x] /= []

ERROR "test.lhs" (line 2): Definition of variable "elem" clashes with import This definition re-defines something imported from the standard Prelude. It can be hidden on import by including the import statement >import Prelude hiding (elem) at the start of the module. ERROR "File2.lhs": Module "Main" already loaded This error happens if you load two anonymous modules into (Win)Hugs. The solution is to name the modules concerned and to set up the appropriate import/export structures.

>f [] = 23
					  >g y = 2
					  >f (x:xs) = 6

ERROR "test.hs" (line 2): "f" multiply defined The first line of the file defines the function f, and the second the function g; the third, erroneously, adds another clause of the definition of f. This is an error. This could happen by inserting by mistake a section into an existing definition.

>foo :: Int -> [Char]
					  >foo x = ['1'] ++ foo(x div 10)

*** term : foo *** type : ((a -> a -> a) -> b -> Int) -> [Char] *** does not match : Int -> [Char] The intention here was to divide the numerical input x by 10; div should have appeared in back-quotes: `div`. The program is a correct program, in which x is applied to the function div, hence the error appears as a mis-typing. This is a good example of why it is sensible to include type declarations in definitions; if the declaration was missing, the foo function would be accepted, only to be rejected (presumably) at the first point at which it is used.

empty :: [a] -> Bool
					  empty as = (as == [])

ERROR "test.hs" (line 2): Cannot justify constraints in explicitly typed binding *** Expression: empty *** Type: [a] -> Bool *** Given context : () *** Constraints : Eq a The problem here is that in order to compare lists for equality one can only do this when the elements themselves carry an equality function. This is necessary even when comparing with the empty list. It is fixed thus

empty :: Eq a => [a] -> Bool
					  empty as = (as == [])

>compress :: [a] -> [a]
					  >compress [] = []
					  >compress [a] = [a]
					  >compress (x:y:xs)
					  >| (x == y) = compress (x:xs)
					  >| otherwise = x : compress (y:xs)

ERROR "lab2.hs" (line 2): Cannot justify constraints in explicitly typed binding *** Expression: compress *** Type : [a] -> [a] *** Given context : () *** Constraints : Eq a The problem here is that the equality function, ==, is used over the elements of the list. This needs to be acknowedged in the type of the function, making it include the constraint that the type a belongs to the equality class, Eq, >compress :: Eq a => [a] -> [a]

>ascendingOrder :: Int -> Int -> Bool
					  >ascendingOrder a b
					  >| a<=b  = a b
					  >| otherwise = b a

ERROR "test.lhs" (line 3): Type error in application *** expression : a b *** term : b *** type : a -> b *** does not match : a *** because: unification would give infinite type The function here should return a Boolean indicating whether its two arguments, a and b are in ascending order. Instead the function attempts to return the two ``in ascending order''. Looking at the definition, in the third line a is applied to b, so a must be a function which can be applied to b. On the other hand, in line 4 the reverse happens, so b is applied to a. Trying to resolve these two constraints gives rise to the ``infinite type'' in the error message. The problem here is compounded here by using a, b and so on as variable names, since the system uses them also as type variable names. Rewriting the function to use x, y etc. as variables helps to make the error message more comprehensible:

>ascendingOrder :: Int -> Int -> Bool
					  >ascendingOrder x y
					  >| x<=y  = x y
					  >| otherwise = y x

ERROR "test.lhs" (line 3): Type error in application *** expression : x y *** term : y *** type : a -> b *** does not match : a *** because: unification would give infinite type >ex = [('2',2),('1','1'),('a',3)] ERROR "test.lhs" (line 1): Char is not an instance of class "Num" The problem here is that a character '1' is being used in a place where a number should appear. This error message refers to the class system in Haskell; if you don't know about this, then you can still get some useful information from the error message, namely - the error occurs on line 1; - a character is being used when something else is expected; - the name of the class mentioned, Num, suggests that a number was expected. In general, an error containing Blah is not an instance of class "Plonk" indicates that something of type Blah appears (on the line in question) in a place where something related to Plonk was expected. >fun x = x ++ 2 ERROR "test.lhs" (line 1): Illegal class constraint Num (a b) in inferred type. The operator ++ needs to be applied to lists; here it is applied to (a list and) a number. The right-hand side is fixed thus: x ++ [2].

>convert :: String -> String
					  >convert s = "Co" ++ (300 + tail s)

ERROR "test.lhs" (line 2): Instance of Num [Char] required for definition of convert A problem here is the use of + to join a number to a string; the compiler therefore tries to find a definition of + over string, i.e. [Char] and fails. >fun x = [2]:[2] ERROR "test.lhs" (line 1): [a] is not an instance of class "Num" Here a list is being added to the front of a list of numbers; a list is used where a number is expected.

>myCheck :: Int -> Bool
					  >myCheck n = ord n == 6

ERROR "test.lhs" (line 2): Type error in function binding *** term : myCheck *** type : Char -> Bool *** does not match : Int -> Bool The problem here is that an incorrect type is specified for a correct definition. The type assertion needs to be replaced by >myCheck :: Char -> Bool >type Fred = (Fred,Int) ERROR "test.lhs" (line 11): Recursive type synonym "Fred" Only types defined using data can be recursive. The intended effect is given by >data Fred = Fred Fred Int

>proximity :: a -> a -> Double
				>proximity x y = 0
				>q :: b -> Int
				>q p = 0
				>where
				>g :: b -> Double
				>g = proximity p

Type checking ERROR "test.hs" (line 8): Inferred type is not general enough *** Expression : g *** Expected type : a -> Double *** Inferred type : _2 -> Double The problem here is the type declaration g :: b -> Double in the local definition: without this, the code type checks. What is the difficulty? It is in the interpretation of a statement like g :: b -> Double, which means that g can be passed an argument of any type. The problem is that this isn't the role of g here: this function can only receive an element of whatever q is passed. The type of g can only be expressed correctly in the presence of scoped type variables: we need the b in q :: b -> Int to be usable (in scope) throughout the definition of q rather than just in the type declaration itself, as is the case in the current language definition.

3/0 Program error: {primDivDouble 3.0 0.0} Here a number is being divided by zero: the `primitive' function, primDivDouble, causes an error when being trying to divide by zero. Exactly the same error message is given by evaluating (1+2)/0 showing that the error message shows the values for which the division is called, rather than the expressions which have those values. >fun n = fun (n+1) Segmentation Fault (core dumped) Evaluating fun 1 initiates a recursion that carries on indefinitely: the Hugs system (on Unix) crashes with this classic error message! >fun n = fun (n+1) ERROR: Control stack overflow If you try to evaluate fun 1: the recursion calls fun 2, which calls fun 3 and so on.... This never gives an answer, but rather goes on forever; after some time it overruns the `control stack' which causes the message that you saw. [1 .. 10]!!23 Program error: PreludeList.!!: index too large This error message is helpful. It indicates the function causing the problem, namely the !! function from the PreludeList module; qualified naming is being used here. The error message itself is contained in the error call in the definition of the !! function in PreludeList: ... [] !! _ = error "PreludeList.!!: index too large" concat [1,2,3] ERROR: Illegal class constraint Num (a b) in inferred type. This is a type error(!): concat expects a list of lists, but is instead passed a list of numbers. The problem here is that -- in Hugs 1.4, at least -- concat is overloaded to work over all monads (which generalise lists) and this gives rise to this kind of error. This should not be a problem in implementations of Haskell 98. Assuming that concat :: [[a]] -> [a] the error message generated for concat [1,2,3] will be ERROR: [a] is not an instance of class "Num"

>test :: [Bool] -> [Bool]
				>test [] = [False]
				test [True]

Program error: {test [True]} This error message here is less helpful. It indicates that an error is caused by applying test to the list [True], but fails to say that this is due to a missing pattern. An alternative definition >test xs = case xs of > [] -> [False]provokes the message Program error: {test_v850 [False]}showing that an error occurs in a pattern match somewhere inside the function test. At worst, a missing pattern can give rise to the message Program error: {_FAIL}A similar problem is produced bytotalArea :: [(Float,Float)] -> [(Float)]totalArea [(a,b)] = map times2 [(a,b)] times2 :: (Float,Float) -> Floattimes2 (a,b) = a * bHere the difficulty is that totalArea is only defined over lists of pairs which contain exactly one element. Replacing the argument [(a,b)] with a variable does the trick. reverse [] ERROR: Cannot find "show" function for: *** expression : reverse [] *** of type : [a] The top-level system for Hugs can only print values which belong to a type which can be shown, that is a type which belongs to the Show class. Now, the list type is an instance of Show, so what is wrong with reverse [] (which evaluates to [])? The problem is that the type of [] is polymorphic: [] :: [a] for all a. Not knowing a Hugs refuses to print a value of type [a]. Note that this behaviour applies to all polymorphic values. Given the definition data Tree a = Empty | Node (Tree a) a (Tree a) we have, on evaluating Empty the error message ERROR: Cannot find "show" function for: *** expression : Empty *** of type : Tree a Functions can be shown, but not very helpfully; printing any function results in <<function>> (1,2,3,4,5,6) ERROR: Cannot find "show" function for: *** Expression : (1,2,3,4,5,6) *** Of type : (Integer,Integer,Integer,Integer,Integer,Integer) The Hugs system derives show functions, which convert values into Strings, for various types automatically, and uses these functions in printing out values. Unfortunately, it will only derive show functions for tuples with five or fewer components. ERROR: Garbage collection fails to reclaim sufficient space This occurs during or after evaluation of a large expression; it means that the heap for Hugs is too small. Heap size can be changed; consult the documentation; use :set to find the current size.