In this section, we describe the syntax and informal semantics of Haskell expressions, including their translations into the Haskell kernel, where appropriate. Except in the case of let expressions, these translations preserve both the static and dynamic semantics. Some of the names and symbols used in the syntax are not reserved. These are indicated by the `special' productions in the lexical syntax. Examples include ! (used only in data declarations) and as (used in import declarations).
Free variables and constructors used in these translations refer to entities defined by the Prelude. To avoid clutter, we use True instead of Prelude.True or map instead of Prelude.map. (Prelude.True is a qualified name as described in Section 5.1.2.)
In the syntax that follows, there are some families of nonterminals indexed by precedence levels (written as a superscript). Similarly, the nonterminals op, varop, and conop may have a double index: a letter l, r, or n for left, right or nonassociativity and a precedence level. A precedencelevel variable i ranges from 0 to 9; an associativity variable a varies over {l, r, n}. Thus, for example
aexp  >  ( exp_{i+1} qop_{(a,i)} ) 
exp  >  exp_{0} :: [context =>] type  (expression type signature) 
  exp_{0}  
exp_{i}  >  exp_{i+1} [qop_{(n,i)} exp_{i+1}]  
  lexp_{i}  
  rexp_{i}  
lexp_{i}  >  (lexp_{i}  exp_{i+1}) qop_{(l,i)} exp_{i+1}  
lexp_{6}  >   exp_{7}  
rexp_{i}  >  exp_{i+1} qop_{(r,i)} (rexp_{i}  exp_{i+1})  
exp_{10}  >  \ apat_{1} ... apat_{n} > exp  (lambda abstraction, n>=1) 
  let decllist in exp  (let expression)  
  if exp then exp else exp  (conditional)  
  case exp of { alts [;] }  (case expression)  
  do { stmts [;] }  (do expression)  
  fexp  
fexp  >  [fexp] aexp  (function application) 
aexp  >  qvar  (variable) 
  gcon  (general constructor)  
  literal  
  ( exp )  (parenthesized expression)  
  ( exp_{1} , ... , exp_{k} )  (tuple, k>=2)  
  [ exp_{1} , ... , exp_{k} ]  (list, k>=1)  
  [ exp_{1} [, exp_{2}] .. [exp_{3}] ]  (arithmetic sequence)  
  [ exp  qual_{1} , ... , qual_{n} ]  (list comprehension, n>=1)  
  ( exp_{i+1} qop_{(a,i)} )  (left section)  
  ( qop_{(a,i)} exp_{i+1} )  (right section)  
  qcon { fbind_{1} , ... , fbind_{n} }  (labeled construction, n>=0)  
  aexp_{{qcon}} { fbind_{1} , ... , fbind_{n} }  (labeled update, n >= 1) 
As an aid to understanding this grammar, Table 1 shows the relative precedence of expressions, patterns and definitions, plus an extended associativity.  indicates that the item is nonassociative.
Item  Associativity 
simple terms, parenthesized terms   
irrefutable patterns (~)   
aspatterns (@)  right 
function application  left 
do, if, let, lambda(\), case (leftwards)  right 
case (rightwards)  right 
infix operators, prec. 9  as defined 
...  ... 
infix operators, prec. 0  as defined 
function types (>)  right 
contexts (=>)   
type constraints (::)   
do, if, let, lambda(\) (rightwards)  right 
sequences (..)   
generators (<)   
grouping (,)  nary 
guards ()   
case alternatives (>)   
definitions (=)   
separation (;)  nary 
The grammar is ambiguous regarding the extent of lambda abstractions, let expressions, and conditionals. The ambiguity is resolved by the metarule that each of these constructs extends as far to the right as possible. As a consequence, each of these constructs has two precedences, one to its left, which is the precedence used in the grammar; and one to its right, which is obtained via the metarule. See the sample parses below.
Expressions involving infix operators are disambiguated by the operator's fixity (see Section 5.6). Consecutive unparenthesized operators with the same precedence must both be either left or right associative to avoid a syntax error. Given an unparenthesized expression "x qop_{(a,i)} y qop_{(b,j)} z", parentheses must be added around either "x qop_{(a,i)} y" or "y qop_{(b,j)} z" when i=j unless a=b=l or a=b=r.
Negation is the only prefix operator in Haskell ; it has the same precedence as the infix  operator defined in the Prelude (see Figure 2).
The separation of function arrows from case alternatives solves the ambiguity that otherwise arises when an unparenthesized function type is used in an expression, such as the guard in a case expression.
Sample parses are shown below.
This  Parses as 
f x + g y  (f x) + (g y) 
 f x + y  ( (f x)) + y 
let { ... } in x + y  let { ... } in (x + y) 
z + let { ... } in x + y  z + (let { ... } in (x + y)) 
f x y :: Int  (f x y) :: Int 
\ x > a+b :: Int  \ x > ((a+b) :: Int) 
For the sake of clarity, the rest of this section shows the syntax of expressions without their precedences.
Translations of Haskell expressions use error and undefined to explicitly indicate where execution time errors may occur. The actual program behavior when an error occurs is up to the implementation. The messages passed to the error function in these translations are only suggestions; implementations may choose to display more or less information when an error occurs.
aexp  >  qvar  (variable) 
  gcon  (general constructor)  
  literal 
gcon  >  ()  
  []  
  (,{,})  
  qcon  
qvar  >  qvarid  ( qvarsym )  (qualified variable) 
qcon  >  qconid  ( qconsym )  (qualified constructor) 
Alphanumeric operators are formed by enclosing an identifier between grave accents (backquotes). Any variable or constructor may be used as an operator in this way. If fun is an identifier (either variable or constructor), then an expression of the form fun x y is equivalent to x `fun`y. If no fixity declaration is given for `fun` then it defaults to highest precedence and left associativity (see Section 5.6).
Similarly, any symbolic operator may be used as a (curried) variable or constructor by enclosing it in parentheses. If op is an infix operator, then an expression or pattern of the form x op y is equivalent to (op) x y.
Qualified names may only be used to reference an imported variable or
constructor (see Section 5.1.2)
but not in the definition of a new variable or constructor. Thus
let F.x = 1 in F.x  invalid
incorrectly uses a qualifier in the definition of x, regardless of
the module containing this definition. Qualification does not affect
the nature of an operator: F.+ is an infix operator just as + is.
Special syntax is used to name some constructors for some of the builtin types, as found in the production for gcon and literal. These are described in Section 6.1.
An integer literal represents the application of the function fromInteger to the appropriate value of type Integer. Similarly, a floating point literal stands for an application of fromRational to a value of type Rational (that is, Ratio Integer).
Translation:The integer literal i is equivalent to fromInteger i, where fromInteger is a method in class Num (see Section 6.3.1).The floating point literal f is equivalent to fromRational (n Ratio.% d), where fromRational is a method in class Fractional and Ratio.% constructs a rational from two integers, as defined in the Ratio library. The integers n and d are chosen so that n/d = f. 
fexp  >  [fexp] aexp  (function application) 
exp  >  \ apat_{1} ... apat_{n} > exp 
Lambda abstractions are written \ p_{1} ... p_{n} > e, where the p_{i} are patterns. An expression such as \x:xs>x is syntactically incorrect, and must be rewritten as \(x:xs)>x.
The set of patterns must be linearno variable may appear more than once in the set.
Translation:The lambda abstraction \ p_{1} ... p_{n} > e is equivalent to\ x_{1} ... x_{n} > case (x_{1}, ..., x_{n}) of (p_{1}, ..., p_{n}) > e where the x_{i} are new identifiers. Given this translation combined with the semantics of case expressions and pattern matching described in Section 3.17.3, if the pattern fails to match, then the result is __. 
exp  >  exp_{1} qop exp_{2}  
   exp  (prefix negation) 
The special form e denotes prefix negation, the only prefix operator in Haskell , and is syntax for negate (e). The binary  operator does not necessarily refer to the definition of  in the Prelude; it may be rebound by the module system. However, unary  will always refer to the negate function defined in the Prelude. There is no link between the local meaning of the  operator and unary negation.
Prefix negation has the same precedence as the infix operator  defined in the Prelude (see Table 2). Because e1e2 parses as an infix application of the binary operator , one must write e1(e2) for the alternative parsing. Similarly, () is syntax for (\ x y > xy), as with any infix operator, and does not denote (\ x > x)one must use negate for that.
Translation:e_{1} op e_{2} is equivalent to (op) e_{1} e_{2}. e is equivalent to negate (e). 
aexp  >  ( exp qop ) 
  ( qop exp ) 
The normal rules of syntactic precedence apply to sections; for example, (*a+b) is syntactically invalid, but (+a*b) and (*(a+b)) are valid. Syntactic associativity, however, is not taken into account in sections; thus, (a+b+) must be written ((a+b)+).
Because  is treated specially in the grammar, ( exp) is not a section, but an application of prefix negation, as described in the preceding section. However, there is a subtract function defined in the Prelude such that (subtract exp) is equivalent to the disallowed section. The expression (+ ( exp)) can serve the same purpose.
Translation:For binary operator op and expression e, if x is a variable that does not occur free in e, the section (op e) is equivalent to \ x > x op e, and the section (e op) is equivalent to (op) e. 
exp  >  if exp_{1} then exp_{2} else exp_{3} 
Translation:if e_{1} then e_{2} else e_{3} is equivalent to:case e_{1} of { True > e_{2} ; False > e_{3} } where True and False are the two nullary constructors from the type Bool, as defined in the Prelude. 
aexp  >  [ exp_{1} , ... , exp_{k} ]  (k>=1) 
Translation:[e_{1}, ..., e_{k}] is equivalent toe_{1} : (e_{2} : ( ... (e_{k} : []))) where : and [] are constructors for lists, as defined in the Prelude (see Section 6.1.3). The types of e_{1} through e_{k} must all be the same (call it t), and the type of the overall expression is [t] (see Section 4.1.1). 
aexp  >  ( exp_{1} , ... , exp_{k} )  (k>=2) 
Translation:(e_{1}, ..., e_{k}) for k>=2 is an instance of a ktuple as defined in the Prelude, and requires no translation. If t_{1} through t_{k} are the types of e_{1} through e_{k}, respectively, then the type of the resulting tuple is (t_{1}, ..., t_{k}) (see Section 4.1.1). 
aexp  >  () 
  ( exp ) 
Translation:(e) is equivalent to e. 
aexp  >  [ exp_{1} [, exp_{2}] .. [exp_{3}] ] 
The forms [e_{1}.. e_{3}] and [e_{1}..] are similar to those above, but with an implied increment of one.
Arithmetic sequences may be defined over any type in class Enum, including Char, Int, and Integer (see Figure 5 and Section 4.3.3). For example, ['a'..'z'] denotes the list of lowercase letters in alphabetical order.
Translation:Arithmetic sequences satisfy these identities:

aexp  >  [ exp  qual_{1} , ... , qual_{n} ]  (list comprehension, n>=1) 
qual  >  pat < exp  
  let decllist  
  exp 
A list comprehension has the form [ e  q_{1}, ..., q_{n} ], n>=1, where the q_{i} qualifiers are either
While list comprehensions are commonly used to generate lists, the definition of list comprehensions uses monadic operations that can be used with other types besides lists. This syntax provides a slightly more concise way of expressing some forms of do expressions (see Section 3.14). For simplicity, we will describe this construct only as it applies to lists.
Such a list comprehension returns the list of elements
produced by evaluating e in the successive environments
created by the nested, depthfirst evaluation of the generators in the
qualifier list. Binding of variables occurs according to the normal
pattern matching rules (see Section 3.17), and if a
match fails then that element of the list is simply skipped over. Thus:
[ x  xs < [ [(1,2),(3,4)], [(5,4),(3,2)] ],
(3,x) < xs ]
yields the list [4,2]. If a qualifier is a guard, it must evaluate
to True for the previous pattern match to succeed.
As usual, bindings in list comprehensions can shadow those in outer
scopes; for example:
[ x  x < x, x < x ]  =  [ z  y < x, z < y] 
Translation:List comprehensions satisfy these identities, which may be used as a translation into the kernel:

exp  >  let decllist in exp 
Translation:The dynamic semantics of the expression let { d_{1} ; ... ; d_{n} } in e_{0} are captured by this translation: After removing all type signatures, each declaration d_{i} is translated into an equation of the form p_{i} = e_{i}, where p_{i} and e_{i} are patterns and expressions respectively, using the translation in Section 4.4.2. Once done, these identities hold, which may be used as a translation into the kernel:

exp  >  case exp of { alts [;] }  
alts  >  alt_{1} ; ... ; alt_{n}  (n>=1) 
alt  >  pat > exp [where decllist]  
  pat gdpat [where decllist]  
gdpat  >  gd > exp [ gdpat ]  
gd  >   exp_{0} 
case e of { p_{1} match_{1} ; ... ; p_{n} match_{n} }
where each match_{i} is of the general form
 g_{i1}  > e_{i1}  
...  
 g_{imi}  > e_{imi}  
where decllist_{i} 
Each alternative p_{i} match_{i} consists of a pattern p_{i} and its matches, match_{i}, which consists of pairs of guards g_{ij} and bodies e_{ij} (expressions), as well as optional bindings (decllist_{i}) that scope over all of the guards and expressions of the alternative. An alternative of the form
pat > exp where decllist
is treated as shorthand for:
pat  True  > expr  
where decllist 
A case expression must have at least one alternative and each alternative must have at least one body. Each body must have the same type, and the type of the whole expression is that type.
A case expression is evaluated by pattern matching the expression e against the individual alternatives. The matches are tried sequentially, from top to bottom. The first successful match causes evaluation of the corresponding alternative body, in the environment of the case expression extended by the bindings created during the matching of that alternative and by the decllist_{i} associated with that alternative. If no match succeeds, the result is __. Pattern matching is described in Section 3.17, with the formal semantics of case expressions in Section 3.17.3.
exp  >  do { stmts [;]}  (do expression) 
stmts  >  exp [; stmts]  
  pat < exp ; stmts  
  let decllist ; stmts 
Translation:Do expressions satisfy these identities, which may be used as a translation into the kernel:

A failurefree pattern is one that can only be refuted by __. Failurefree patterns are defined as follows:
This translation requires a monad in class MonadZero if any pattern bound by < is not failurefree. Otherwise, only class methods from Monad are generated. Type errors resulting from patterns that are not failurefree can be corrected by using ~ to force the pattern to be failurefree.
As indicated by the translation of do, variables bound by let have fully polymorphic types while those defined by < are lambda bound and are thus monomorphic.
Different datatypes cannot share common field labels in the same scope. A field label can be used at most once in a constructor. Within a datatype, however, a field name can be used in more than one constructor provided the field has the same typing in all constructors.
aexp  >  qvar 
Translation:A field label f introduces a selector function defined as:

aexp  >  qcon { fbind_{1} , ... , fbind_{n} }  (labeled construction, n>=0) 
fbind  >  var  qvar = exp 
Translation:In the binding f = v, the field f labels v. Any binding f that omits the = v is expanded to f = f.
The auxiliary function pick_{C}_{i} bs d is defined as follows: If the ith component of a constructor C has the field name f, and if f=v appears in the binding list bs, then pick_{C}_{i} bs d is v. Otherwise, pick_{C}_{i} bs d is the default value d. 
aexp  >  aexp_{<qcon>} { fbind_{1} , ... , fbind_{n} }  (labeled update, n>=1) 
Translation:Using the prior definition of pick,

Expression  Translation 
C1 {f1 = 3}  C1' 3 undefined 
C2 {f1 = 1, f4 = 'A', f3 = 'B'}  C2' 1 'B' 'A' 
x {f1 = 1}  case x of C1' _ f2 > C1' 1 f2 
C2' _ f3 f4 > C2' 1 f3 f4 
The field f1 is common to both constructors in T. The constructors C1' and C2' are `hidden constructors', see the translation in Section 4.2.1. A compiletime error will result if no single constructor defines the set of field names used in an update, such as x {f2 = 1, f3 = 'x'}.
exp  >  exp :: [context =>] type 
Patterns appear in lambda abstractions, function definitions, pattern bindings, list comprehensions, do expressions, and case expressions. However, the first five of these ultimately translate into case expressions, so defining the semantics of pattern matching for case expressions is sufficient.
Patterns have this syntax:
pat  >  var + integer  (successor pattern) 
pat   pat_{0}  
pat_{i}  >  pat_{i+1} [qconop_{(n,i)} pat_{i+1}]  
  lpat_{i}  
  rpat_{i}  
lpat_{i}  >  (lpat_{i}  pat_{i+1}) qconop_{(l,i)} pat_{i+1}  
lpat_{6}  >   (integer  float)  (negative literal) 
rpat_{i}  >  pat_{i+1} qconop_{(r,i)} (rpat_{i}  pat_{i+1})  
pat_{10}>  apat  
  gcon apat_{1} ... apat_{k}  (arity gcon = k, k>=1)  
apat  >  var [@ apat]  (as pattern) 
  gcon  (arity gcon = 0)  
  qcon { fpat_{1} , ... , fpat_{k} }  (labeled pattern, k>=0)  
  literal  
  _  (wildcard)  
  ( pat )  (parenthesized pattern)  
  ( pat_{1} , ... , pat_{k} )  (tuple pattern, k>=2)  
  [ pat_{1} , ... , pat_{k} ]  (list pattern, k>=1)  
  ~ apat  (irrefutable pattern)  
fpat  >  var = pat  
  var 
All patterns must be linear no variable may appear more than once.
Patterns of the form var@pat are called aspatterns,
and allow one to use var
as a name for the value being matched by pat. For example,
case e of { xs@(x:rest) > if x==0 then rest else xs }
is equivalent to:
let { xs = e } in
case xs of { (x:rest) > if x==0 then rest else xs }
Patterns of the form _ are
wildcards and are useful when some part of a pattern
is not referenced on the righthandside. It is as if an
identifier not used elsewhere were put in its place. For example,
case e of { [x,_,_] > if x==0 then True else False }
is equivalent to:
case e of { [x,y,z] > if x==0 then True else False }
In the pattern matching rules given below we distinguish two kinds of patterns: an irrefutable pattern is: a variable, a wildcard, N apat where N is a constructor defined by newtype and apat is irrefutable (see Section 4.2.3), var@apat where apat is irrefutable, or of the form ~apat (whether or not apat is irrefutable). All other patterns are refutable.
Patterns are matched against values. Attempting to match a pattern can have one of three results: it may fail; it may succeed, returning a binding for each variable in the pattern; or it may diverge (i.e. return __). Pattern matching proceeds from left to right, and outside to inside, according to these rules:
Matching any value against the wildcard pattern _ always succeeds and no binding is done.
Operationally, this means that no matching is done on an irrefutable pattern until one of the variables in the pattern is used. At that point the entire pattern is matched against the value, and if the match fails or diverges, so does the overall computation.
Aside from the obvious static type constraints (for example, it is a static error to match a character against a boolean), these static class constraints hold: an integer literal pattern can only be matched against a value in the class Num and a floating literal pattern can only be matched against a value in the class Fractional. A n+k pattern can only be matched against a value in the class Integral.
Many people feel that n+k patterns should not be used. These patterns may be removed or changed in future versions of Haskell . Compilers should support a flag that disables the use of these patterns.
Here are some examples:
Top level patterns in case expressions and the set of top level patterns in function or pattern bindings may have zero or more associated guards. A guard is a boolean expression that is evaluated only after all of the arguments have been successfully matched, and it must be true for the overall pattern match to succeed. The environment of the guard is the same as the righthandside of the caseexpression alternative, function definition, or pattern binding to which it is attached.
The guard semantics have an obvious influence on the
strictness characteristics of a function or case expression. In
particular, an otherwise irrefutable pattern
may be evaluated because of a guard. For example, in
f ~(x,y,z) [a]  a==y = 1
both a and y will be evaluated by a standard definition of ==.
The semantics of all pattern matching constructs other than case expressions are defined by giving identities that relate those constructs to case expressions. The semantics of case expressions themselves are in turn given as a series of identities, in Figures 34. Any implementation should behave so that these identities hold; it is not expected that it will use them directly, since that would generate rather inefficient code.
Figure 4Semantics of Case Expressions, Part 2 
In Figures 34: e, e' and e_{i} are expressions; g and g_{i} are booleanvalued expressions; p and p_{i} are patterns; v, x, and x_{i} are variables; K and K' are algebraic datatype (data) constructors (including tuple constructors); N is a newtype constructor;
and k is a character, string, or numeric literal.
Rule (b) matches a general sourcelanguage case expression, regardless of whether it actually includes guardsif no guards are written, then True is substituted for the guards g_{i,j} in the match_{i} forms. Subsequent identities manipulate the resulting case expression into simpler and simpler forms.
Rule (h) in Figure 4 involves the overloaded operator ==; it is this rule that defines the meaning of pattern matching against overloaded constants.
These identities all preserve the static semantics. Rules (d), (e), and (j) use a lambda rather than a let; this indicates that variables bound by case are monomorphically typed (Section 4.1.3).