See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/2743675

Report on the Programming Language

Article · February 1970

Source: CiteSeer

CITATIONS READS
109 4,096

13 authors, including:

Simon Loftus Peyton Jones Philip Wadler

Microsoft The University of Edinburgh
383 PUBLICATIONS   18,849 CITATIONS    229 PUBLICATIONS   15,551 CITATIONS   

SEE PROFILE SEE PROFILE

Kevin Hammond John Hughes

University of St Andrews Chalmers University of Technology
215 PUBLICATIONS   3,806 CITATIONS    152 PUBLICATIONS   7,820 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

EmBounded View project

EU-Project ADVANCE View project

All content following this page was uploaded by John Peterson on 22 February 2013.

The user has requested enhancement of the downloaded file.

 Report on the
Programming Language
Haskell
A Non-strict, Purely Functional Language
Version 1.4
April 7, 1997
John Peterson [editor]
1

Kevin Hammond [editor]

2

Lennart Augustsson 3

Brian Boutel 4

Warren Burton 5

Joseph Fasel 6

Andrew D. Gordon 7

John Hughes 3

Paul Hudak 1

Thomas Johnsson 3

Mark Jones 9

Erik Meijer 10

Simon Peyton Jones 8

Alastair Reid 1

Philip Wadler 11

Authors' aliations: (1) Yale University, (2) University of St. Andrews,

(3) Chalmers University of Technology, (4) Victoria University of Welling-
ton, (5) Simon Fraser University, (6) Los Alamos National Laboratory,
(7) University of Cambridge, (8) University of Glasgow, (9) University of
Nottingham, (10) Utrecht University, (11) Bell Labs
CONTENTS i

Contents
1 Introduction 1
1.1 Program Structure : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 1
1.2 The Haskell Kernel : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 2
1.3 Values and Types : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 2
1.4 Namespaces : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 2
1.5 Layout : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 3
2 Lexical Structure 6
2.1 Notational Conventions : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 6
2.2 Lexical Program Structure : : : : : : : : : : : : : : : : : : : : : : : : : : : : 6
2.3 Identiers and Operators : : : : : : : : : : : : : : : : : : : : : : : : : : : : 8
2.4 Numeric Literals : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 9
2.5 Character and String Literals : : : : : : : : : : : : : : : : : : : : : : : : : : 10
3 Expressions 11
3.1 Errors : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 13
3.2 Variables, Constructors, and Operators : : : : : : : : : : : : : : : : : : : : : 14
3.3 Curried Applications and Lambda Abstractions : : : : : : : : : : : : : : : : 15
3.4 Operator Applications : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 15
3.5 Sections : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 16
3.6 Conditionals : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 16
3.7 Lists : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 16
3.8 Tuples : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 17
3.9 Unit Expressions and Parenthesized Expressions : : : : : : : : : : : : : : : 17
3.10 Arithmetic Sequences : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 17
3.11 List Comprehensions : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 18
3.12 Let Expressions : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 19
3.13 Case Expressions : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 20
3.14 Do Expressions : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 21
3.15 Datatypes with Field Labels : : : : : : : : : : : : : : : : : : : : : : : : : : : 22
3.16 Expression Type-Signatures : : : : : : : : : : : : : : : : : : : : : : : : : : : 24
3.17 Pattern Matching : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 24
4 Declarations and Bindings 31
4.1 Overview of Types and Classes : : : : : : : : : : : : : : : : : : : : : : : : : 31
4.2 User-Dened Datatypes : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 36
4.3 Type Classes and Overloading : : : : : : : : : : : : : : : : : : : : : : : : : : 41
4.4 Nested Declarations : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 45
4.5 Static Semantics of Function and Pattern Bindings : : : : : : : : : : : : : : 48
4.6 Kind Inference : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 53
ii CONTENTS

5 Modules 55
5.1 Module Structure : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 55
5.2 Closure : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 60
5.3 Standard Prelude : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 60
5.4 Separate Compilation : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 62
5.5 Abstract Datatypes : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 62
5.6 Fixity Declarations : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 62
6 Predened Types and Classes 64
6.1 Standard Haskell Types : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 64
6.2 Standard Haskell Classes : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 66
6.3 Numbers : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 72
7 Basic Input/Output 78
7.1 Standard I/O Functions : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 78
7.2 Sequencing I/O Operations : : : : : : : : : : : : : : : : : : : : : : : : : : : 80
7.3 Exception Handling in the I/O Monad : : : : : : : : : : : : : : : : : : : : : 80
A Standard Prelude 82
A.1 Prelude PreludeList : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 96
A.2 Prelude PreludeText : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 103
A.3 Prelude PreludeIO : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 109
B Syntax 111
B.1 Notational Conventions : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 111
B.2 Lexical Syntax : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 111
B.3 Layout : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 113
B.4 Context-Free Syntax : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 115
C Literate comments 120
D Specication of Derived Instances 122
D.1 An example : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 125
E Compiler Pragmas 127
E.1 Inlining : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 127
E.2 Specialization : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 127
E.3 Optimization : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 128
References 129
Index 131
PREFACE iii

Preface
(January 1, 1997)

\Some half dozen persons have written technically on combinatory logic, and
most of these, including ourselves, have published something erroneous. Since
some of our fellow sinners are among the most careful and competent logicians
on the contemporary scene, we regard this as evidence that the subject is re-
fractory. Thus fullness of exposition is necessary for accuracy; and excessive
condensation would be false economy here, even more than it is ordinarily."
Haskell B. Curry and Robert Feys
in the Preface to Combinatory Logic [2], May 31, 1956

In September of 1987 a meeting was held at the conference on Functional Programming

Languages and Computer Architecture (FPCA '87) in Portland, Oregon, to discuss an un-
fortunate situation in the functional programming community: there had come into being
more than a dozen non-strict, purely functional programming languages, all similar in ex-
pressive power and semantic underpinnings. There was a strong consensus at this meeting
that more widespread use of this class of functional languages was being hampered by the
lack of a common language. It was decided that a committee should be formed to design
such a language, providing faster communication of new ideas, a stable foundation for real
applications development, and a vehicle through which others would be encouraged to use
functional languages. This document describes the result of that committee's eorts: a
purely functional programming language called Haskell, named after the logician Haskell
B. Curry whose work provides the logical basis for much of ours.

Goals
The committee's primary goal was to design a language that satised these constraints:
1. It should be suitable for teaching, research, and applications, including building large
systems.
2. It should be completely described via the publication of a formal syntax and semantics.
3. It should be freely available. Anyone should be permitted to implement the language
and distribute it to whomever they please.
4. It should be based on ideas that enjoy a wide consensus.
5. It should reduce unnecessary diversity in functional programming languages.
The committee hopes that Haskell can serve as a basis for future research in language
design. We hope that extensions or variants of the language may appear, incorporating
experimental features.
iv PREFACE

This Report
This report is the ocial specication of the Haskell language and should be suitable for
writing programs and building implementations. It is not a tutorial on programming in
Haskell such as the `Gentle Introduction' [5], so some familiarity with functional languages
is assumed.
Version 1.4 of the report was unveiled in 1997. It makes some minor corrections to
version 1.3 and adds a few new features as described below. Version 1.4 is described in two
separate documents: the Haskell Language Report (this document) and the Haskell Library
Report[8].

Highlights of Haskell 1.3

Libraries
For the rst time, we distinguish between Prelude and Library entities. Entities dened
by the Prelude, a module named Prelude, are in scope unless explicitly hidden. Entities
dened in library modules are in scope only if that module is explicitly imported. The
library modules specied by Haskell are described in the Haskell Library Report.

Monadic I/O
Monadic I/O has proven to be more general and in many respects simpler than the stream-
based I/O system used in Haskell 1.2. Here are the highlights of the I/O denition.
 We dene a monadic programming model for Haskell. Expressions of type IO a denote
computations that may engage in I/O before returning an answer of type a.
 The IO monad admits computations that fail and recovers from such failures.
 We dene a new type of handles, to mediate I/O operations on les and other I/O
devices. Handles are part of the I/O library.
 We dene input polling and input of characters. In contrast, Haskell 1.2 represented
character input as a single String (that is, a lazy list of characters), containing all
the characters available for input throughout the program execution.
 Monadic I/O provides an extensible framework capable of incorporating advanced
operating system and GUI interfaces in libraries.
 Monadic programming has been made more readable through the introduction of a
special do syntax.
PREFACE v

Constructor Classes
Constructor classes are a natural generalization of the original Haskell type system, sup-
porting polymorphism over type constructors. For example, the monadic operators used by
the I/O system have been generalized using constructor classes to arbitrary monads just as
(+) has been generalized to arbitrary numeric types using type classes.

New Datatype Features

A number of enhancements have been made to Haskell type declarations. These include:
 Strictness annotations allow structures to be represented in a more ecient manner.
 The components of a constructor may be labeled using eld names. Selection, con-
struction, and update operations that reference elds by name rather than position
are now available.
 The newtype declaration denes a type that renames an existing datatype without
changing the underlying object representation. Unlike type synonyms, types dened
by newtype are distinct from their denition.

Improvements in the Module System

A number of substantial changes to the module system have been made. Instead of renam-
ing, qualied names are used to resolve name con icts. All names are now redenable; there
is no longer a PreludeCore module containing names that cannot be reused. Interface les
are no longer specied by this report; all issues of separate compilation are now left up to
the implementation.

The n +k Pattern Controversy

For technical reasons, many people feel that n +k patterns are an incongruous language
design feature that should be eliminated from Haskell. On the other hand, they serve
as a vehicle for teaching introductory programming, in particular recursion over natural
numbers. Alternatives to n +k patterns have been explored, but are too premature to
include in Haskell 1.3. Thus the 1.3 committee decided to retain this feature at present
but to discourage the use of n +k patterns by Haskell users. This feature may be altered or
removed in future versions of Haskell and should be avoided. Implementors are encouraged
to provide a mechanism for users to selectively enable or disable n +k patterns.

Highlights of Haskell 1.4

Version 1.4 of the report makes the following changes in the language:
vi PREFACE

 The character set has been changed to Unicode.

 List comprehensions have been generalized to arbitrary monads.
 Import and export of class methods and constructors is no longer restricted to `all
or nothing' as previously. Any subset of class methods or data constructors may be
selected for import or export. Also, constructors and class methods can now be named
directly on import and export lists instead of as components of a type or class.
 Qualied names may now be used as eld names in patterns and updates.
 Ord is no longer a superclass of Enum. Some of the default methods for Enum have
changed.
 Context restrictions on newtype declarations have been relaxed.
 The Prelude is now more explicit about some instances for Read and Show.
 The xity of >>= has changed.
These changes are relatively minor { the version 1.3 report is nearly identical to this one.

Haskell Resources
We welcome your comments, suggestions, and criticisms on the language or its presentation
in the report. A common mailing list for technical discussion of Haskell uses the following
electronic mail addresses:
 [email protected] forwards mail to all subscribers of the Haskell list.
 [email protected] is used to add and remove subscribers from the mail-
ing list. To subscribe or unsubscribe send messages of the form:
subscribe haskell
unsubscribe haskell
You may wish to subscribe or remove a mailing address other than the reply-to address
contained in your mail message. These commands may include an explicit email
address:
subscribe haskell [email protected]
Please do not send subscription requests direct to the mailing list.
 Each implementation has an email address for discussions of specic Haskell systems.
Please send questions and comments regarding these directly to the associated groups
instead of the global Haskell community.
Web pages for Haskell, which includes an on-line version of this report, a tutorial,
extensions to Haskell, information about upgrading programs from prior Haskell versions,
and information about Haskell implementations can be found at the following sites:
PREFACE vii

 http://haskell.org

 http://www.dcs.gla.ac.uk/fp/software/ghc

 http://www.cs.chalmers.se/Haskell

 http://www.cs.nott.ac.uk/Research/fpg/haskell.html

Acknowledgements
We heartily thank these people for their useful contributions to this report: Richard Bird,
Stephen Blott, Tom Blenko, Duke Briscoe, Magnus Carlsson, Franklin Chen, Chris Clack,
Guy Cousineau, Tony Davie, Chris Fasel, Pat Fasel, Andy Gill, Cordy Hall, Thomas Hall-
gren, Bob Hiromoto, Nic Holt, Ian Holyer, Randy Hudson, Simon B. Jones, Stef Joosten,
Mike Joy, Stefan Kahrs, Kent Karlsson, Richard Kelsey, Siau-Cheng Khoo, Amir Kishon,
John Launchbury, Mark Lillibridge, Sandra Loosemore, Olaf Lubeck, Jim Mattson, Randy
Michelsen, Rick Mohr, Arthur Norman, Nick North, Paul Otto, Larne Pekowsky, Rinus Plas-
meijer, Ian Poole, John Robson, Colin Runciman, Patrick Sansom, Lauren Smith, Raman
Sundaresh, Satish Thatte, Tom Thomson, Pradeep Varma, Tony Warnock, Stuart Wray,
and Bonnie Yantis. We are especially grateful to past members of the Haskell committee|
Arvind, Jon Fairbairn, Maria M. Guzman, Dick Kieburtz, Rishiyur Nikhil, Mike Reeve,
David Wise, and Jonathan Young|for the major contributions they have made to previous
versions of this report, which we have been able to build upon, and for their support for
this latest revision of Haskell. We also thank those who have participated in the lively
discussions about Haskell on the FP and Haskell mailing lists.
Finally, aside from the important foundational work laid by Church, Rosser, Curry, and
others on the lambda calculus, we wish to acknowledge the in uence of many noteworthy
programming languages developed over the years. Although it is dicult to pinpoint the
origin of many ideas, we particularly wish to acknowledge the in uence of Lisp (and its
modern-day incarnations Common Lisp and Scheme); Landin's ISWIM; APL; Backus's FP
[1]; ML and Standard ML; Hope and Hope+ ; Clean; Id; Gofer; Sisal; and Turner's series
of languages culminating in Miranda.1 Without these forerunners Haskell would not have
been possible.

1
Miranda is a trademark of Research Software Ltd.
viii PREFACE
 1

1 Introduction
Haskell is a general purpose, purely functional programming language incorporating many
recent innovations in programming language design. Haskell provides higher-order func-
tions, non-strict semantics, static polymorphic typing, user-dened algebraic datatypes,
pattern-matching, list comprehensions, a module system, a monadic I/O system, and a rich
set of primitive datatypes, including lists, arrays, arbitrary and xed precision integers, and
oating-point numbers. Haskell is both the culmination and solidication of many years of
research on lazy functional languages.
This report denes the syntax for Haskell programs and an informal abstract semantics
for the meaning of such programs. We leave as implementation dependent the ways in
which Haskell programs are to be manipulated, interpreted, compiled, etc. This includes
such issues as the nature of programming environments and the error messages returned for
undened programs (i.e. programs that formally evaluate to ?).

1.1 Program Structure

In this section, we describe the abstract syntactic and semantic structure of Haskell, as well
as how it relates to the organization of the rest of the report.
1. At the topmost level a Haskell program is a set of modules, described in Section 5.
Modules provide a way to control namespaces and to re-use software in large programs.
2. The top level of a module consists of a collection of declarations, of which there are
several kinds, all described in Section 4. Declarations dene things such as ordinary
values, datatypes, type classes, and xity information.
3. At the next lower level are expressions, described in Section 3. An expression denotes
a value and has a static type; expressions are at the heart of Haskell programming \in
the small."
4. At the bottom level is Haskell's lexical structure, dened in Section 2. The lexical
structure captures the concrete representation of Haskell programs in text les.
This report proceeds bottom-up with respect to Haskell's syntactic structure.
The sections not mentioned above are Section 6, which describes the standard built-
in datatypes and classes in Haskell, and Section 7, which discusses the I/O facility in
Haskell (i.e. how Haskell programs communicate with the outside world). Also, there are
several appendices describing the Prelude, the concrete syntax, literate programming, the
specication of derived instances, and pragmas supported by most Haskell compilers.
Examples of Haskell program fragments in running text are given in typewriter font:
let x = 1
z = x+y
in z+1
2 1. INTRODUCTION

\Holes" in program fragments representing arbitrary pieces of Haskell code are written in
italics, as in if e1 then e2 else e3 . Generally the italicized names are mnemonic, such as
e for expressions, d for declarations, t for types, etc.

1.2 The Haskell Kernel

Haskell has adopted many of the convenient syntactic structures that have become popular
in functional programming. In all cases, their formal semantics can be given via translation
into a proper subset of Haskell called the Haskell kernel. It is essentially a slightly sugared
variant of the lambda calculus with a straightforward denotational semantics. The trans-
lation of each syntactic structure into the kernel is given as the syntax is introduced. This
modular design facilitates reasoning about Haskell programs and provides useful guidelines
for implementors of the language.

1.3 Values and Types

An expression evaluates to a value and has a static type. Values and types are not mixed in
Haskell. However, the type system allows user-dened datatypes of various sorts, and per-
mits not only parametric polymorphism (using a traditional Hindley-Milner type structure)
but also ad hoc polymorphism, or overloading (using type classes).
Errors in Haskell are semantically equivalent to ?. Technically, they are not distinguish-
able from nontermination, so the language includes no mechanism for detecting or acting
upon errors. Of course, implementations will probably try to provide useful information
about errors.

1.4 Namespaces
Haskell provides a lexical syntax for inx operators (either functions or constructors). To
emphasize that operators are bound to the same things as identiers, and to allow the two
to be used interchangeably, there is a simple way to convert between the two: any function
or constructor identier may be converted into an operator by enclosing it in backquotes,
and any operator may be converted into an identier by enclosing it in parentheses. For
example, x + y is equivalent to (+) x y, and f x y is the same as x f y. These lexical
matters are discussed further in Section 2.
There are six kinds of names in Haskell: those for variables and constructors denote
values; those for type variables, type constructors, and type classes refer to entities related
to the type system; and module names refer to modules. There are three constraints on
naming:
1. Names for variables and type variables are identiers beginning with lowercase letters;
the other four kinds of names are identiers beginning with uppercase letters.
2. Constructor operators are operators beginning with \:"; variable operators are oper-
ators not beginning with \:".
1.5 Layout 3

3. An identier must not be used as the name of a type constructor and a class in the
same scope.
These are the only constraints; for example, Int may simultaneously be the name of a
module, class, and constructor within a single scope.

1.5 Layout
In the syntax given in the rest of the report, layout lists are always preceded by the keyword
where, let, do, or of, and are enclosed within curly braces ({ }) with the individual
declarations separated by semicolons (;). Layout lists usually contain declarations, but do
and case introduce lists of other sorts. For example, the syntax of a let expression is:
let { decl1 ; decl2 ; ::: ; decln [;] } in exp
Haskell permits the omission of the braces and semicolons by using layout to convey the
same information. This allows both layout-sensitive and -insensitive styles of coding, which
can be freely mixed within one program. Because layout is not required, Haskell programs
can be straightforwardly produced by other programs.
The layout (or \o-side") rule takes eect whenever the open brace is omitted after the
keyword where, let, do, or of. When this happens, the indentation of the next lexeme
(whether or not on a new line) is remembered and the omitted open brace is inserted (the
whitespace preceding the lexeme may include comments). For each subsequent line, if it
contains only whitespace or is indented more, then the previous item is continued (nothing
is inserted); if it is indented the same amount, then a new item begins (a semicolon is
inserted); and if it is indented less, then the layout list ends (a close brace is inserted). A
close brace is also inserted whenever the syntactic category containing the layout list ends;
that is, if an illegal lexeme is encountered at a point where a close brace would be legal, a
close brace is inserted. The layout rule matches only those open braces that it has inserted;
an explicit open brace must be matched by an explicit close brace. Within these explicit
open braces, no layout processing is performed for constructs outside the braces, even if a
line is indented to the left of an earlier implicit open brace.
Given these rules, a single newline may actually terminate several layout lists. Also,
these rules permit:
f x = let a = 1; b = 2
g y = exp2
in exp1
making a, b and g all part of the same layout list.
To facilitate the use of layout at the top level of a module (an implementation may
allow several modules may reside in one le), the keyword module and the end-of-le token
are assumed to occur in column 0 (whereas normally the rst column is 1). Otherwise, all
top-level declarations would have to be indented.
4 1. INTRODUCTION

See also Section B.3.

As an example, Figure 1 shows a (somewhat contrived) module and Figure 2 shows the
result of applying the layout rule to it. Note in particular: (a) the line beginning }};pop,
where the termination of the previous line invokes three applications of the layout rule,
corresponding to the depth (3) of the nested where clauses, (b) the close braces in the
where clause nested within the tuple and case expression, inserted because the end of the
tuple was detected, and (c) the close brace at the very end, inserted because of the column
0 indentation of the end-of-le token.
When comparing indentations for standard Haskell programs, a xed-width font with
this tab convention is assumed: tab stops are 8 characters apart (with the rst tab stop in
column 9), and a tab character causes the insertion of enough spaces (always  1) to align
the current position with the next tab stop. Particular implementations may alter this rule
to accommodate variable-width fonts and alternate tab conventions, but standard Haskell
programs must observe this rule.
1.5 Layout 5

module AStack( Stack, push, pop, top, size ) where

data Stack a = Empty
| MkStack a (Stack a)
push :: a -> Stack a -> Stack a
push x s = MkStack x s

size :: Stack a -> Integer

size s = length (stkToLst s) where
stkToLst Empty = []
stkToLst (MkStack x s) = x:xs where xs = stkToLst s
pop :: Stack a -> (a, Stack a)
pop (MkStack x s)
= (x, case s of r -> i r where i x = x) -- (pop Empty) is an error
top :: Stack a -> a
top (MkStack x s) = x -- (top Empty) is an error

Figure 1: A sample program

module AStack( Stack, push, pop, top, size ) where

{data Stack a = Empty
| MkStack a (Stack a)
;push :: a -> Stack a -> Stack a
;push x s = MkStack x s
;size :: Stack a -> Integer
;size s = length (stkToLst s) where
{stkToLst Empty = []
;stkToLst (MkStack x s) = x:xs where {xs = stkToLst s
}};pop :: Stack a -> (a, Stack a)
;pop (MkStack x s)
= (x, case s of {r -> i r where {i x = x}}) -- (pop Empty) is an error
;top :: Stack a -> a
;top (MkStack x s) = x -- (top Empty) is an error
}

Figure 2: Sample program with layout expanded

6 2. LEXICAL STRUCTURE

2 Lexical Structure
In this section, we describe the low-level lexical structure of Haskell. Most of the details
may be skipped in a rst reading of the report.

2.1 Notational Conventions

These notational conventions are used for presenting syntax:
[pattern ] optional
fpattern g zero or more repetitions
(pattern ) grouping
pat1 j pat2 choice
pathpat i
0 dierence|elements generated by pat
except those generated by pat 0
fibonacci terminal syntax in typewriter font
Because the syntax in this section describes lexical syntax, all whitespace is expressed
explicitly; there is no implicit space between juxtaposed symbols. BNF-like syntax is used
throughout, with productions having the form:
nonterm ! alt1 j alt2 j : : : j altn
Care must be taken in distinguishing metalogical syntax such as j and [: : :] from concrete
terminal syntax (given in typewriter font) such as | and [...], although usually the context
makes the distinction clear.
Haskell uses the Unicode[10] character set. However, source programs are currently
biased toward the ASCII character set used in earlier versions of Haskell.
Haskell uses a pre-processor to convert non-Unicode character sets into Unicode. This
pre-processor converts all characters to Unicode and uses the escape sequence \uhhhh , where
the "h" are hex digits, to denote escaped unicode characters. Since this translation occurs
before the program is compiled, escaped Unicode characters may appear in identiers and
any other place in the program.
This syntax depends on properties of the Unicode characters as dened by the Unicode
consortium. Haskell compilers are expected to make use of new versions of Unicode as they
are made available.

2.2 Lexical Program Structure

program ! f lexeme j whitespace g
lexeme ! varid j conid j varsym j consym j literal j special j reservedop j reservedid
literal ! integer j oat j char j string
2.2 Lexical Program Structure 7

special ! ( j)j,j;j[j]j_jj{j}
whitespace ! whitestu fwhitestu g
whitestu ! whitechar j comment j ncomment
whitechar ! newline j return j linefeed j vertab j formfeed
j space j tab j UNIwhite
newline ! a newline (system dependent)
return ! a carriage return
linefeed ! a line feed
space ! a space
tab ! a horizontal tab
vertab ! a vertical tab
formfeed ! a form feed
uniWhite ! any UNIcode character dened as whitespace
comment ! -- fany g newline
ncomment ! {- ANYseq fncomment ANYseq g -}
ANYseq ! fANY ghfANY g ( {- j -} ) fANY gi
ANY ! any j newline j vertab j formfeed
any ! graphic j space j tab j nonbrkspc
graphic ! large j small j digit j symbol j special j : j " j '
small ! ASCsmall j UNIsmall
ASCsmall ! a j b j : : : j z
UNIsmall ! any Unicode lowercase letter
large ! ASClarge j UNIlarge
ASClarge ! A j B j : : : j Z
UNIlarge ! any uppercase or titlecase Unicode letter
symbol ! ASCsymbol j UNIsymbol
ASCsymbol ! ! j # j $ j % j & j * j + j . j / j < j = j > j ? j @
j \ j^j|j-j~
UNIsymbol ! Any Unicode symbol or punctuation
digit ! 0 j 1 j ::: j 9
udigit ! digit j UNIdigit
UNIdigit ! A Unicode numberic
octit ! 0 j 1 j ::: j 7
hexit ! digit j A j : : : j F j a j : : : j f

Characters not in the category ANY are not valid in Haskell programs and should result
in a lexing error. Comments are valid whitespace. An ordinary comment begins with two
consecutive dashes (--) and extends to the following newline. A nested comment begins
with {- and ends with -}; it can be between any two lexemes. All character sequences
not containing {- nor -} are ignored within a nested comment. Nested comments may
be nested to any depth: any occurrence of {- within the nested comment starts a new
8 2. LEXICAL STRUCTURE

nested comment, terminated by -}. Within a nested comment, each {- is matched by a

corresponding occurrence of -}. In an ordinary comment, the character sequences {- and
-} have no special signicance, and, in a nested comment, the sequence -- has no special
signicance. Nested comments are used for compiler pragmas, as explained in Appendix E.
If some code is commented out using a nested comment, then any occurrence of {- or -}
within a string or within an end-of-line comment in that code will interfere with the nested
comments.

2.3 Identiers and Operators

varid ! (small fsmall j large j udigit j ' j _g)hreservedid i
conid ! large fsmall j large j udigit j ' j _g
reservedid ! case j class j data j default j deriving j do j else
j j j j j
if import in infix infixl infixr instancej j
j j j j
let module newtype of then type wherej j j
specialid ! j
as qualified hiding j

An identier consists of a letter followed by zero or more letters, digits, underscores, and
single quotes. Identiers are lexically distinguished into two classes: those that begin with
a lower-case letter (variable identiers) and those that begin with an upper-case letter
(constructor identiers). Identiers are case sensitive: name, naMe, and Name are three
distinct identiers (the rst two are variable identiers, the last is a constructor identier).
Some identiers, here indicated by specialid , have special meanings in certain contexts but
can be used as ordinary identiers.
varsym ! ( symbol fsymbol j :g )hreservedopi
consym ! (: fsymbol j :g)hreservedopi
reservedop ! .. j :: j = j \ j | j <- j -> j @ j ~ j =>
specialop ! -j!
Operator symbols are formed from one or more symbol characters, as dened above,
and are lexically distinguished into two classes: those that start with a colon (constructors)
and those that do not (functions). Some operators, here indicated by specialop , have special
meanings in certain contexts but can be used as ordinary operators.
The sequence -- immediately terminates a symbol; thus +--+ parses as the symbol +
followed by a comment.
Other than the special syntax for prex negation, all operators are inx, although each
inx operator can be used in a section to yield partially applied operators (see Section 3.5).
All of the standard inx operators are just predened symbols and may be rebound.
Although case is a reserved word, cases is not. Similarly, although = is reserved, == and
~= are not. At each point, the longest possible lexeme is read, using a context-independent
2.4 Numeric Literals 9

deterministic lexical analysis (i.e. no lookahead beyond the current character is required).
Any kind of whitespace is also a proper delimiter for lexemes.
In the remainder of the report six dierent kinds of names will be used:
varid (variables)
conid (constructors)
tyvar ! varid (type variables)
tycon ! conid (type constructors)
tycls ! conid (type classes)
modid ! conid (modules)
Variables and type variables are represented by identiers beginning with small letters, and
the other four by identiers beginning with capitals; also, variables and constructors have
inx forms, the other four do not. Namespaces are also discussed in Section 1.4.
External names may optionally be qualied in certain circumstances by prepending them
with a module identier. This applies to variable, constructor, type constructor and type
class names, but not type variables or module names. Qualied names are discussed in
detail in Section 5.1.2.
qvarid ! [modid .] varid
qconid ! [modid .] conid
qtycon ! [modid .] tycon
qtycls ! [modid .] tycls
qvarsym ! [modid .] varsym
qconsym ! [modid .] consym

2.4 Numeric Literals

decimal ! digit fdigit g
octal ! octit foctit g
hexadecimal! hexit fhexit g

integer ! decimal
j 0o octal j 0O octal
j 0x hexadecimal j 0X hexadecimal
oat ! decimal . decimal [(e j E)[- j +]decimal ]
There are two distinct kinds of numeric literals: integer and oating. Integer literals may
be given in decimal (the default), octal (prexed by 0o or 0O) or hexadecimal notation
(prexed by 0x or 0X). Floating literals are always decimal. A oating literal must contain
digits both before and after the decimal point; this ensures that a decimal point cannot be
mistaken for another use of the dot character. Negative numeric literals are discussed in
Section 3.4. The typing of numeric literals is discussed in Section 6.3.1.
10 2. LEXICAL STRUCTURE

2.5 Character and String Literals

char ! ' (graphich' j \i j space j escapeh\&i) '
string ! " fgraphich" j \i j space j escape j gap g "
escape ! \ ( charesc j ascii j decimal j o octal j x hexadecimal )
charesc ! ajbjfjnjrjtjvj\j"j'j&
ascii ! ^cntrl j NUL j SOH j STX j ETX j EOT j ENQ j ACK
j BEL j BS j HT j LF j VT j FF j CR j SO j SI j DLE
j DC1 j DC2 j DC3 j DC4 j NAK j SYN j ETB j CAN
j EM j SUB j ESC j FS j GS j RS j US j SP j DEL
cntrl ! ASClarge j @ j [ j \ j ] j ^ j _
gap ! \ whitechar fwhitechar g \
Character literals are written between single quotes, as in 'a', and strings between
double quotes, as in "Hello".
Escape codes may be used in characters and strings to represent special characters.
Note that a single quote ' may be used in a string, but must be escaped in a character;
similarly, a double quote " may be used in a character, but must be escaped in a string.
\ must always be escaped. The category charesc also includes portable representations for
the characters \alert" (\a), \backspace" (\b), \form feed" (\f), \new line" (\n), \carriage
return" (\r), \horizontal tab" (\t), and \vertical tab" (\v).
Escape characters for the Unicode character set, including control characters such as \^X,
are also provided. Numeric escapes such as \137 are used to designate the character with
decimal representation 137; octal (e.g. \o137) and hexadecimal (e.g. \x37) representations
are also allowed. Numeric escapes that are out-of-range of the Unicode standard (16 bits)
are an error.
Consistent with the \consume longest lexeme" rule, numeric escape characters in strings
consist of all consecutive digits and may be of arbitrary length. Similarly, the one ambiguous
ASCII escape code, "\SOH", is parsed as a string of length 1. The escape character \& is
provided as a \null character" to allow strings such as "\137\&9" and "\SO\&H" to be
constructed (both of length two). Thus "\&" is equivalent to "" and the character '\&' is
disallowed. Further equivalences of characters are dened in Section 6.1.2.
A string may include a \gap"|two backslants enclosing white characters|which is
ignored. This allows one to write long strings on more than one line by writing a backslant
at the end of one line and at the start of the next. For example,
"Here is a backslant \\ as well as \137, \
\a numeric escape character, and \^X, a control character."

String literals are actually abbreviations for lists of characters (see Section 3.7).
 11

3 Expressions
In this section, we describe the syntax and informal semantics of Haskell expressions, includ-
ing 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 dened by
the Prelude. To avoid clutter, we use True instead of Prelude.True or map instead of
Prelude.map. (Prelude.True is a qualied 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 non-associativity and a precedence
level. A precedence-level variable i ranges from 0 to 9; an associativity variable a varies
over fl ; r ; n g. Thus, for example
aexp ! ( exp i +1 qop (a ;i ) )
actually stands for 30 productions, with 10 substitutions for i and 3 for a .
exp ! exp 0 :: [context =>] type (expression type signature)
j exp 0
exp i ! exp i +1 [qop (n;i ) exp i +1 ]
j lexp i
j rexp i
lexp i ! (lexp i j exp i +1 ) qop (l;i ) exp i +1
lexp 6 ! - exp 7
rexp i ! exp i +1 qop (r;i ) (rexp i j exp i +1 )
exp 10 ! \ apat1 : : : apatn -> exp (lambda abstraction; n  1 )
j let decllist in exp (let expression)
j if exp then exp else exp (conditional)
j case exp of { alts [;] } (case expression)
j do { stmts [;] } (do expression)
j fexp
fexp ! [fexp ] aexp (function application)
aexp ! qvar (variable)
j gcon (general constructor)
j literal
j ( exp ) (parenthesized expression)
j ( exp1 , : : : , expk ) (tuple; k  2 )
j [ exp1 , : : : , expk ] (list; k  1 )
j [ exp1 [, exp2 ] .. [exp3 ] ] (arithmetic sequence)
12 3. EXPRESSIONS

Item Associativity
simple terms, parenthesized terms {
irrefutable patterns (~) {
as-patterns (@) right
function application left
do, if, let, lambda(\), case (leftwards) right
case (rightwards) right
inx operators, prec. 9 as dened
... ...
inx operators, prec. 0 as dened
function types (->) right
contexts (=>) {
type constraints (::) {
do, if, let, lambda(\) (rightwards) right
sequences (..) {
generators (<-) {
grouping (,) n-ary
guards (|) {
case alternatives (->) {
denitions (=) {
separation (;) n-ary

Table 1: Precedence of expressions, patterns, denitions (highest to lowest)

j [ exp | qual1 , : : : , qualn ] (list comprehension; n  1 )

j ( exp i +1 qop (a ;i ) ) (left section)
j ( qop (a ;i ) exp i +1 ) (right section)
j qcon { fbind1 , : : : , fbindn } (labeled construction; n  0 )
j aexpfqcon g { fbind1 , : : : , fbindn } (labeled update; n  1 )

As an aid to understanding this grammar, Table 1 shows the relative precedence of

expressions, patterns and denitions, plus an extended associativity. ? indicates that the
item is non-associative.
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.
3.1 Errors 13

Expressions involving inx operators are disambiguated by the operator's xity (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 ex-
pression \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 prex operator in Haskell; it has the same precedence as the inx
- operator dened in the Prelude (see Figure 2, page 63).

The separation of function arrows from case alternatives solves the ambiguity that oth-
erwise 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.

3.1 Errors
Errors during expression evaluation, denoted by ?, are indistinguishable from non-termination.
Since Haskell is a lazy language, all Haskell types include ?. That is, a value of any type
may be bound to a computation that, when demanded, results in an error. When evalu-
ated, errors cause immediate program termination and cannot be caught by the user. The
Prelude provides two functions to directly cause such errors:
error :: String -> a
undefined :: a
A call to error terminates execution of the program and returns an appropriate error indi-
cation to the operating system. It should also display the string in some system-dependent
manner. When undefined is used, the error message is created by the compiler.
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.
14 3. EXPRESSIONS

3.2 Variables, Constructors, and Operators

aexp ! qvar (variable)
j gcon (general constructor)
j literal

gcon ! ()
j []
j (,f,g)
j qcon
qvar ! qvarid j ( qvarsym ) (qualied variable)
qcon ! qconid j ( qconsym ) (qualied constructor)
Alphanumeric operators are formed by enclosing an identier between grave accents
(backquotes). Any variable or constructor may be used as an operator in this way. If fun
is an identier (either variable or constructor), then an expression of the form fun x y is
equivalent to x fun y . If no xity 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 inx operator, then an expression or pattern of the
form x op y is equivalent to (op ) x y .
Qualied names may only be used to reference an imported variable or constructor (see
Section 5.1.2) but not in the denition of a new variable or constructor. Thus
let F.x = 1 in F.x -- invalid
incorrectly uses a qualier in the denition of x, regardless of the module containing this
denition. Qualication does not aect the nature of an operator: F.+ is an inx operator
just as + is.
Special syntax is used to name some constructors for some of the built-in 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 appro-
priate value of type Integer. Similarly, a oating 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 oating 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 dened in the Ratio library. The integers n and d are chosen so
that n =d = f .
3.3 Curried Applications and Lambda Abstractions 15

3.3 Curried Applications and Lambda Abstractions

fexp ! [fexp ] aexp (function application)
exp ! \ apat1 : : : apatn -> exp
Function application is written e1 e2 . Application associates to the left, so the parentheses
may be omitted in (f x) y. Because e1 could be a data constructor, partial applications
of data constructors are allowed.
Lambda abstractions are written \ p1 : : : pn -> e , where the pi are patterns. An ex-
pression such as \x:xs->x is syntactically incorrect, and must be rewritten as \(x:xs)->x.
The set of patterns must be linear|no variable may appear more than once in the set.

Translation: The lambda abstraction \ p1 : : : pn -> e is equivalent to

\ x1 : : : x n -> case (x1 , : : : , xn ) of (p1 , : : : , pn ) -> e
where the xi are new identiers. 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 ?.

3.4 Operator Applications

exp ! exp1 qop exp2
j - exp (prex negation)

The form e1 qop e2 is the inx application of binary operator qop to expressions e1 and
e2 .
The special form -e denotes prex negation, the only prex operator in Haskell, and is
syntax for negate (e ). The binary - operator does not necessarily refer to the denition of
- in the Prelude; it may be rebound by the module system. However, unary - will always
refer to the negate function dened in the Prelude. There is no link between the local
meaning of the - operator and unary negation.
Prex negation has the same precedence as the inx operator - dened in the Prelude
(see Table 2, page 63). Because e1-e2 parses as an inx application of the binary oper-
ator -, one must write e1(-e2) for the alternative parsing. Similarly, (-) is syntax for
(\ x y -> x-y), as with any inx operator, and does not denote (\ x -> -x)|one must
use negate for that.

Translation: e1 op e2 is equivalent to (op ) e1 e2 . -e is equivalent to negate (e ).

16 3. EXPRESSIONS

3.5 Sections
aexp ! ( exp qop )
j ( qop exp )

Sections are written as ( op e ) or ( e op ), where op is a binary operator and e is an

expression. Sections are a convenient syntax for partial application of binary operators.
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 applica-
tion of prex negation, as described in the preceding section. However, there is a subtract
function dened 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 .

3.6 Conditionals
exp ! if exp1 then exp2 else exp3

A conditional expression has the form if e1 then e2 else e3 and returns the value of e2
if the value of e1 is True, e3 if e1 is False, and ? otherwise.

Translation: if e1 then e2 else e3 is equivalent to:

case e1 of { True -> e2 ; False -> e3 }

where True and False are the two nullary constructors from the type Bool, as dened
in the Prelude.

3.7 Lists
aexp ! [ exp1 , : : : , expk ] (k  1 )

Lists are written [e1 , : : : , ek ], where k  1 ; the empty list is written []. Standard
operations on lists are given in the Prelude (see Appendix A, notably Section A.1).
3.8 Tuples 17

Translation: [e1 , : : : , ek ] is equivalent to

e1 : (e2 : ( : : : (ek : [])))

where : and [] are constructors for lists, as dened in the Prelude (see Section 6.1.3).
The types of e1 through ek must all be the same (call it t ), and the type of the overall
expression is [t ] (see Section 4.1.1).

3.8 Tuples
aexp ! ( exp1 , : : : , expk ) (k  2 )
Tuples are written (e1 , : : : , ek ), and may be of arbitrary length k  2 . Standard opera-
tions on tuples are given in the Prelude (see Appendix A).

Translation: (e1 , : : : , ek ) for k  2 is an instance of a k -tuple as dened in the

Prelude, and requires no translation. If t1 through tk are the types of e1 through ek ,
respectively, then the type of the resulting tuple is (t1 , : : : , tk ) (see Section 4.1.1).

3.9 Unit Expressions and Parenthesized Expressions

aexp ! ()
j ( exp )

The form (e ) is simply a parenthesized expression, and is equivalent to e . The unit expres-
sion () has type () (see Section 4.1.1); it is the only member of that type apart from ? (it
can be thought of as the \nullary tuple")|see Section 6.1.5.

Translation: (e ) is equivalent to e .

3.10 Arithmetic Sequences

aexp ! [ exp1 [, exp2 ] .. [exp3 ] ]

The form [e1 , e2 .. e3 ] denotes an arithmetic sequence from e1 in increments of e2 ? e1

of values not greater than e3 (if the increment is nonnegative) or not less than e3 (if the
increment is negative). Thus, the resulting list is empty if the increment is nonnegative and
e3 is less than e1 or if the increment is negative and e3 is greater than e1 . If the increment
is zero, an innite list of e1 s results if e3 is not less than e1 . If e3 is omitted, the result
is an innite list, unless the element type is nite, in which case the implied limit is the
greatest value of the type if the increment is nonnegative, or the least value, otherwise.
18 3. EXPRESSIONS

The forms [e1 .. e3 ] and [e1 ..] are similar to those above, but with an implied incre-
ment of one.
Arithmetic sequences may be dened over any type in class Enum, including Char, Int,
and Integer (see Figure 5 , page 67 and Section 4.3.3). For example, ['a'..'z'] denotes
the list of lowercase letters in alphabetical order.

Translation: Arithmetic sequences satisfy these identities:

[ e1 .. ] = enumFrom e1
[ e1 ,e2 .. ] = enumFromThen e1 e2
[ e1 ..e3 ] = enumFromTo e1 e3
[ e1 ,e2 ..e3 ] = enumFromThenTo e1 e2 e3
where enumFrom, enumFromThen, enumFromTo, and enumFromThenTo are class methods
in the class Enum as dened in the Prelude (see Figure 5 , page 67 ).

3.11 List Comprehensions

aexp ! [ exp | qual1 , : : : , qualn ] (list comprehension; n  1 )
qual ! pat <- exp
j let decllist
j exp
A list comprehension has the form [ e | q1 , : : : , qn ]; n  1 ; where the qi qualiers are
either
 generators of the form p <- e , where p is a pattern (see Section 3.17) of type t and e
is an expression of type Monad m => m t
 guards, which are arbitrary expressions of type Bool
 local bindings that provide new denitions for use in the generated expression e or
subsequent guards and generators.
While list comprehensions are commonly used to generate lists, the denition 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, depth-rst evaluation of the generators in
the qualier 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 ]
3.12 Let Expressions 19

yields the list [4,2]. If a qualier 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:
[ e | q1 : : : qn ] = do {T (q1 );: : :;T (qn ); return e }
T (b ) = guard b
T (let decllist ) = let decllist
T (p <- l ) = p <- l
where e ranges over expressions, p ranges over patterns, l ranges over list-valued ex-
pressions, and b ranges over boolean expressions. The return and guard functions are
as dened in the Prelude.

As indicated by the translation of list comprehensions, variables bound by let have fully
polymorphic types while those dened by <- are lambda bound and are thus monomorphic
(see Section 4.5.4).

3.12 Let Expressions

exp ! let decllist in exp

Let expressions have the general form let { d1 ; : : : ; dn } in e , and introduce a nested,
lexically-scoped, mutually-recursive list of declarations (let is often called letrec in other
languages). The scope of the declarations is the expression e and the right hand side of the
declarations. Declarations are described in Section 4. Pattern bindings are matched lazily;
an implicit ~ makes these patterns irrefutable. For example,
let (x,y) = undefined in e

does not cause an execution-time error until x or y is evaluated.

20 3. EXPRESSIONS

Translation: The dynamic semantics of the expression let { d1 ; : : : ; dn } in e0

are captured by this translation: After removing all type signatures, each declaration
di is translated into an equation of the form pi = ei , where pi and ei 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:

let {p1 = e1 ; ...; pn = en } in e0 = let (~p1 ,...,~pn ) = (e1 ,...,en ) in e0

let p = e1 in e0 = case e1 of ~p -> e0
where no variable in p appears free in e1
let p e1 in e0
= = let p = fix ( \ ~p -> e1 ) in e0
where is the least xpoint operator. Note the use of the irrefutable patterns in the
fix
second and third rules. This translation does not preserve the static semantics because
the use of case precludes a fully polymorphic typing of the bound variables. The static
semantics of the bindings in a let expression are described in Section 4.4.2.

3.13 Case Expressions

exp ! case exp of { alts [;] }
alts ! alt1 ; : : : ; altn (n  1 )
alt ! pat -> exp [where decllist ]
j pat gdpat [where decllist ]
gdpat ! gd -> exp [ gdpat ]
gd ! | exp 0
A case expression has the general form
case e of { p1 match1 ; : : : ; pn matchn }

where each matchi is of the general form

| gi1 -> ei1
:::
| gimi -> eimi
where decllisti

Each alternative pi matchi consists of a pattern pi and its matches, matchi , which consists
of pairs of guards gij and bodies eij (expressions), as well as optional bindings (decllisti )
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
3.14 Do Expressions 21

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 in-
dividual alternatives. The matches are tried sequentially, from top to bottom. The rst
successful match causes evaluation of the corresponding alternative body, in the environ-
ment of the case expression extended by the bindings created during the matching of that
alternative and by the decllisti 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.

3.14 Do Expressions
exp ! do { stmts [;]} (do expression)
stmts ! exp [; stmts ]
j pat <- exp ; stmts
j let decllist ; stmts
A do expression provides a more readable syntax for monadic programming.

Translation: Do expressions satisfy these identities, which may be used as a transla-

tion into the kernel:
do {e } = e
do {e ;stmts } = e >> do {stmts }
do {p <- e ; stmts } = e >>= \p -> do {stmts }
where p is failure-free
do {p <- e ; stmts } = let ok p = do {stmts }
ok _ = zero
in e >>= ok
where p is not failure-free
do {let decllist ; stmts } = letdecllist in do {stmts }

>>, >>=, and zero are operations in the classes Monad and MonadZero, as dened in the
Prelude., and ok is a new identier not appearing in p.
A failure-free pattern is one that can only be refuted by ?. Failure-free patterns are
dened as follows:
 All irrefutable patterns are failure-free (irrefutable patterns are described in Section
3.17.1).
 If C is the only constructor in its type, then C p1 : : : pn is failure-free when each of
the pi is failure free.
22 3. EXPRESSIONS

 If pattern p is failure-free, then the pattern v @p is failure-free.

This translation requires a monad in class MonadZero if any pattern bound by <- is not
failure-free. Otherwise, only class methods from Monad are generated. Type errors resulting
from patterns that are not failure-free can be corrected by using ~ to force the pattern to
be failure-free.
As indicated by the translation of do, variables bound by let have fully polymorphic
types while those dened by <- are lambda bound and are thus monomorphic.

3.15 Datatypes with Field Labels

A datatype declaration may optionally include eld labels for some or all of the components
of the type (see Section 4.2.1). Readers unfamiliar with datatype declarations in Haskell
may wish to read Section 4.2.1 rst. These eld labels can be used to construct, select from,
and update elds in a manner that is independent of the overall structure of the datatype.
Dierent datatypes cannot share common eld labels in the same scope. A eld label
can be used at most once in a constructor. Within a datatype, however, a eld name can be
used in more than one constructor provided the eld has the same typing in all constructors.

3.15.1 Field Selection

aexp ! qvar
Field names are used as selector functions. When used as a variable, a eld name serves
as a function that extracts the eld from an object. Selectors are top level bindings and so
they may be shadowed by local variables but cannot con ict with other top level bindings of
the same name. This shadowing only aects selector functions; in other record constructs,
eld labels cannot be confused with ordinary variables.

Translation: A eld label f introduces a selector function dened as:

f x = case x of { C1 p11 : : : p1k -> e1 ; : : : ; Cn pn1 : : : pnk -> en }
where C1 : : : Cn are all the constructors of the datatype containing a eld labeled with
f , pij is y when f labels the j th component of Ci or _ otherwise, and ei is y when some
eld in Ci has a label of f or undefined otherwise.

3.15.2 Construction Using Field Labels

aexp ! qcon { fbind1 , : : : , fbindn } (labeled construction; n  0 )
fbind ! var j qvar = exp
3.15 Datatypes with Field Labels 23

A constructor with labeled elds may be used to construct a value in which the components
are specied by name rather than by position. Unlike the braces used in declaration lists,
these are not subject to layout; the { and } characters must be explicit. (This is also true of
eld updates and eld patterns.) Construction using eld names is subject to the following
constraints:
 Only eld labels declared with the specied constructor may be mentioned.
 A eld name may not be mentioned more than once.
 Fields not mentioned are initialized to ?.
 When the = exp is omitted and there is a variable with the same name as the eld
label in scope, the eld is initialized to the value of that variable.
 A compile-time error occurs when any strict elds (elds whose declared types are
prexed by !) are omitted during construction. Strict elds are discussed in Sec-
tion 4.2.1.

Translation: In the binding f = v , the eld f labels v . Any binding f that omits the
= v is expanded to f = f .
C { bs } = C (pick1C bs undefined) : : : (pickkC bs undefined)
k is the arity of C .
The auxiliary function pickiC bs d is dened as follows:
If the i th component of a constructor C has the eld name f , and if f = v
appears in the binding list bs , then pickiC bs d is v . Otherwise, pickiC bs d
is the default value d .

3.15.3 Updates Using Field Labels

aexp ! aexphqcon i { fbind1 , : : : , fbindn } (labeled update; n  1 )

Values belonging to a datatype with eld names may be non-destructively updated. This
creates a new value in which the specied eld values replace those in the existing value.
Updates are restricted in the following ways:
 All labels must be taken from the same datatype.
 At least one constructor must dene all of the labels mentioned in the update.
 No label may be mentioned more than once.
 An execution error occurs when the value being updated does not contain all of the
specied labels.
24 3. EXPRESSIONS

 When the = exp is omitted, the eld is updated to the value of the variable in scope
with the same name as the eld label.

Translation: Using the prior denition of pick ,

e { bs } = case e of
C1 v1 : : : vk1 -> C (pick1C bs v1 ) : : : (pickkC bs vk1 )
...
Cj v1 : : : vkj -> C (pick1C bs v1 ) : : : (pickkC bs vkj )
_ -> error "Update error"
where fC1 ; : : :; Cj g is the set of constructors containing all labels in b , and ki is the
arity of Ci .

Here are some examples using labeled elds:

data T = C1 {f1,f2 :: Int}
| C2 {f1 :: Int,
f3,f4 :: Char}

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 eld 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 compile-time error will result if no single
constructor denes the set of eld names used in an update, such as x {f2 = 1, f3 = 'x'}.

3.16 Expression Type-Signatures

exp ! exp :: [context =>] type
Expression type-signatures have the form e :: t , where e is an expression and t is a type
(Section 4.1.1); they are used to type an expression explicitly and may be used to resolve
ambiguous typings due to overloading (see Section 4.3.4). The value of the expression is
just that of exp . As with normal type signatures (see Section 4.4.1), the declared type may
be more specic than the principal type derivable from exp , but it is an error to give a type
that is more general than, or not comparable to, the principal type.

3.17 Pattern Matching

Patterns appear in lambda abstractions, function denitions, pattern bindings, list compre-
hensions, do expressions, and case expressions. However, the rst ve of these ultimately
translate into case expressions, so dening the semantics of pattern matching for case ex-
pressions is sucient.
3.17 Pattern Matching 25

3.17.1 Patterns
Patterns have this syntax:
pat ! var + integer (successor pattern)
pat j pat 0
pat i ! pat i +1 [qconop (n;i ) pat i +1 ]
j lpat i
j rpat i
lpat i ! (lpat i j pat i +1 ) qconop (l;i ) pat i +1
lpat 6 ! - (integer j oat ) (negative literal)
rpat i ! pat i +1 qconop (r;i ) (rpat i j pat i +1 )
pat 10 ! apat
j gcon apat1 : : : apatk (arity gcon = k ; k  1 )
apat ! var [ @ apat ] (as pattern)
j gcon (arity gcon = 0 )
j qcon { fpat1 , : : : , fpatk } (labeled pattern; k  0 )
j literal
j _ (wildcard)
j ( pat ) (parenthesized pattern)
j ( pat1 , : : : , patk ) (tuple pattern; k  2 )
j [ pat1 , : : : , patk ] (list pattern; k  1 )
j ~ apat (irrefutable pattern)
fpat ! var = pat
j var
The arity of a constructor must match the number of sub-patterns associated with it; one
cannot match against a partially-applied constructor.
All patterns must be linear |no variable may appear more than once.
Patterns of the form var @pat are called as-patterns, 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 right-hand-side. It is as if an identier not used elsewhere were put in its
place. For example,
case e of { [x,_,_] -> if x==0 then True else False }
26 3. EXPRESSIONS

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 dened 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.

3.17.2 Informal Semantics of Pattern Matching

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:
1. Matching a value v against the irrefutable pattern var always succeeds and binds var
to v . Similarly, matching v against the irrefutable pattern ~apat always succeeds.
The free variables in apat are bound to the appropriate values if matching v against
apat would otherwise succeed, and to ? if matching v against apat fails or diverges.
(Binding does not imply evaluation.)
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.
2. Matching a value con v against the pattern con pat , where con is a constructor dened
by newtype, is equivalent to matching v against the pattern pat . That is, constructors
associated with newtype serve only to change the type of a value.
3. Matching ? against a refutable pattern always diverges.
4. Matching a non-? value can occur against three kinds of refutable patterns:
(a) Matching a non-? value against a pattern whose outermost component is a con-
structor dened by data fails if the value being matched was created by a dier-
ent constructor. If the constructors are the same, the result of the match is the
result of matching the sub-patterns left-to-right against the components of the
data value: if all matches succeed, the overall match succeeds; the rst to fail or
diverge causes the overall match to fail or diverge, respectively.
(b) Numeric literals are matched using the overloaded == function. The behavior of
numeric patterns depends entirely on the denition of == for the type of object
being matched.
3.17 Pattern Matching 27

(c) Matching a non-? value x against a pattern of the form n +k (where n is a variable
and k is a positive integer literal) succeeds if x  k , resulting in the binding of
n to x ? k , and fails if x < k . The behavior of n +k patterns depends entirely on
the underlying denitions of >=, fromInteger, and - for the type of the object
being matched.
5. Matching against a constructor using labeled elds is the same as matching ordinary
constructor patterns except that the elds are matched in the order they are named
in the eld list. All elds listed must be declared by the constructor; elds may not
be named more than once. Fields not named by the pattern are ignored (matched
against _).
6. The result of matching a value v against an as-pattern var @apat is the result of
matching v against apat augmented with the binding of var to v . If the match of v
against apat fails or diverges, then so does the overall match.
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 oating 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 ag that disables the
use of these patterns.
Here are some examples:
1. If the pattern [1,2] is matched against [0,?], then 1 fails to match against 0, and
the result is a failed match. But if [1,2] is matched against [?,0], then attempting
to match 1 against ? causes the match to diverge .
2. These examples demonstrate refutable vs. irrefutable matching:
(\ ~(x,y) -> 0) ? ) 0
(\ (x,y) -> 0) ? ) ?
(\ ~[x] -> 0) [] ) 0
(\ ~[x] -> x) [] ) ?
(\ ~[x,~(a,b)] -> x) [(0,1), ] ? ) (0,1)
(\ ~[x, (a,b)] -> x) [(0,1), ] ? ) ?
(\ (x:xs) -> x:x:xs) ? ) ?
(\ ~(x:xs) -> x:x:xs) ? ) ?:?:?
Additional examples illustrating some of the subtleties of pattern matching may be found
in Section 4.2.3.
28 3. EXPRESSIONS

(a) case e of { alts } = (\v -> case v of { alts }) e

where v is a completely new variable
(b) case v
of { 1 p match1; : : : ; pn matchn }
= case of {v p1 match1 ;
_ -> : : : case v of {
pn matchn
_ -> error "No match" } : : :}
where each matchi has the form:
| gi;1 -> ei;1 ; : : : ; | gi;m -> ei;m where { declsi }
i i

(c) case v of { p | g1 -> e1 ; : : :

| gn -> en where { decls }
_ -> e0 }
= case e0 of
{y -> (where y is a completely new variable)
case v of {
p -> let { decls } in
if g1 then e1 : : : else if gn then en else y
_ -> y }}
(d) case v of { ~p -> e; _ -> e0 }
= (\x01 : : : x0n -> e1 ) (case v of { p-> x1 }) : : : (case v of { p -> xn })
where e1 = e [x01 =x1; : : :; x0n=xn ]
x1 ; : : :; xn are all the variables in p; x01 ; : : :; x0n are completely new variables
(e) case v of { x@p -> e; _ -> e0 }
= case v of { p -> ( \ x -> e ) v ; _ -> e0 }
(f) case v of { _ -> e; _ -> e0 } = e

Figure 3: Semantics of Case Expressions, Part 1

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 right-hand-side of the case-expression alternative, function denition, or
pattern binding to which it is attached.
The guard semantics have an obvious in uence 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 denition of ==.

3.17 Pattern Matching 29

3.17.3 Formal Semantics of Pattern Matching

The semantics of all pattern matching constructs other than case expressions are dened
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 3{4. Any
implementation should behave so that these identities hold; it is not expected that it will
use them directly, since that would generate rather inecient code.
In Figures 3{4: e , e 0 and ei are expressions; g and gi are boolean-valued expressions;
p and pi are patterns; v , x , and xi are variables; K and K 0 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 source-language case expression, regardless of whether it
actually includes guards|if no guards are written, then True is substituted for the guards
gi ;j in the matchi 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 denes 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).
30 3. EXPRESSIONS

(g) case v
of { K p1 : : :pn -> e; _ -> e0 }
v
= case of {
K x1 : : :xn -> case x1 of {
p1 -> :::
case xn of { pn -> e ; _ -> e0 } :::
_ -> 0 }
e
_ -> e0 }
at least one of p1 ; : : :; pn is not a variable; x1; : : :; xn are new variables
(h) case v of { k -> e; _ -> e0 } = if (v ==k) then e else e0
(i) case v of { x -> e; _ -> e0 } = case v of { x -> e }
(j) case v of { x -> e } = ( \ x -> e ) v
(k) case N v of { N p -> e; _ -> e0 }
= case v of { p -> e; _ -> e0 }
where N is a newtype constructor
(l) case ? of { N p -> e; _ -> e0 } = case ? of { p -> e }
where N is a newtype constructor
(m) case v of { K { f1 = p1 , f2 = p2 , : : : } -> e ; _ -> e0 }
= case e0 of {
y ->
case v of {
K { f1 = p1 } ->
case v of { K { f2 = p2 , ::: } -> e; _ -> y };
_ -> y }}
where f1 , f2 , : : : are elds of constructor K ; y is a new variable
(n) case v of { K { f = p} -> e; _ -> e0 }
= case v of {
K p1 : : : pn -> e ; _ -> e0 }
where pi is p if f labels the ith component of K , _ otherwise
(o) case v of { K {} -> e ; _ -> e0 }
= case v of {
K _ : : : _ -> e ; _ -> e0 }
(p) case (K 0 e1 : : : em ) of { K x1 : : : xn -> e; _ -> e0 } = e0
where K and K 0 are distinct data constructors of arity n and m, respectively
(q) case (K e1 : : : en ) of { K x1 : : : xn -> e; _ -> e0 }
= case e1 of { x01 -> : : : case en of { x0n -> e[x01=x1 : : :x0n =xn ] }: : :}
where K is a constructor of arity n; x01 : : :x0n are completely new variables
(r) case e0 of { x+k -> e; _ -> e0 }
= if e0 >= k then let {x0 = e0 -k} in e[x0 =x] else e0 (x0 is a new variable)

Figure 4: Semantics of Case Expressions, Part 2

 31

4 Declarations and Bindings

In this section, we describe the syntax and informal semantics of Haskell declarations.
module ! module modid [exports ] where body
j body
body ! { [impdecls ;] [[xdecls ;] topdecls [;]] }
j { impdecls [;] }
topdecls ! topdecl1 ; : : : ; topdecln (n  0 )
topdecl ! type simpletype = type
j data [context =>] simpletype = constrs [deriving ]
j newtype [context =>] simpletype = con atype [deriving ]
j class [context =>] simpleclass [where { cbody [;] }]
j instance [context =>] qtycls inst [where { valdefs [;] }]
j default (type1 , : : : , typen ) (n  0 )
j decl
decls ! decl1 ; : : : ; decln (n  0 )
decl ! signdecl
j valdef
decllist ! { decls [;] }
signdecl ! vars :: [context =>] type
vars ! var1 , : : : , varn (n  1 )
The declarations in the syntactic category topdecls are only allowed at the top level of
a Haskell module (see Section 5), whereas decls may be used either at the top level or in
nested scopes (i.e. those within a let or where construct).
For exposition, we divide the declarations into three groups: user-dened datatypes,
consisting of type, newtype, and data declarations (Section 4.2); type classes and over-
loading, consisting of class, instance, and default declarations (Section 4.3); and nested
declarations, consisting of value bindings and type signatures (Section 4.4).
Haskell has several primitive datatypes that are \hard-wired" (such as integers and
oating-point numbers), but most \built-in" datatypes are dened with normal Haskell
code, using normal type and data declarations. These \built-in" datatypes are described
in detail in Section 6.1.

4.1 Overview of Types and Classes

Haskell uses a traditional Hindley-Milner polymorphic type system to provide a static type
semantics [3, 4], but the type system has been extended with type and constructor classes
(or just classes) that provide a structured way to introduce overloaded functions.
32 4. DECLARATIONS AND BINDINGS

A class declaration (Section 4.3.1) introduces a new type class and the overloaded
operations that must be supported by any type that is an instance of that class. An
instance declaration (Section 4.3.2) declares that a type is an instance of a class and
includes the denitions of the overloaded operations|called class methods|instantiated
on the named type.
For example, suppose we wish to overload the operations (+) and negate on types Int
and Float. We introduce a new type class called Num:
class Num a where -- simplified class declaration for Num
(+) :: a -> a -> a
negate :: a -> a
This declaration may be read \a type a is an instance of the class Num if there are (over-
loaded) class methods (+) and negate, of the appropriate types, dened on it."
We may then declare Int and Float to be instances of this class:
instance Num Int where -- simplified instance of Num Int
x + y = addInt x y
negate x = negateInt x
instance Num Float where -- simplified instance of Num Float
x + y = addFloat x y
negate x = negateFloat x
where addInt, negateInt, addFloat, and negateFloat are assumed in this case to be
primitive functions, but in general could be any user-dened function. The rst declaration
above may be read \Int is an instance of the class Num as witnessed by these denitions
(i.e. class methods) for (+) and negate."
More examples of type and constructor classes can be found in the papers by Jones [6]
or Wadler and Blott [11]. The term `type class' was used to describe the original Haskell
1.0 type system; `constructor class' was used to describe an extension to the original type
classes. There is no longer any reason to use two dierent terms: in this report, `type class'
includes both the original Haskell type classes and the constructor classes introduced by
Jones.

4.1.1 Syntax of Types

type ! btype [-> type ] (function type)
btype ! [btype ] atype (type application)
atype ! gtycon
j tyvar
j ( type1 , : : : , typek ) (tuple type; k  2 )
j [ type ] (list type)
j ( type ) (parenthesised constructor)
4.1 Overview of Types and Classes 33

gtycon ! qtycon
j () (unit type)
j [] (list constructor)
j (->) (function constructor)
j (,f,g) (tupling constructors)

The syntax for Haskell type expressions is given above. Just as data values are built using
data constructors, type values are built from type constructors . As with data constructors,
the names of type constructors start with uppercase letters.
To ensure that they are valid, type expressions are classied into dierent kinds, which
take one of two possible forms:
 The symbol  represents the kind of all nullary type constructors.
 If  and  are kinds, then  !  is the kind of types that take a type of kind 
1 2 1 2 1
and return a type of kind  .
2

The main forms of type expression are as follows:

1. Type variables, written as identiers beginning with a lowercase letter. The kind of a
variable is determined implicitly by the context in which it appears.
2. Type constructors. Most type constructors are written as identiers beginning with
an uppercase letter. For example:
 Char, Int, Integer, Float, Double and Bool are type constants with kind .
 Maybe and IO are unary type constructors, and treated as types with kind  ! .
 The declarations data T ... or newtype T ... add the type constructor T to
the type vocabulary. The kind of T is determined by kind inference.
Special syntax is provided for some type constructors:
 The trivial type is written as () and has kind . It denotes the \nullary tuple"
type, and has exactly one value, also written () (see Sections 3.9 and 6.1.5).
 The function type is written as (->) and has kind  !  ! .
 The list type is written as [] and has kind  ! .
 The tuple types are written as (,), (,,), and so on. Their kinds are  !  ! ,
 !  !  ! , and so on.
Use of the (->) and [] constants is described in more detail below.
3. Type application. If t1 is a type of kind 1 ! 2 and t2 is a type of kind 1 , then
t1 t2 is a type expression of kind 2.
4. A parenthesized type, having form (t ), is identical to the type t .
34 4. DECLARATIONS AND BINDINGS

For example, the type expression IO a can be understood as the application of a constant,
IO, to the variable a. Since the IO type constructor has kind  ! , it follows that both
the variable a and the whole expression, IO a, must have kind . In general, a process of
kind inference (see Section 4.6) is needed to determine appropriate kinds for user-dened
datatypes, type synonyms, and classes.
Special syntax is provided to allow certain type expressions to be written in a more
traditional style:
1. A function type has the form t1 -> t2 , which is equivalent to the type (->) t1 t2 .
Function arrows associate to the right.
2. A tuple type has the form (t1 , : : : , tk ) where k  2 , which is equivalent to the type
(,. . . ,) t1 : : : tk where there are k ? 1 commas between the parenthesis. It denotes
the type of k -tuples with the rst component of type t1 , the second component of
type t2 , and so on (see Sections 3.8 and 6.1.4).
3. A list type has the form [t ], which is equivalent to the type [] t . It denotes the type
of lists with elements of type t (see Sections 3.7 and 6.1.3).
Although the tuple, list, and function types have special syntax, they are not dierent from
user-dened types with equivalent functionality.
Expressions and types have a consistent syntax. If ti is the type of expression or pattern
ei , then the expressions (\ e1 -> e2 ), [e1 ], and (e1 ; e2 ) have the types (t1 -> t2 ), [t1 ],
and (t1 ; t2 ), respectively.
With one exception, the type variables in a Haskell type expression are all assumed to
be universally quantied; there is no explicit syntax for universal quantication [3]. For
example, the type expression a -> a denotes the type 8 a : a ! a . For clarity, however,
we often write quantication explicitly when discussing the types of Haskell programs.
The exception referred to is that of the distinguished type variable in a class declaration
(Section 4.3.1).

4.1.2 Syntax of Class Assertions and Contexts

context ! class
j ( class1 , : : : , classn ) (n  1 )
class ! qtycls tyvar
simpleclass ! tycls tyvar
tycls ! conid
tyvar ! varid

A class assertion has form qtycls tyvar , and indicates the membership of the parameterized
type tyvar in the class qtycls . A class identier begins with an uppercase letter.
4.1 Overview of Types and Classes 35

A context consists of one or more class assertions, and has the general form
( C1 u1 ; : : :; Cn un )
where C1 ; : : :; Cn are class identiers, and u1 ; : : :; un are type variables; the parentheses
may be omitted when n = 1 . In general, we use c to denote a context and we write c => t
to indicate the type t restricted by the context c . The context c must only contain type
variables referenced in t . For convenience, we write c => t even if the context c is empty,
although in this case the concrete syntax contains no =>.

4.1.3 Semantics of Types and Classes

In this subsection, we provide informal details of the type system. (Wadler and Blott [11]
and Jones [6] discuss type and constructor classes, respectively, in more detail.)
The Haskell type system attributes a type to each expression in the program. In general,
a type is of the form 8 u : c ) t , where u is a set of type variables u1 ; : : :; un . In any
such type, any of the universally-quantied type variables ui that are free in c must also be
free in t . Furthermore, the context c must be of the form given above in Section 4.1.2; that
is, it must have the form (C1 u1 ; : : :; Cn un ) where C1 ; : : :; Cn are class identiers, and
u1 ; : : :; un are type variables.
The type of an expression e depends on a type environment that gives types for the
free variables in e , and a class environment that declares which types are instances of
which classes (a type becomes an instance of a class only via the presence of an instance
declaration or a deriving clause).
Types are related by a generalization order (specied below); the most general type that
can be assigned to a particular expression (in a given environment) is called its principal
type. Haskell's extended Hindley-Milner type system can infer the principal type of all ex-
pressions, including the proper use of overloaded class methods (although certain ambiguous
overloadings could arise, as described in Section 4.3.4). Therefore, explicit typings (called
type signatures) are usually optional (see Sections 3.16 and 4.4.1).
The type 8 u : c1 ) t1 is more general than the type 8 w : c2 ) t2 if and only if
there is a substitution S whose domain is u such that:
 t2 is identical to S (t1 ).
 Whenever c2 holds in the class environment, S (c1 ) also holds.
The main point about contexts above is that, given the type 8 u : c ) t , the presence of
C ui in the context c expresses the constraint that the type variable ui may be instantiated
as t 0 within the type expression t only if t 0 is a member of the class C . For example, consider
the function double:
double x = x + x
The most general type of double is 8 a : Num a ) a ! a . double may be applied to
values of type Int (instantiating a to Int), since Int is an instance of the class Num. However,
double may not be applied to values of type Char, because Char is not an instance of class
Num.
36 4. DECLARATIONS AND BINDINGS

4.2 User-Dened Datatypes

In this section, we describe algebraic datatypes (data declarations), renamed datatypes
(newtype declarations), and type synonyms (type declarations). These declarations may
only appear at the top level of a module.

4.2.1 Algebraic Datatype Declarations

topdecl ! data [context =>] simpletype = constrs [deriving ]
simpletype ! tycon tyvar1 : : : tyvark (k  0 )
constrs ! constr1 | : : : | constrn (n  1 )
constr ! con [!] atype1 : : : [!] atypek (arity con = k ; k  0 )
j (btype j ! atype ) conop (btype j ! atype ) (inx conop )
j con { elddecl1 , : : : , elddecln } (n  1 )
elddecl ! vars :: (type j ! atype )
deriving ! deriving (dclass j (dclass1 , : : : , dclassn ))(n  0 )
dclass ! qtycls
The precedence for constr is the same as that for expressions|normal constructor appli-
cation has higher precedence than inx constructor application (thus a : Foo a parses as
a : (Foo a)).
An algebraic datatype declaration introduces a new type and constructors over that
type and has the form:
data c => T u1 : : : uk = K1 t11 : : : t1k1 |


| Kn tn1 : : : tnkn

where c is a context. This declaration introduces a new type constructor T with constituent
data constructors K1 ; : : :; Kn whose types are given by:
Ki :: 8 u1 : : : uk : ci ) ti1 !


! tiki ! (T u1 : : : uk )
where ci is the largest subset of c that constrains only those type variables free in the types
ti1 ; : : :; tiki . The type variables u1 through uk must be distinct and may appear in c and
the tij ; it is a static error for any other type variable to appear in c or on the right-hand-side.
The new type constant T has a kind of the form 1 ! : : : ! k !  where the kinds i of
the argument variables ui are determined by kind inference as described in Section 4.6. This
means that T may be used in type expressions with anywhere between 0 and k arguments.
For example, the declaration
data Eq a => Set a = NilSet | ConsSet a (Set a)
introduces a type constructor Set of kind  ! , and constructors NilSet and ConsSet
with types
NilSet :: 8 a : Set a
ConsSet :: 8 a : Eq a ) a ! Set a ! Set a
4.2 User-Dened Datatypes 37

In the example given, the overloaded type for ConsSet ensures that ConsSet can only
be applied to values whose type is an instance of the class Eq. The context in the data
declaration has no other eect whatsoever.
The visibility of a datatype's constructors (i.e. the \abstractness" of the datatype) out-
side of the module in which the datatype is dened is controlled by the form of the datatype's
name in the export list as described in Section 5.5.
The optional deriving part of a data declaration has to do with derived instances, and
is described in Section 4.3.3.

Labeled Fields A data constructor of arity k creates an object with k components. These
components are normally accessed positionally as arguments to the constructor in expres-
sions or patterns. For large datatypes it is useful to assign eld labels to the components
of a data object. This allows a specic eld to be referenced independently of its location
within the constructor.
A constructor denition in a data declaration using the { } syntax assigns labels to the
components of the constructor. Constructors using eld labels may be freely mixed with
constructors without them. A constructor with associated eld labels may still be used as
an ordinary constructor; features using labels are simply a shorthand for operations using
an underlying positional constructor. The arguments to the positional constructor occur in
the same order as the labeled elds. For example, the declaration
data C = F { f1,f2 :: Int, f3 :: Bool}

denes a type and constructor identical to the one produced by

data C = F Int Int Bool

Operations using eld labels are described in Section 3.15. A data declaration may use
the same eld label in multiple constructors as long as the typing of the eld is the same
in all cases after type synonym expansion. A label cannot be shared by more than one
type in scope. Field names share the top level namespace with ordinary variables and class
methods and must not con ict with other top level names in scope.

Strictness Flags Whenever a data constructor is applied, each argument to the construc-
tor is evaluated if and only if the corresponding type in the algebraic datatype declaration
has a strictness ag (!).
38 4. DECLARATIONS AND BINDINGS

Translation: A declaration of the form

data c => T u 1 : : : uk = : : : | K s 1 : : : sn | :::
where each si is either of the form !ti or ti , replaces every occurance of K in an
expression by
(\ x1 : : : x n -> ( ((K op1 x1 ) op2 x2 ) : : : ) opn xn )
where opi is the lazy apply function $ if si is of the form ti , and opi is the strict apply
function `strict` (see Section 6.2.7) if si is of the form ! ti . Pattern matching on K
is not aected by strictness ags.

Strictness ags may require the explicit inclusion of an Eval context in a data declaration
(see Section 6.2.7). This occurs precisely when the context of a strict function used in the
above translation propagates to a type variable. For example, in
data (Eval a) => Pair a b = MakePair !a b

the class assertion (Eval a) is required by the use of strict in the translation of the
constructor MakePair. This context must be explicitly supplied by the programmer. The
Eval context may be implied by a more general one; for example, the Num class includes
Eval as a superclass to avoid mentioning Eval in the following:

data (Integral a) => Rational a = !a :% !a -- Rational library

For some types, the Eval context may not be expressible (see Section 4.5.3. For example,
in
data T a b = T !(a b)

the context Eval (a b) would be required. Since this context is not legal, the strictness
ag cannot be used in this situation.

4.2.2 Type Synonym Declarations

topdecl ! type simpletype = type
simpletype ! tycon tyvar1 : : : tyvark (k  0 )

A type synonym declaration introduces a new type that is equivalent to an old type. It has
the form
type T u1 : : : uk = t

which introduces a new type constructor, T . The type (T t1 : : : tk ) is equivalent to the type
t [t1 =u1 ; : : :; tk =uk ]. The type variables u1 through uk must be distinct and are scoped
only over t ; it is a static error for any other type variable to appear in t . The kind of
the new type constructor T is of the form 1 ! : : : ! k !  where the kinds i of the
arguments ui and  of the right hand side t are determined by kind inference as described
4.2 User-Dened Datatypes 39

in Section 4.6. For example, the following denition can be used to provide an alternative
way of writing the list type constructor:
type List = []

Type constructor symbols T introduced by type synonym declarations cannot be partially

applied; it is a static error to use T without the full number of arguments.
Although recursive and mutually recursive datatypes are allowed, this is not so for type
synonyms, unless an algebraic datatype intervenes. For example,
type Rec a = [Circ a]
data Circ a = Tag [Rec a]
is allowed, whereas
type Rec a = [Circ a] -- invalid
type Circ a = [Rec a] --
is not. Similarly, type Rec a = [Rec a] is not allowed.
Type synonyms are a strictly syntactic mechanism to make type signatures more read-
able. A synonym and its denition are completely interchangeable.

4.2.3 Datatype Renamings

topdecl ! newtype [context =>] simpletype = con atype [deriving ]
simpletype ! tycon tyvar1 : : : tyvark (k  0 )

A declaration of the form

newtype c => T u1 : : : uk = Nt
introduces a new type whose representation is the same as an existing type. The type
( T u1 : : : uk ) renames the datatype t . It diers from a type synonym in that it creates
a distinct type that must be explicitly coerced to or from the original type. Also, unlike
type synonyms, newtype may be used to dene recursive types. The constructor N in an
expression coerces a value from type t to type ( T u1 : : : uk ). Using N in a pattern
coerces a value from type ( T u1 : : : uk ) to type t . These coercions may be implemented
without execution time overhead; newtype does not change the underlying representation
of an object.
New instances (see Section 4.3.2) can be dened for a type dened by newtype but may
not be dened for a type synonym. A type created by newtype diers from an algebraic
datatype in that the representation of an algebraic datatype has an extra level of indirection.
This dierence makes access to the representation less ecient. The dierence is re ected
in dierent rules for pattern matching (see Section 3.17). Unlike algebraic datatypes, the
newtype constructor N is unlifted, so that N ? is the same as ?.
The following examples clarify the dierences between data (algebraic datatypes), type
(type synonyms), and newtype (renaming types.) Given the declarations
40 4. DECLARATIONS AND BINDINGS

data D1 = D1 Int
data D2 = D2 !Int
type S = Int
newtype N = N Int
d1 (D1 i) = 42
d2 (D2 i) = 42
s i = 42
n (N i) = 42
the expressions ( d1 ? ), ( d2 ? ) and (d2 (D2 ? ) ) are all equivalent to ?, whereas
( n ? ), ( n ( N ? ) ), ( d1 ( D1 ? ) ) and ( s ? ) are all equivalent to 42. In partic-
ular, ( N ? ) is equivalent to ? while ( D1 ? ) is not equivalent to ?.
The optional deriving part of a newtype declaration is treated in the same way as the
deriving component of a data declaration; see Section 4.3.3.
Every type, both those declared by data and newtype, is made an instance of the Eval
class by an implicit derived instance declaration for Eval (see Section 6.2.7). It is as if there
was an implicit \deriving(Eval)" on every type declaration. For newtype, the instance
declaration has the form
instance CEval => Eval (T u1 : : : uk ) where
(N x) `seq` y = x `seq` y
where CEval is the context obtained by simplifying Eval t . For example, the declaration
newtype Age = MkAge Int

gives rise to the instance declaration

instance Eval Age where
(MkAge x) `seq` y = x `seq` y
since simplifying Eval Int yields the empty context. On the other hand,
newtype Id a = MkId a

gives rise to
instance Eval a => Eval (Id a) where
(MkId a) `seq` b = a `seq` b
This derived instance may lead to a context reduction error (see Section 4.5.3). A static
error occurs when it is not possible to nd CEval for a newtype declaration (just as with
other derived instances). For example
newtype T a = MkT (a Int)

is illegal, because one cannot reduce the context Eval (a Int). The derived Eval instance
for data declarations has an empty context and thus will never generate static errors. Types
that cannot be renamed by newtype due to this context problem are the same as those that
cannot be marked as strict in a data declaration (see Section 4.2.1).
4.3 Type Classes and Overloading 41

4.3 Type Classes and Overloading

4.3.1 Class Declarations
topdecl ! class [context =>] simpleclass [where { cbody [;] }]
cbody ! [ cmethods [ ; cdefaults ] ]
cmethods ! signdecl1 ; : : : ; signdecln (n  1 )
cdefaults ! valdef1 ; : : : ; valdefn (n  1 )

A class declaration introduces a new class and the operations (class methods) on it. A class
declaration has the general form:
class c => Cu where { v1 :: c1 => t1 ; : : : ; vn :: cn => tn ;
valdef1 ; : : : ; valdefm }
This introduces a new class name C ; the type variable u is scoped only over the class method
signatures in the class body. The context c species the superclasses of C , as described
below; the only type variable that may be referred to in c is u . The class declaration intro-
duces new class methods v1 ; : : :; vn , whose scope extends outside the class declaration,
with types:
vi :: 8u; w: (Cu; ci) ) ti
The ti must mention u ; they may mention type variables w other than u , and the type of
vi is polymorphic in both u and w . The ci may constrain only w ; in particular, the ci may
not constrain u . For example:
class Foo a where
op :: Num b => a -> b -> a
Here the type of op is 8 a ; b : (Foo a ; Num b ) ) a ! b ! a .
Default class methods for any of the vi may be included in the class declaration as a
normal valdef ; no other denitions are permitted. The default class method for vi is used
if no binding for it is given in a particular instance declaration (see Section 4.3.2).
Class methods share the top level namespace with variable bindings and eld names;
they must not con ict with other top level bindings in scope. That is, a class method can
not have the same name as a top level denition, a eld name, or another class method.
A class declaration with no where part may be useful for combining a collection of
classes into a larger one that inherits all of the class methods in the original ones. For
example:
class (Read a, Show a) => Textual a

In such a case, if a type is an instance of all superclasses, it is not automatically an instance

of the subclass, even though the subclass has no immediate class methods. The instance
declaration must be given explicitly with no where part.
The superclass relation must not be cyclic; i.e. it must form a directed acyclic graph.
42 4. DECLARATIONS AND BINDINGS

4.3.2 Instance Declarations

topdecl ! instance [context =>] qtycls inst [where { valdefs [;] }]
inst ! gtycon
j ( gtycon tyvar1 : : : tyvark ) (k  0 ; tyvars distinct)
j ( tyvar1 , : : : , tyvark ) (k  2 ; tyvars distinct)
j [ tyvar ]
j ( tyvar1 -> tyvar2 ) tyvar1 and tyvar2 distinct
valdefs ! valdef1 ; : : : ; valdefn (n  0 )
An instance declaration introduces an instance of a class. Let
class c => C u where { cbody }

be a class declaration. The general form of the corresponding instance declaration is:
instance c 0 => C (T u1 : : : uk ) where { d }

where k  0 and T is not a type synonym. The constructor being instanced, (T u1 : : : uk ),

is a type constructor applied to simple type variables u1 ; : : : uk , which must be distinct.
This prohibits instance declarations such as:
instance C (a,a) where ...
instance C (Int,a) where ...
instance C [[a]] where ...
The constructor (T u1 : : : uk ) must have an appropriate kind for the class C ; this can
be determined using kind inference as described in Section 4.6. The declarations d may
contain bindings only for the class methods of C . The declarations may not contain any
type signatures since the class method signatures have already been given in the class
declaration.
If no binding is given for some class method then the corresponding default class method
in the class declaration is used (if present); if such a default does not exist then the class
method of this instance is bound to undefined and no compile-time error results.
An instance declaration that makes the type T to be an instance of class C is called
a C-T instance declaration and is subject to these static restrictions:
 A type may not be declared as an instance of a particular class more than once in the
program.
 The class and type must have the same kind.
 Assume that the type variables in the instance type (T u1 : : : uk ) satisfy the con-
straints in the instance context c 0 . Under this assumption, the following two conditions
must also be satised:
1. The constraints expressed by the superclass context c [(T u1 : : : uk )=u ] of C
must be satised. In other words, T must be an instance of each of C 's super-
classes and the contexts of all superclass instances must be implied by c 0.
4.3 Type Classes and Overloading 43

2. Any constraints on the type variables in the instance type that are required for
the class method declarations in d to be well-typed must also be satised.
In fact, except in pathological cases it is possible to infer from the instance declaration
the most general instance context c 0 satisfying the above two constraints, but it is
nevertheless mandatory to write an explicit instance context.
The following illustrates the restrictions imposed by superclass instances:
class Foo a => Bar a where ...

instance (Eq a, Show a) => Foo [a] where ...

instance Num a => Bar [a] where ...
This is perfectly valid. Since Foo is a superclass of Bar, the second instance declaration
is only valid if [a] is an instance of Foo under the assumption Num a. The rst instance
declaration does indeed say that [a] is an instance of Foo under this assumption, because
Eq and Show are superclasses of Num.

If the two instance declarations instead read like this:

instance Num a => Foo [a] where ...
instance (Eq a, Show a) => Bar [a] where ...
then the program would be invalid. The second instance declaration is valid only if [a] is
an instance of Foo under the assumptions (Eq a, Show a). But this does not hold, since
[a] is only an instance of Foo under the stronger assumption Num a.

Further examples of instance declarations may be found in Appendix A.

4.3.3 Derived Instances

As mentioned in Section 4.2.1, data and newtype declarations contain an optional deriving
form. If the form is included, then derived instance declarations are automatically generated
for the datatype in each of the named classes. These instances are subject to the same
restrictions as user-dened instances. When deriving a class C for a type T , instances for
all superclasses of C must exist for T , either via an explicit instance declaration or by
including the superclass in the deriving clause.
Derived instances provide convenient commonly-used operations for user-dened data-
types. For example, derived instances for datatypes in the class Eq dene the operations ==
and /=, freeing the programmer from the need to dene them.
The only classes in the Prelude for which derived instances are allowed are Eq, Ord,
Enum, Bounded, Show, and Read, all dened in Figure 5, page 67. The precise details of how
the derived instances are generated for each of these classes are provided in Appendix D,
including a specication of when such derived instances are possible. Instances of class Eval
are always implicitly derived for algebraic datatypes. The class Eval may not be explicitly
listed in a deriving form or dened by an explicit instance declaration. Classes dened by
the standard libraries may also be derivable.
44 4. DECLARATIONS AND BINDINGS

A static error results if it is not possible to derive an instance declaration over a class
named in a deriving form. For example, not all datatypes can properly support class
methods in Enum. It is also a static error to give an explicit instance declaration for a class
that is also derived.
If the deriving form is omitted from a data or newtype declaration, then no instance
declarations (except for Eval) are derived for that datatype; that is, omitting a deriving
form is equivalent to including an empty deriving form: deriving ().

4.3.4 Defaults for Overloaded Numeric Operations

topdecl ! default (type1 , : : : , typen ) (n  0 )
A problem inherent with Haskell-style overloading is the possibility of an ambiguous type.
For example, using the read and show functions dened in Appendix D, and supposing that
just Int and Bool are members of Read and Show, then the expression
let x = read "..." in show x -- invalid
is ambiguous, because the types for show and read,
show :: 8 a : Show a ) a ! String
read :: 8 a : Read a ) String ! a

could be satised by instantiating a as either Int in both cases, or Bool. Such expressions
are considered ill-typed, a static error.
We say that an expression e is ambiguously overloaded if, in its type 8 u : c ) t , there
is a type variable u in u that occurs in c but not in t . Such types are invalid.
For example, the earlier expression involving show and read is ambiguously overloaded
since its type is 8 a : Show a ; Read a ) String.
Overloading ambiguity can only be circumvented by input from the user. One way is
through the use of expression type-signatures as described in Section 3.16. For example, for
the ambiguous expression given earlier, one could write:
let x = read "..." in show (x::Bool)
which disambiguates the type.
Occasionally, an otherwise ambiguous expression needs to be made the same type as
some variable, rather than being given a xed type with an expression type-signature. This
is the purpose of the function asTypeOf (Appendix A): x `asTypeOf` y has the value of
x , but x and y are forced to have the same type. For example,
approxSqrt x = encodeFloat 1 (exponent x `div` 2) `asTypeOf` x
(See Section 6.3.6.)
Ambiguities in the class Num are most common, so Haskell provides another way to
resolve them|with a default declaration:
default (t1 , : : : , tn )
4.4 Nested Declarations 45

where n  0 , and each ti must be a monotype for which Num ti holds. In situations where an
ambiguous type is discovered, an ambiguous type variable is defaultable if at least one of its
classes is a numeric class (that is, Num or a subclass of Num) and if all of its classes are dened
in the Prelude or a standard library (Figures 6{7, pages 74{75 show the numeric classes,
and Figure 5, page 67, shows the classes dened in the Prelude.) Each defaultable variable
is replaced by the rst type in the default list that is an instance of all the ambiguous
variable's classes. It is a static error if no such type is found.
Only one default declaration is permitted per module, and its eect is limited to that
module. If no default declaration is given in a module then it assumed to be:
default (Int, Double)

The empty default declaration default () must be given to turn o all defaults in a module.

4.4 Nested Declarations

The following declarations may be used in any declaration list, including the top level of a
module.

4.4.1 Type Signatures

signdecl ! vars :: [context =>] type
A type signature species types for variables, possibly with respect to a context. A type
signature has the form:
v1 ; : : :; vn :: c => t
which is equivalent to asserting vi :: c => t for each i from 1 to n . Each vi must have a
value binding in the same declaration list that contains the type signature; i.e. it is invalid
to give a type signature for a variable bound in an outer scope. Moreover, it is invalid to
give more than one type signature for one variable.
As mentioned in Section 4.1.1, every type variable appearing in a signature is universally
quantied over that signature, and hence the scope of a type variable is limited to the type
signature that contains it. For example, in the following declarations
f :: a -> a
f x = x :: a -- invalid
the a's in the two type signatures are quite distinct. Indeed, these declarations contain a
static error, since x does not have type 8 a : a . (The type of x is dependent on the type of
f; there is currently no way in Haskell to specify a signature for a variable with a dependent
type; this is explained in Section 4.5.4.)
If a given program includes a signature for a variable f , then each use of f is treated as
having the declared type. It is a static error if the same type cannot also be inferred for
the dening occurrence of f .
46 4. DECLARATIONS AND BINDINGS

If a variable f is dened without providing a corresponding type signature declaration,

then each use of f outside its own declaration group (see Section 4.5) is treated as having
the corresponding inferred, or principal type . However, to ensure that type inference is still
possible, the dening occurrence, and all uses of f within its declaration group must have
the same monomorphic type (from which the principal type is obtained by generalization,
as described in Section 4.5.2).
For example, if we dene
sqr x = x*x
then the principal type is sqr :: 8 a : Num a ) a ! a , which allows applications such
as sqr 5 or sqr 0.1. It is also valid to declare a more specic type, such as
sqr :: Int -> Int
but now applications such as sqr 0.1 are invalid. Type signatures such as
sqr :: (Num a, Num b) => a -> b -- invalid
sqr :: a -> a -- invalid
are invalid, as they are more general than the principal type of sqr.
Type signatures can also be used to support polymorphic recursion. The following
denition is pathological, but illustrates how a type signature can be used to specify a type
more general than the one that would be inferred:
data T a = K (T Int) (T a)
f :: T a -> a
f (K x y) = if f x == 1 then f y else undefined
If we remove the signature declaration, the type of f will be inferred as T Int -> Int due
to the rst recursive call for which the argument to f is T Int. Polymorphic recursion
allows the user to supply the more general type signature, T a -> a.

4.4.2 Function and Pattern Bindings

decl ! valdef
valdef ! lhs = exp [where decllist ]
j lhs gdrhs [where decllist ]
lhs ! pat 0
j funlhs
funlhs ! var apat f apat g
j pat i +1 varop (a ;i ) pat i +1
j lpat i varop ( l;i ) pat i +1
j pat i +1 varop ( r;i ) rpat i
gdrhs ! gd = exp [gdrhs ]
4.4 Nested Declarations 47

gd ! | exp 0

We distinguish two cases within this syntax: a pattern binding occurs when lhs is pat ;
otherwise, the binding is called a function binding. Either binding may appear at the
top-level of a module or within a where or let construct.

Function bindings. A function binding binds a variable to a function value. The general
form of a function binding for variable x is:
x p11 : : : p1k match1
:::
x pn1 : : : pnk matchn
where each pij is a pattern, and where each matchi is of the general form:
= ei where { declsi }

or
| gi1 = ei1
:::
| gimi = eimi
declsi }
where {
and where n  1 , 1  i  n , mi  1 . The former is treated as shorthand for a particular
case of the latter, namely:
| True = ei where { declsi }

Note that all clauses dening a function must be contiguous, and the number of patterns
in each clause must be the same. The set of patterns corresponding to each match must be
linear|no variable is allowed to appear more than once in the entire set.
Alternative syntax is provided for binding functional values to inx operators. For
example, these two function denitions are equivalent:
plus x y z = x+y+z
x plus y = \ z -> x+y+z

Translation: The general binding form for functions is semantically equivalent to the
equation (i.e. simple pattern binding):
x x1 x2 ::: xk = case ( x1 , :::, xk ) of (p11 ; : : :; p1k ) match1
:::
(pm1 ; : : :; pmk ) matchm
where the xi are new identiers.
48 4. DECLARATIONS AND BINDINGS

Pattern bindings. A pattern binding binds variables to values. A simple pattern binding
has form p = e . The pattern p is matched \lazily" as an irrefutable pattern, as if there
were an implicit ~ in front of it. See the translation in Section 3.12.
The general form of a pattern binding is p match , where a match is the same structure
as for function bindings above; in other words, a pattern binding is:
p | g1 = e1
| g2 = e 2
:::
| gm = e m
where { decls }

Translation: The pattern binding above is semantically equivalent to this simple

pattern binding:
p = let decls in
if g1 then e1 else
if g2 then e2 else
:::
if gm then em else error "Unmatched pattern"

4.5 Static Semantics of Function and Pattern Bindings

The static semantics of the function and pattern bindings of a let expression or where
clause are discussed in this section.

4.5.1 Dependency Analysis

In general the static semantics are given by the normal Hindley-Milner inference rules.
A dependency analysis transformation is rst performed to enhance polymorphism. Two
variables bound by value declarations are in the same declaration group if either
1. they are bound by the same pattern binding, or
2. their bindings are mutually recursive (perhaps via some other declarations that are
also part of the group).
Application of the following rules causes each let or where construct (including the where
dening the top level bindings in a module) to bind only the variables of a single declaration
group, thus capturing the required dependency analysis:2
1. The order of declarations in where/let constructs is irrelevant.
2. let {d1 ; d2 } in e = let {d1 } in (let {d2 } in e )
(when no identier bound in d2 appears free in d1 )
2
A similar transformation is described in Peyton Jones' book [9].
4.5 Static Semantics of Function and Pattern Bindings 49

4.5.2 Generalization
The Hindley-Milner type system assigns types to a let-expression in two stages. First, the
right-hand side of the declaration is typed, giving a type with no universal quantication.
Second, all type variables that occur in this type are universally quantied unless they
are associated with bound variables in the type environment; this is called generalization.
Finally, the body of the let-expression is typed.
For example, consider the declaration
f x = let g y = (y,y)
in ...

The type of g's denition is a ! (a ; a ). The generalization step attributes to g the poly-
morphic type 8 a : a ! (a ; a ), after which the typing of the \..." part can proceed.
When typing overloaded denitions, all the overloading constraints from a single dec-
laration group are collected together, to form the context for the type of each variable
declared in the group. For example, in the denition:
f x = let g1 x y = if x>y then show x else g2 y x
g2 p q = g1 q p
in ...
The types of the denitions of g1 and g2 are both a ! a ! String, and the accumulated
constraints are Ord a (arising from the use of >), and Show a (arising from the use of show).
The type variables appearing in this collection of constraints are called the constrained type
variables.
The generalization step attributes to both g1 and g2 the type
8 a : (Ord a ; Show a) ) a ! a ! String

Notice that g2 is overloaded in the same way as g1 even though the occurrences of > and
show are in the denition of g1.

If the programmer supplies explicit type signatures for more than one variable in a
declaration group, the contexts of these signatures must be identical up to renaming of the
type variables.

4.5.3 Context Reduction Errors

As mentioned in Section 4.1.3, the context of a type may constrain only type variables.
Hence, types produced by generalization must be expressed in a form in which all context
constraints have be reduced to apply only to type variables. Consider, for example, the
denition:
f xs y = xs == [y]

Its type is given by

50 4. DECLARATIONS AND BINDINGS

f :: Eq a => [a] -> a -> Bool

and not
f :: Eq [a] => [a] -> a -> Bool

Even though the equality is taken at the list type, the context must be simplied, using the
instance declaration for Eq on lists, before generalization. If no such instance is in scope, a
static error occurs.
The context may also fail to simplify, leading to a static error, because it contains a
constraint of the form C (m t ) where m is one of the the type variable being generalized.
That is, the class C applies to a type expression that is not a type variable or a type
constructor. For example:, the
f x = show (return x)

The type of return is Monad m => a -> m a; the type of show is Show a => a -> String.
The type of f should be (Monad m, Show (m a)) => a -> String. The context to be
simplied will therefore be (Monad m, Show (m a)), which cannot be further reduced,
resulting in a static error.
Code generated by derived instance functions (see Section 4.3.3) may lead to general-
ization errors. For example, in the type
data Apply a b = App (a b) deriving Show

the derived Show instance will produce a context Show (a b), which cannot be reduced and
thus results in a static error. Context reduction error may also arise from strictness ags in
data declarations (see Section 4.2.1) and the implicitly derived Eval instance in newtype
declarations (see Section 4.2.3).

4.5.4 Monomorphism
Sometimes it is not possible to generalize over all the type variables used in the type of the
denition. For example, consider the declaration
f x = let g y z = ([x,y], z)
in ...
In an environment where x has type a , the type of g's denition is a ! b ! ([a ]; b ).
The generalization step attributes to g the type 8 b : a ! b ! ([a ]; b ); only b can be
universally quantied because a occurs in the type environment. We say that the type of g
is monomorphic in the type variable a .
The eect of such monomorphism is that the rst argument of all applications of g must
be of a single type. For example, it would be valid for the \..." to be
(g True, g False)

(which would, incidentally, force x to have type Bool) but invalid for it to be
(g True, g 'c')
4.5 Static Semantics of Function and Pattern Bindings 51

In general, a type 8 u : c ) t is said to be monomorphic in the type variable a if a is free

in 8 u : c ) t .
It is worth noting that the explicit type signatures provided by Haskell are not powerful
enough to express types that include monomorphic type variables. For example, we cannot
write
f x = let
g :: a -> b -> ([a],b)
g y z = ([x,y], z)
in ...
because that would claim that g was polymorphic in both a and b (Section 4.4.1). In this
program, g can only be given a type signature if its rst argument is restricted to a type
not involving type variables; for example
g :: Int -> b -> ([Int],b)

This signature would also cause x to have type Int.

4.5.5 The Monomorphism Restriction

Haskell places certain extra restrictions on the generalization step, beyond the standard
Hindley-Milner restriction described above, which further reduces polymorphism in partic-
ular cases.
The monomorphism restriction depends on the binding syntax of a variable. Recall that
a variable is bound by either a function binding or a pattern binding, and that a simple
pattern binding is a pattern binding in which the pattern consists of only a single variable
(Section 4.4.2).
Two rules dene the monomorphism restriction:
Rule 1. We say that a given declaration group is unrestricted if and only if:
(a): every variable in the group is bound by a function binding or a simple pattern
binding, and
(b): an explicit type signature is given for every variable in the group that is bound
by simple pattern binding.
The usual Hindley-Milner restriction on polymorphism is that only type variables free
in the environment may be generalized. In addition, the constrained type variables
of a restricted declaration group may not be generalized in the generalization step for
that group. (Recall that a type variable is constrained if it must belong to some type
class; see Section 4.5.2.)
Rule 2. The type of a variable exported from a module must be completely polymorphic;
that is, it must not have any free type variables. It follows from Rule 1 that if all
top-level declaration groups are unrestricted, then Rule 2 is automatically satised.
52 4. DECLARATIONS AND BINDINGS

Rule 1 is required for two reasons, both of which are fairly subtle. First, it prevents com-
putations from being unexpectedly repeated. For example, genericLength is a standard
function (in library List) whose type is given by
genericLength :: Num a => [b] -> a
Now consider the following expression:
let { len = genericLength xs } in (len, len)
It looks as if len should be computed only once, but without Rule 1 it might be computed
twice, once at each of two dierent overloadings. If the programmer does actually wish the
computation to be repeated, an explicit type signature may be added:
let { len :: Num a => a; len = genericLength xs } in (len, len)
When non-simple pattern bindings are used, the types inferred are always monomorphic in
their constrained type variables, irrespective of whether a type signature is provided. For
example, in
(f,g) = ((+),(-))
both f and g are monomorphic regardless of any type signatures supplied for f or g.
Rule 1 also prevents ambiguity. For example, consider the declaration group
[(n,s)] = reads t
Recall that reads is a standard function whose type is given by the signature
reads :: (Read a) => String -> [(a,String)]
Without Rule 1, n would be assigned the type 8 a : Read a ) a and s the type 8 a :
Read a ) String. The latter is an invalid type, because it is inherently ambiguous. It is
not possible to determine at what overloading to use s. Rule 1 makes n and s monomorphic
in a .
Lastly, Rule 2 is required because there is no way to enforce monomorphic use of an
exported binding, except by performing type inference on modules outside the current
module. Exported variables are handled in the same way as non-exported ones even though
their usage outside the module could theoreticly be used to determine monomorphic type.
For example, in the program
module M(x) where
x = 1
the monomorphism restriction prevents the type of x from being generalized to Num a => a.
Since references to x outside module M cannot be used to determine the type of x, the
defaulting rule (see Section 4.3.4) assigns the type Int to x.
The monomorphism rule has a number of consequences for the programmer. Anything
dened with function syntax usually generalizes as a function is expected to. Thus in
f x y = x+y
the function f may be used at any overloading in class Num. There is no danger of recom-
putation here. However, the same function dened with pattern syntax:
4.6 Kind Inference 53

f = \x -> \y -> x+y

requires a type signature if f is to be fully overloaded. Many functions are most naturally
dened using simple pattern bindings; the user must be careful to ax these with type
signatures to retain full overloading. The standard prelude contains many examples of this:
sum :: (Num a) => [a] -> a
sum = foldl (+) 0

4.6 Kind Inference

This section describes the rules that are used to perform kind inference, i.e. to calculate a
suitable kind for each type constructor and class appearing in a given program.
The rst step in the kind inference process is to arrange the set of datatype, synonym,
and class denitions into dependency groups. This can be achieved in much the same way
as the dependency analysis for value declarations that was described in Section 4.5. For
example, the following program fragment includes the denition of a datatype constructor
D, a synonym S and a class C, all of which would be included in the same dependency group:
data C a => D a = Foo (S a)
type S a = [D a]
class C a where
bar :: a -> D a -> Bool
The kinds of variables, constructors, and classes within each group are determined using
standard techniques of type inference and kind-preserving unication [6]. For example, in
the denitions above, the parameter a appears as an argument of the function constructor
(->) in the type of bar and hence must have kind . It follows that both D and S must
have kind  !  and that every instance of class C must have kind .
It is possible that some parts of an inferred kind may not be fully determined by the
corresponding denitions; in such cases, a default of  is assumed. For example, we could
assume an arbitrary kind  for the a parameter in each of the following examples:
data App f a = A (f a)
data Tree a = Leaf | Fork (Tree a) (Tree a)

This would give kinds ( ! ) !  !  and  !  for App and Tree, respectively, for
any kind , and would require an extension to allow polymorphic kinds. Instead, using the
default binding  = , the actual kinds for these two constructors are ( ! ) !  !  and
 ! , respectively.
Defaults are applied to each dependency group without consideration of the ways in
which particular type constructor constants or classes are used in later dependency groups
or elsewhere in the program. For example, adding the following denition to those above
do not in uence the kind inferred for Tree (by changing it to ( ! ) ! , for instance),
and instead generates a static error because the kind of [],  ! , does not match the kind
 that is expected for an argument of Tree:
54 4. DECLARATIONS AND BINDINGS

type FunnyTree = Tree [] -- invalid

This is important because it ensures that each constructor and class are used consistently
with the same kind whenever they are in scope.
 55

5 Modules
A module denes a collection of values, datatypes, type synonyms, classes, etc. (see Sec-
tion 4) in an environment created by a set of imports, resources brought into scope from
other modules, and exports some of these resources, making them available to other mod-
ules. We use the term entity to refer to a value, type, or classes dened in, imported into,
or perhaps exported from a module.
A Haskell program is a collection of modules, one of which, by convention, must be
called Main and must export the value main. The value of the program is the value of the
identier main in module Main, and main must have type IO () (see Section 7).
Modules may reference other modules via explicit import declarations, each giving the
name of a module to be imported and specifying its entities to be imported. Modules may
be mutually recursive.
The name-space for modules is at, with each module being associated with a unique
module name (which are Haskell identiers beginning with a capital letter; i.e. modid ).
There is one distinguished module, Prelude, which is imported into all programs by default
(see Section 5.3), plus a set of standard library modules that may be imported as required
(see the Haskell Library Report[8]).

5.1 Module Structure

A module denes a mutually recursive scope containing declarations for value bindings,
data types, type synonyms, classes, etc. (see Section 4).
module ! module modid [exports ] where body
j body
body ! { [impdecls ;] [[xdecls ;] topdecls [;]] }
j { impdecls [;] }
modid ! conid
impdecls ! impdecl1 ; : : : ; impdecln (n  1 )
topdecls ! topdecl1 ; : : : ; topdecln (n  0 )
A module begins with a header: the keyword module, the module name, and a list
of entities (enclosed in round parentheses) to be exported. The header is followed by
an optional list of import declarations that specify modules to be imported, optionally
restricting the imported bindings. This is followed by an optional list of xity declarations
and the module body. The module body is simply a list of top-level declarations (topdecls ),
as described in Section 4.
An abbreviated form of module, consisting only of the module body, is permitted. If
this is used, the header is assumed to be `module Main(main) where'. If the rst lexeme
in the abbreviated module is not a {, then the layout rule applies for the top level of the
module.
56 5. MODULES

5.1.1 Export Lists

exports ! ( export1 , : : : , exportn [ , ] ) (n  0 )
export ! qvar
j qtycon [(..) j ( qcname1 , : : : , qcnamen )] (n  0 )
j qtycls [(..) j ( qvar1 , : : : , qvarn )] (n  0 )
j module modid
qcname ! qvar j qcon
An export list identies the entities to be exported by a module declaration. A module
implementation may only export an entity that it declares, or that it imports from some
other module. If the export list is omitted, all values, types and classes dened in the
module are exported, but not those that are imported.
Entities in an export list may be named as follows:
1. A value, eld name, or class method, whether declared in the module body or im-
ported, may be named by giving the name of the value as a qvarid . Operators should
be enclosed in parentheses to turn them into qvarid 's.
2. An algebraic datatype T declared by a data or newtype declaration may be named
in one of three ways:
 The form T names the type but not the constructors or eld names. The ability
to export a type without its constructors allows the construction of abstract
datatypes (see Section 5.5).
 The form T (qcname1, : : : ,qcnamen ), where the qcnamei name only construc-
tors and eld names in T , names the type and some or all of its constructors and
eld names. The qcnamei must not contain duplications.
 The abbreviated form T (..) names the type and all its constructors and eld
names that are currently in scope (whether qualied or not).
Data constructors cannot be named in export lists in any other way.
3. A type synonym T declared by a type declaration may be named by the form T .
4. A class C with operations f1 ; : : :; fn declared in a class declaration may be named
in one of three ways:
 The form C names the class but not the class methods.
 The form C (f1, : : : ,fn), where the fi must be class methods C , names the class
and some or all of its methods. The fi must not contain duplications.
 The abbreviated form C (..) names the class and all its methods that are in
scope (whether qualied or not).
5.1 Module Structure 57

5. The set of all entities brought into scope from a module m by one or more unqualied
import declarations may be named by the form `module m ', which is equivalent to
listing all of the entities imported from the module. For example:
module Queue( module Stack, enqueue, dequeue ) where
import Stack
...
Here the module Queue uses the module name Stack in its export list to abbreviate
all the entities imported from Stack.
6. A module can name its own local denitions in its export list using its name in the
`module m' syntax. For example:
module Mod1(module Mod1, module Mod2) where
import Mod2
import Mod3
Here module Mod1 exports all local denitions as well as those imported from Mod2
but not those imported from Mod3. Note that module M where is the same as using
module M(module M) where.

The qualier (see Section 5.1.2) on a name only identies the module an entity is imported
from; this may be dierent from the module in which the entity is dened. For example, if
module A exports B.c, this is referenced as `A.c', not `A.B.c'. In consequence, names in
export lists must remain distinct after qualiers are removed. For example:
module A ( B.f, C.f, g, B.g ) where -- an invalid module
import qualified B(f,g)
import qualified C(f)
g = True
There are name clashes in the export list between B.f and C.f and between g and B.g even
though there are no name clashes within module A.

5.1.2 Import Declarations

impdecl ! import [qualified] modid [as modid ] [impspec ]
impspec ! ( import1 , : : : , importn [ , ] ) (n  0 )
j hiding ( import1 , : : : , importn [ , ] ) (n  0 )
import ! var
j tycon [ (..) j ( cname1 , : : : , cnamen )] (n  1 )
j tycls [(..) j ( var1 , : : : , varn )] (n  0 )
cname ! var j con

The entities exported by a module may be brought into scope in another module with
an import declaration at the beginning of the module. The import declaration names the
module to be imported and optionally species the entities to be imported. A single module
58 5. MODULES

may be imported by more than one import declaration. Imported names serve as top level
declarations: they scope over the entire body of the module but may be shadowed by local
non-top-level bindings. The eect of multiple import declarations is cumulative: an entity
is in scope if it is named by any of the import declarations in a module. The ordering of
imports is irrelevant.
Exactly which entities are to be imported can be specied in one of three ways:
1. The imported entities can be specied explicitly by listing them in parentheses. Items
in the list have the same form as those in export lists, except qualiers are not permit-
ted and the `module modid ' entity is not permitted. When the (..) form of import
is used for a type or class, the (..) refers to all of the constructors, methods, or eld
names exported from the module.
The list must name only entities exported by the imported module. The list may be
empty, in which case nothing except the instances are imported.
2. Entities can be excluded by using the form hiding(import1 , : : : , importn ), which
species that all entities exported by the named module should imported except for
those named in the list. Data constructors may be named directly in hiding lists
without being prexed by the associated type. Thus, in
import M hiding (C)
any constructor, class, or type named C is excluded. In contrast, using C in an import
list names only a class or type. The hiding clause only applies to unqualied names.
In the previous example, the name M.C is brought into scope. A hiding clause has no
eect in an import qualified declaration.
The eect of multiple import declarations is strictly cumulative: hiding an entity
on one import declaration does not prevent the same entity from being imported by
another import from the same module.
3. Finally, if impspec is omitted then all the entities exported by the specied module
are imported.
When an import declaration uses the qualified keyword, the names brought into scope
must be prexed by the name of the imported module (or a local alias, if an as clause is
present). A qualied name is written as modid .name . This allows full programmer control
of the unqualied namespace: a locally dened entity can share the same name as a qualied
import:
module Ring where
import qualified Prelude -- All Prelude names must be qualified
l1 + l2 = l1 ++ l2 -- This + differs from the one in the Prelude
l1 * l2 = nub (l1 + l2)

succ = (Prelude.+ 1)
The qualier does not change the syntactic treatment of a name: Prelude.+ is an inx
operator with the same xity as the denition of + in the Prelude. Qualiers may be
5.1 Module Structure 59

applied to names imported by an unqualied import; this allows a qualied import to be

replaced with an unqualied one without forcing changes in the references to the imported
names.
Imported modules may be assigned a local alias in the importing module using the as
clause. For example, in
import qualified Complex as C
entities must be referenced using `C.' as a qualier instead of `Complex.'. This also allows
a dierent module to be substituted for Complex without changing the qualiers used for
the imported module. It is an error for more than one module in scope to use the same
qualier. Qualiers can only be used for imported entities: locally dened names within a
module may not include a qualier unless the module explicitly imports itself.
Since qualier names are part of the lexical syntax, no spaces are allowed between the
qualier and the name. Sample parses are shown below.
This Lexes as this
f.g f . g (three tokens)
F.g F.g (qualied `g')
f.. f .. (two tokens)
F.. F.. (qualied `.')
F. F . (two tokens)

It may be that a particular entity is imported into a module by more than one route
| for example, because it is exported by two modules, both of which are imported by a
third module. Benign name clashes of this form are allowed, but it is a static error for two
dierent entities to have the same name. When two entities have the same name, they are
considered to be the same object if and only if they are dened by the same module. Two
dierent qualied names may refer to the same entity; the name of the importing module
does not aect the identity of an entity.
It is an error for two dierent entities to have the same name. This is valid:
module A
import B(f)
import qualified C(f)
as long as only one imported f is unqualied and f is not dened at the top level of A.
Qualiers are the only way to resolve name clashes between imported entities.

5.1.3 Importing and Exporting Instance Declarations

Instance declarations cannot be explicitly named on import or export lists. All instances
in scope within a module are always exported and any import brings all instances in from
the imported module. Thus, an instance declaration is in scope if and only if a chain of
import declarations leads to the module containing the instance declaration. For example,
import M() would not bring any new names in scope from module M, but would bring in
any instance visible in M.
60 5. MODULES

5.2 Closure
Every module in a Haskell program must be closed. That is, every name explicitly mentioned
by the source code must be either dened locally or imported from another module. Entities
that the compiler requires for type checking or other compile time analysis need not be
imported if they are not mentioned by name. The Haskell compilation system is responsible
for nding any information needed for compilation without the help of the programmer.
That is, the import of a variable x does not require that the datatypes and classes in the
signature of x be brought into the module along with x unless these entities are referenced
by name in the user program. The Haskell system silently imports any information that
must accompany an entity for type checking or any other purposes. Such entities need not
even be explicitly exported: the following program is valid even though T does not escape
M1:
module M1(x) where
data T = T
x = T
module M2 where
import M1(x)
y = x
In this example, there is no way to supply an explicit type signature for y since T is not
in scope. Whether or not T is explicitly exported, module M2 knows enough about T to
correctly type check the program.
The type of an exported entity is unaected by non-exported type synonyms. For
example, in
module M(x) where
type T = Int
x :: T
x = 1
the type of x is both T and Int; these are interchangeable even when T is not in scope. That
is, the denition of T is available to any module that encounters it whether or not the name
T is in scope. The only reason to export T is to allow other modules to refer it by name;
the type checker nds the denition of T if needed whether or not it is exported.

5.3 Standard Prelude

Many of the features of Haskell are dened in Haskell itself as a library of standard da-
tatypes, classes, and functions, called the \Standard Prelude." In Haskell, the Prelude is
contained in the the module Prelude. There are also many predened library modules,
which provide less frequently used functions and types. For example, arrays, tables, and
most of the input/output are all part of the standard libraries. These are dened in the
Haskell Library Report[8], a separate document. Separating libraries from the Prelude has
the advantage of reducing the size and complexity of the Prelude, allowing it to be more
easily assimilated, and increasing the space of useful names available to the programmer.
5.3 Standard Prelude 61

Prelude and library modules dier from other modules in that their semantics (but not
their implementation) are a xed part of the Haskell language denition. This means, for
example, that a compiler may optimize calls to functions in the Prelude without being
concerned that a future change to the program will alter the semantics of the Prelude
function.

5.3.1 The Prelude Module

The Prelude module is imported automatically into all modules as if by the statement
`import Prelude', if and only if it is not imported with an explicit import declaration.
This provision for explicit import allows values dened in the Prelude to be hidden from
the unqualied name space. The Prelude module is always available as a qualied import:
an implicit `import qualified Prelude' is part of every module and names prexed by
`Prelude.' can always be used to refer to entities in the Prelude.
The semantics of the entities in Prelude is specied by an implementation of Prelude
written in Haskell, given in Appendix A. Some datatypes (such as Int) and functions
(such as Int addition) cannot be specied directly in Haskell. Since the treatment of such
entities depends on the implementation, they are not formally dened in the appendix. The
implementation of Prelude is also incomplete in its treatment of tuples: there should be an
innite family of tuples and their instance declarations, but the implementation only gives
a scheme.

5.3.2 Shadowing Prelude Names

The rules about the Prelude have been cast so that it is possible to use Prelude names for
nonstandard purposes; however, every module that does so must have an import declaration
that makes this nonstandard usage explicit. For example:
module A where
import Prelude hiding (null)
null x = []
Module A redenes null, but it must indicate this by importing Prelude without null.
Furthermore, A exports null, but every module that imports null unqualied from A must
also hide null from Prelude just as A does. Thus there is little danger of accidentally
shadowing Prelude names.
It is possible to construct and use a dierent module to serve in place of the Prelude.
Other than the fact that it is implicitly imported, the Prelude is an ordinary Haskell module;
it is special only in that some objects in the Prelude are referenced by special syntactic
constructs. Redening names used by the Prelude does not aect the meaning of these
special constructs. For example, in
module B where
import qualified Prelude
import MyPrelude
...
62 5. MODULES

B imports nothing from Prelude, but the explicit import qualified Prelude declaration
prevents the automatic import of Prelude. import MyPrelude brings the non-standard
prelude into scope. As before, the standard prelude names are hidden explicitly. Special
syntax, such as lists or tuples, always refers to prelude entities: there is no way to redene
the meaning of [x] in terms of a dierent implementation of lists.

5.4 Separate Compilation

Depending on the Haskell implementation used, separate compilation of mutually recursive
modules may require that imported modules contain additional information so that they
may be referenced before they are compiled. Explicit type signatures for all exported values
may be necessary to deal with mutual recursion. The precise details of separate compilation
are not dened by this report.

5.5 Abstract Datatypes

The ability to export a datatype without its constructors allows the construction of abstract
datatypes (ADTs). For example, an ADT for stacks could be dened as:
module Stack( StkType, push, pop, empty ) where
data StkType a = EmptyStk | Stk a (StkType a)
push x s = Stk x s
pop (Stk _ s) = s
empty = EmptyStk
Modules importing Stack cannot construct values of type StkType because they do not
have access to the constructors of the type.
It is also possible to build an ADT on top of an existing type by using a newtype
declaration. For example, stacks can be dened with lists:
module Stack( StkType, push, pop, empty ) where
newtype StkType a = Stk [a]
push x (Stk s) = Stk (x:s)
pop (Stk (x:s)) = Stk s
empty = Stk []

5.6 Fixity Declarations

xdecls ! x1 ; : : : ; xn (n  1 )
x ! infixl [digit ] ops
j infixr [digit ] ops
j infix [digit ] ops
ops ! op1 , : : : , opn (n  1 )
op ! varop j conop
5.6 Fixity Declarations 63

A xity declaration gives the xity and binding precedence of a set of operators. Fixity
declarations must appear only at the start of a module and may only be given for identiers
dened in that module. Fixity declarations cannot subsequently be overridden, and an
identier can only have one xity denition.
There are three kinds of xity, non-, left- and right-associativity (infix, infixl, and
infixr, respectively), and ten precedence levels, 0 to 9 inclusive (level 0 binds least tightly,
and level 9 binds most tightly). If the digit is omitted, level 9 is assumed. Any operator
lacking a xity declaration is assumed to be infixl 9 (See Section 3 for more on the use of
xities). Table 2 lists the xities and precedences of the operators dened in the Prelude.

Prec- Left associative Non-associative Right associative

edence operators operators operators
9 !! .
8 ^, ^^, **
7 *, /, `div`,
`mod`, `rem`, `quot`
6 +, -
5 \\ :, ++
4 ==, /=, <, <=, >, >=,
`elem`, `notElem`
3 &&
2 ||
1 >>, >>=
0 $, `seq`

Table 2: Precedences and xities of prelude operators

Fixity is a property of the name of an identier or operator: the same xity attaches to
every occurrence of an operator name in a module, whether at the top level or rebound at
an inner level. For example:
module Foo
import Bar
infix 3 `op`

f x = ... where p `op` q = ...

Here `op` has xity 3 wherever it is in scope, provided Bar does not export the identier
op. If Bar does export op, then the example becomes invalid, because the xity (or lack
thereof) of op is dened in Bar (or wherever Bar imported op from). If op is imported as
a qualied name from Bar, no con ict may occur: the xity of a qualied name does not
aect unqualied uses of the same name.
64 6. PREDEFINED TYPES AND CLASSES

6 Predened Types and Classes

The Haskell Prelude contains predened classes, types, and functions that are implicitly
imported into every Haskell program. In this section, we describe the types and classes
found in the Prelude. Most functions are not described in detail here as they can easily be
understood from their denitions as given in Appendix A. Other predened types such as
arrays, complex numbers, and rationals are dened in the Haskell Library Report.

6.1 Standard Haskell Types

These types are dened by the Haskell Prelude. Numeric types are described in Section
6.3. When appropriate, the Haskell denition of the type is given. Some denitions may
not be completely valid on syntactic grounds but they faithfully convey the meaning of the
underlying type.

6.1.1 Booleans
data Bool = False | True deriving
(Read, Show, Eq, Ord, Enum, Bounded)
The boolean type Bool is an enumeration. The basic boolean functions are && (and), ||
(or), and not. The name otherwise is dened as True to make guarded expressions more
readable.

6.1.2 Characters and Strings

The character type Char is an enumeration and consists of 16 bit values, conforming to
the Unicode standard [10]. The lexical syntax for characters is dened in Section 2.5;
character literals are nullary constructors in the datatype Char. Type Char is an instance
of the classes Read, Show, Eq, Ord, Enum, and Bounded. The toEnum and fromEnum functions,
standard functions over bounded enumerations, map characters onto Int values in the range
[ 0 ; 2 16 ? 1 ].
Note that ASCII control characters each have several representations in character liter-
als: numeric escapes, ASCII mnemonic escapes, and the \^X notation. In addition, there
are the following equivalences: \a and \BEL, \b and \BS, \f and \FF, \r and \CR, \t and
\HT, \v and \VT, and \n and \LF.

A string is a list of characters:

type String = [Char]

Strings may be abbreviated using the lexical syntax described in Section 2.5. For example,
"A string" abbreviates
[ 'A',' ','s','t','r', 'i','n','g']
6.1 Standard Haskell Types 65

6.1.3 Lists
data [a] = [] | a : [a] deriving (Eq, Ord)

Lists are an algebraic datatype of two constructors, although with special syntax, as de-
scribed in Section 3.7. The rst constructor is the null list, written `[]' (\nil"), and the
second is `:' (\cons"). The module PreludeList (see Appendix A.1) denes many standard
list functions. Arithmetic sequences and list comprehensions, two convenient syntaxes for
special kinds of lists, are described in Sections 3.10 and 3.11, respectively. Lists are an
instance of classes Read, Show, Eq, Ord, Monad, MonadZero, and MonadPlus.

6.1.4 Tuples
Tuples are algebraic datatypes with special syntax, as dened in Section 3.8. Each tuple
type has a single constructor. There is no upper bound on the size of a tuple. However, some
Haskell implementations may restrict the size of tuples and limit the instances associated
with larger tuples. The Prelude and libraries dene tuple functions such as zip for tuples
up to a size of 7. All tuples are instances of Eq, Ord, Bounded, Read, and Show. Classes
dened in the libraries may also supply instances for tuple types. The constructor for a tuple
is written by omitting the expressions surrounding the commas: thus (x,y) and (,) x y
produce the same value. The following functions are dened for pairs (2-tuples): fst, snd,
curry, and uncurry. Similar functions are not predened for larger tuples.

6.1.5 The Unit Datatype

data () = () deriving (Eq, Ord, Bounded, Enum, Read, Show)

The unit datatype () has one non-? member, the nullary constructor (). See also Sec-
tion 3.9.

6.1.6 The Void Datatype

data Void

The Void has no constructors; only ? is an instance of this type.

6.1.7 Function Types

Functions are an abstract type: no constructors directly create functional values. Functions
are an instance of the Show class but not Read. The following simple functions are found
the Prelude: id, const, (.), flip, ($), and until.
66 6. PREDEFINED TYPES AND CLASSES

6.1.8 The IO and IOError Types

The IO type serves as a tag for operations (actions) that interact with the outside world.
The IO type is abstract: no constructors are visible to the user. IO is an instance of the
Monad and Show classes. Section 7 describes I/O operations.

IOError is an abstract type representing errors raised by I/O operations. It is an

instance of Show and Eq. Values of this type are constructed by the various I/O functions
and are not presented in any further detail in this report. The Library Report contains
many other I/O functions.

6.1.9 Other Types

data Maybe a = Nothing | Just a deriving (Eq, Ord, Read, Show)
data Either a b = Left a | Right b deriving (Eq, Ord, Read, Show)
data Ordering = LT | EQ | GT deriving
(Eq, Ord, Bounded, Enum, Read, Show)
The Maybe type is an instance of classes Functor, Monad, MonadZero and MonadPlus. The
Ordering type is used by compare in the class Ord. The functions maybe and either are
found in the Prelude.

6.2 Standard Haskell Classes

Figure 5 shows the hierarchy of Haskell classes dened in the Prelude and the Prelude types
that are instances of these classes. The Void type is not mentioned in this gure since it is
not a member of any class.
6.2 Standard Haskell Classes 67

Figure 5: Standard Haskell Classes

68 6. PREDEFINED TYPES AND CLASSES

6.2.1 The Eq Class

class Eq a where
(==), (/=) :: a -> a -> Bool
x /= y = not (x == y)
All basic datatypes except for functions and IO are instances of this class. Instances of Eq
can be derived for any user-dened datatype whose constituents are also instances of Eq.

6.2.2 The Ord Class

class (Eq a) => Ord a where
compare :: a -> a -> Ordering
(<), (<=), (>=), (>) :: a -> a -> Bool
max, min :: a -> a -> a
compare x y
| x == y = EQ
| x <= y = LT
| otherwise = GT
x <= y = compare x y /= GT
x < y = compare x y == LT
x >= y = compare x y /= LT
x > y = compare x y == GT
-- note that (min x y, max x y) = (x,y) or (y,x)
max x y | x >= y = x
| otherwise = y
min x y | x < y = x
| otherwise = y
The Ord class is used for totally ordered datatypes. All basic datatypes except for functions
and IO are instances of this class. Instances of Ord can be derived for any user-dened
datatype whose constituent types are in Ord. The declared order of the constructors in the
data declaration determines the ordering in derived Ord instances. The Ordering datatype
allows a single comparison to determine the precise ordering of two objects. The defaults
allow a user to create an Ord instance either with a type-specic compare function or with
type-specic == and <= functions.
6.2 Standard Haskell Classes 69

6.2.3 The Read and Show Classes

type ReadS a = String -> [(a,String)]
type ShowS = String -> String
class Read a where
readsPrec :: Int -> ReadS a
readList :: ReadS [a]
class Show a where
showsPrec :: Int -> a -> ShowS
showList :: [a] -> ShowS
The Read and Show classes are used to convert values to or from strings. Derived instances
of Read and Show replicate the style in which a constructor is declared: inx constructors
and eld names are used on input and output. Strings produced by showsPrec are usually
readable by readsPrec. Functions and the IO type are not in Read.
For convenience, the Prelude provides the following auxiliary functions:
reads :: (Read a) => ReadS a
reads = readsPrec 0
shows :: (Show a) => a -> ShowS
shows = showsPrec 0
read :: (Read a) => String -> a
read s = case [x | (x,t) <- reads s, ("","") <- lex t] of
[x] -> x
[] -> error "PreludeText.read: no parse"
_ -> error "PreludeText.read: ambiguous parse"
show :: (Show a) => a -> String
show x = shows x ""
shows and reads use a default precedence of 0. The show function returns a String
instead of a ShowS; the read function reads input from a string, which must be completely
consumed by the input process. The lex function used by read is also part of the Prelude.
70 6. PREDEFINED TYPES AND CLASSES

6.2.4 The Enum Class

class (Ord a) => Enum a where
toEnum :: Int -> a
fromEnum :: a -> Int
enumFrom :: a -> [a] -- [n..]
enumFromThen :: a -> a -> [a] -- [n,n'..]
enumFromTo :: a -> a -> [a] -- [n..m]
enumFromThenTo :: a -> a -> a -> [a] -- [n,n'..m]

enumFromTo n m = takeWhile (<= m) (enumFrom n)

enumFromThenTo n n' m
= takeWhile (if n' >= n then (<= m) else (>= m))
(enumFromThen n n')
Class Enum denes operations on sequentially ordered types. The toEnum and fromEnum
functions map values from a type in Enum onto Int. These functions are not meaningful for
all instances of Enum: oating point values or Integer may not be mapped onto an Int.
An runtime error occurs if either toEnum or fromEnum is given a value not mappable to
the result type. Instances of Enum may be derived for any enumeration type (types whose
constructors have no elds). There are also Enum instances for oats.

6.2.5 Monadic Classes

class Functor f where
map :: (a -> b) -> (f a -> f b)
class Monad m where
(>>=) :: m a -> (a -> m b) -> m b
(>>) :: m a -> m b -> m b
return :: a -> m a

class (Monad m) => MonadZero m where

zero :: m a

class (MonadZero m) => MonadPlus m where

(++) :: m a -> m a -> m a
These classes dene the basic monadic operations. See Section 7 for more information about
monads. The monadic classes serve to organize a set of operations common to a number of
related types. These types are all container types : that is, they contain a value or values of
another type. (To be precise, types in these classes must have kind  ! .) In the Prelude,
lists, Maybe, and IO are all predened container types.
The Functor class is used for types that can be mapped over. Lists, IO, and Maybe are
in this class. The IO type, Maybe, and lists are instances of Monad. The do syntax provides
a more readable notation for the operators in Monad. Both lists and Maybe are instances
of the MonadZero class. The MonadPlus class provides a `monadic addition' operator: ++.
In the Prelude, Maybe and lists are in this class. For lists, ++ denes concatenation. For
Maybe, the ++ function returns the rst non-empty value (if any).
6.2 Standard Haskell Classes 71

Instances of these classes should satisfy the following laws:

map id = id
map (f . g) = map f . map g
map f xs = xs >>= return . f
return a >>= k = k a
m >>= return = m
m >>= (\x -> k x >>= h) = (m >>= k) >>= h
m >> zero = zero
zero >>= m = zero
m ++ zero = m
zero ++ m = m

All instances dened in the Prelude satisfy these laws.

The Prelude provides the following auxiliary functions:
accumulate :: Monad m => [m a] -> m [a]
sequence :: Monad m => [m a] -> m ()
mapM :: Monad m => (a -> m b) -> [a] -> m [b]
mapM_ :: Monad m => (a -> m b) -> [a] -> m ()
guard :: MonadZero m => Bool -> m ()

6.2.6 The Bounded Class

class Bounded a where
minBound, maxBound :: a

The Bounded class is used to name the upper and lower limits of a type. Ord is not
a superclass of Bounded since types that are not totally ordered may also have upper and
lower bounds. The types Int, Char, Bool, (), Ordering, and all tuples are instances of
Bounded. The Bounded class may be derived for any enumeration type; minBound is the
rst constructor listed in the data declaration and maxBound is the last. Bounded may also
be derived for single-constructor datatypes whose constituent types are in Bounded.

6.2.7 The Eval Class

class Eval a where
strict :: (a -> b) -> a -> b
seq :: a -> b -> b
strict f x = x `seq` f x
Class Eval is a special class for which no instances may be explicitly dened. An Eval
instance is implicitly derived for every datatype. Functions as well as all other built-in
types are in Eval. (As a consequence, ? is not the same as \x -> ? since seq can be used
to distinguish them.)
72 6. PREDEFINED TYPES AND CLASSES

The functions seq and strict are dened by the equations:

seq ?b = ?
seq a b = b ; if a 6= ?
strict f x = seq x (f x )
These functions are usually introduced to improve performance by avoiding unneeded lazi-
ness. Strict datatypes (see Section 4.2.1) are dened in terms of the strict function. This
class explicitly marks functions and types that employ polymorphic strictness.
The Eval instance for a type T with a constructor C implicitly derived by the compiler
is:
instance Eval T where
x `seq` y = case x of
C -> y
_ -> y -- catches any other constructors in T
The case is used to force evaluation of the rst argument to `seq` before returning the
second argument. The constructor mentioned by seq is arbitrary: any constructor from T
can be used.

6.3 Numbers
Haskell provides several kinds of numbers; the numeric types and the operations upon
them have been heavily in uenced by Common Lisp and Scheme. Numeric function names
and operators are usually overloaded, using several type classes with an inclusion relation
shown in Figure 5, page 67. The class Num of numeric types is a subclass of Eq, since
all numbers may be compared for equality; its subclass Real is also a subclass of Ord,
since the other comparison operations apply to all but complex numbers (dened in the
Complex library). The class Integral contains both xed- and arbitrary-precision integers;
the class Fractional contains all non-integral types; and the class Floating contains all
oating-point types, both real and complex.
The Prelude denes only the most basic numeric types: xed sized integers (Int), ar-
bitrary precision integers (Integer), single precision oating (Float), and double precision
oating (Double). Other numeric types such as rationals and complex numbers are dened
in libraries. In particular, the type Rational is a ratio of two Integer values, as dened
in the Rational library.
The default oating point operations dened by the Haskell Prelude do not conform to
current language independent arithmetic (LIA) standards. These standards require consid-
erable more complexity in the numeric structure and have thus been relegated to a library.
Some, but not all, aspects of the IEEE standard oating point standard have been accounted
for in class RealFloat.
Table 3 lists the standard numeric types. The type Int covers at least the range
[ ? 2 29 ; 2 29 ? 1 ]. As Int is an instance of the Bounded class, maxBound and minBound
can be used to determine the exact Int range dened by an implementation. Float is
6.3 Numbers 73

Type Class Description

Integer Integral Arbitrary-precision integers
Int Integral Fixed-precision integers
(Integral a) => Ratio a RealFrac Rational numbers
Float RealFloat Real oating-point, single precision
Double RealFloat Real oating-point, double precision
(RealFloat a) => Complex a Floating Complex oating-point

Table 3: Standard Numeric Types

implementation-dened; it is desirable that this type be at least equal in range and precision
to the IEEE single-precision type. Similarly, Double should cover IEEE double-precision.
The results of exceptional conditions (such as over ow or under ow) on the xed-precision
numeric types are undened; an implementation may choose error (?, semantically), a
truncated value, or a special value such as innity, indenite, etc.
The standard numeric classes and other numeric functions dened in the Prelude are
shown in Figures 6{7. Figure 5 shows the class dependencies and built-in types that are
instances of the numeric classes.

6.3.1 Numeric Literals

The syntax of numeric literals is given in Section 2.4. An integer literal represents the ap-
plication of the function fromInteger to the appropriate value of type Integer. Similarly,
a oating literal stands for an application of fromRational to a value of type Rational
(that is, Ratio Integer). Given the typings:
fromInteger :: (Num a) => Integer -> a
fromRational :: (Fractional a) => Rational -> a
integer and oating literals have the typings (Num a) => a and (Fractional a) => a,
respectively. Numeric literals are dened in this indirect way so that they may be interpreted
as values of any appropriate numeric type. See Section 4.3.4 for a discussion of overloading
ambiguity.

6.3.2 Arithmetic and Number-Theoretic Operations

The inx class methods (+), (*), (-), and the unary function negate (which can also be
written as a prex minus sign; see section 3.4) apply to all numbers. The class methods
quot, rem, div, and mod apply only to integral numbers, while the class method (/) applies
only to fractional ones. The quot, rem, div, and mod class methods satisfy these laws:
(x quot y)*y + (x rem y) == x
(x div y)*y + (x mod y) == x
74 6. PREDEFINED TYPES AND CLASSES

class (Eq a, Show a, Eval a) => Num a where

(+), (-), (*) :: a -> a -> a
negate :: a -> a
abs, signum :: a -> a
fromInteger :: Integer -> a
class (Num a, Ord a) => Real a where
toRational :: a -> Rational
class (Real a, Enum a) => Integral a where
quot, rem, div, mod :: a -> a -> a
quotRem, divMod :: a -> a -> (a,a)
toInteger :: a -> Integer
class (Num a) => Fractional a where
(/) :: a -> a -> a
recip :: a -> a
fromRational :: Rational -> a
class (Fractional a) => Floating a where
pi :: a
exp, log, sqrt :: a -> a
(**), logBase :: a -> a -> a
sin, cos, tan :: a -> a
asin, acos, atan :: a -> a
sinh, cosh, tanh :: a -> a
asinh, acosh, atanh :: a -> a

Figure 6: Standard Numeric Classes and Related Operations, Part 1

`quot` is integer division truncated toward zero, while the result of `div` is truncated
toward negative innity. The quotRem class method takes a dividend and a divisor as
arguments and returns a (quotient, remainder) pair; divMod is dened similarly:
quotRem x y = (x quot y, x rem y)
divMod x y = (x div y, x mod y)
Also available on integral numbers are the even and odd predicates:
even x = x rem 2 == 0
odd = not . even
Finally, there are the greatest common divisor and least common multiple functions: gcd x
y is the greatest integer that divides both x and y . lcm x y is the smallest positive integer
that both x and y divide.
6.3 Numbers 75

class (Real a, Fractional a) => RealFrac a where

properFraction :: (Integral b) => a -> (b,a)
truncate, round :: (Integral b) => a -> b
ceiling, floor :: (Integral b) => a -> b
class (RealFrac a, Floating a) => RealFloat a where
floatRadix :: a -> Integer
floatDigits :: a -> Int
floatRange :: a -> (Int,Int)
decodeFloat :: a -> (Integer,Int)
encodeFloat :: Integer -> Int -> a
exponent :: a -> Int
significand :: a -> a
scaleFloat :: Int -> a -> a
isNaN, isInfinite, isDenormalized, isNegativeZero, isIEEE
:: a -> Bool

fromIntegral :: (Integral a, Num b) => a -> b

gcd, lcm :: (Integral a) => a -> a-> a
(^) :: (Num a, Integral b) => a -> b -> a
(^^) :: (Fractional a, Integral b) => a -> b -> a
fromRealFrac :: (RealFrac a, Fractional b) => a -> b
atan2 :: (RealFloat a) => a -> a -> a

Figure 7: Standard Numeric Classes and Related Operations, Part 2

6.3.3 Exponentiation and Logarithms

The one-argument exponential function exp and the logarithm function log act on oating-
point numbers and use base e . logBase a x returns the logarithm of x in base a . sqrt
returns the principal square root of a oating-point number. There are three two-argument
exponentiation operations: (^) raises any number to a nonnegative integer power, (^^)
raises a fractional number to any integer power, and (**) takes two oating-point argu-
ments. The value of x ^0 or x ^^0 is 1 for any x , including zero; 0**y is undened.

6.3.4 Magnitude and Sign

A number has a magnitude and a sign. The functions abs and signum apply to any number
and satisfy the law:
abs x * signum x == x

For real numbers, these functions are dened by:

76 6. PREDEFINED TYPES AND CLASSES

abs x | x >= 0 = x
| x < 0 = -x
signum x | x > 0 = 1
| x == 0 = 0
| x < 0 = -1

6.3.5 Trigonometric Functions

The circular and hyperbolic sine, cosine, and tangent functions and their inverses are pro-
vided for oating-point numbers. A version of arctangent taking two real oating-point
arguments is also provided: For real oating x and y , atan2 y x diers from atan (y /x )
in that its range is ( ? ;  ] rather than (?  = 2 ;  = 2 ) (because the signs of the
arguments provide quadrant information), and that it is dened when x is zero.
The precise denition of the above functions is as in Common Lisp, which in turn
follows Peneld's proposal for APL [7]. See these references for discussions of branch cuts,
discontinuities, and implementation.

6.3.6 Coercions and Component Extraction

The ceiling, floor, truncate, and round functions each take a real fractional argument
and return an integral result. ceiling x returns the least integer not less than x , and
floor x , the greatest integer not greater than x . truncate x yields the integer nearest x
between 0 and x , inclusive. round x returns the nearest integer to x , the even integer if x
is equidistant between two integers.
The function properFraction takes a real fractional number x and returns a pair com-
prising x as a proper fraction: an integral number with the same sign as x and a fraction
with the same type and sign as x and with absolute value less than 1. The ceiling, floor,
truncate, and round functions can be dened in terms of this one.

Two functions convert numbers to type Rational: toRational returns the rational
equivalent of its real argument with full precision; approxRational takes two real fractional
arguments x and  and returns the simplest rational number within  of x , where a rational
p=q in reduced form is simpler than another p0=q 0 if jpj  jp0j and q  q 0. Every real interval
contains a unique simplest rational; in particular, note that 0=1 is the simplest rational of
all.
The class methods of class RealFloat allow ecient, machine-independent access to
the components of a oating-point number. The functions floatRadix, floatDigits, and
floatRange give the parameters of a oating-point type: the radix of the representation,
the number of digits of this radix in the signicand, and the lowest and highest values the
exponent may assume, respectively. The function decodeFloat applied to a real oating-
point number returns the signicand expressed as an Integer and an appropriately scaled
exponent (an Int). If decodeFloat x yields (m ,n ), then x is equal in value to mb n ,
6.3 Numbers 77

where b is the oating-point radix, and furthermore, either m and n are both zero or
else b d ?1  m < b d , where d is the value of floatDigits x. encodeFloat performs the
inverse of this transformation. The functions significand and exponent together provide
the same information as decodeFloat, but rather than an Integer, significand x yields
a value of the same type as x, scaled to lie in the open interval (?1 ; 1 ). exponent 0 is zero.
scaleFloat multiplies a oating-point number by an integer power of the radix.

The functions isNaN, isInfinite, isDenormalized, isNegativeZero, and isIEEE all

support numbers represented using the IEEE standard. For non-IEEE oating point num-
bers, these may all return false.
Also available are the following coercion functions:
fromIntegral :: (Integral a, Num b) => a -> b
fromRealFrac :: (RealFrac a, Fractional b) => a -> b
78 7. BASIC INPUT/OUTPUT

7 Basic Input/Output
The I/O system in Haskell is purely functional, yet has all of the expressive power found in
conventional programming languages. To achieve this, Haskell uses a monad to integrate
I/O operations into a purely functional context.
The I/O monad used by Haskell mediates between the values natural to a functional
language and the actions that characterize I/O operations and imperative programming
in general. The order of evaluation of expressions in Haskell is constrained only by data
dependencies; an implementation has a great deal of freedom in choosing this order. Actions,
however, must be ordered in a well-dened manner for program execution { and I/O in
particular { to be meaningful. Haskell's I/O monad provides the user with a way to specify
the sequential chaining of actions, and an implementation is obliged to preserve this order.
The term monad comes from a branch of mathematics known as category theory. From
the perspective of a Haskell programmer, however, it is best to think of a monad as an
abstract datatype. In the case of the I/O monad, the abstract values are the actions men-
tioned above. Some operations are primitive actions, corresponding to conventional I/O
operations. Special operations (methods in the class Monad, see Section 6.2.5) sequentially
compose actions, corresponding to sequencing operators (such as the semi-colon) in imper-
ative languages.

7.1 Standard I/O Functions

Although Haskell provides fairly sophisticated I/O facilities, as dened in the IO library,
it is possible to write many Haskell programs using only the few simple functions that are
exported from the Prelude, and which are described in this section.
All I/O functions dened here are character oriented. The treatment of the newline
character will vary on dierent systems. For example, two characters of input, return and
linefeed, may read as a single newline character. These functions cannot be used portably
for binary I/O.

Output Functions These functions write to the standard output device (this is normally
the user's terminal).
putChar :: Char -> IO ()
putStr :: String -> IO ()
putStrLn :: String -> IO () -- adds a newline
print :: Show a => a -> IO ()
The print function outputs a value of any printable type to the standard output device
(this is normally the user's terminal). Printable types are those that are instances of class
Show; print converts values to strings for output using the show operation and adds a
newline.
For example, a program to print the rst 20 integers and their powers of 2 could be
written as:
7.1 Standard I/O Functions 79

main = print ([(n, 2^n) | n <- [0..19]])

Input Functions These functions read input from the standard input device (normally
the user's terminal).
getChar :: IO Char
getLine :: IO String
getContents :: IO String
interact :: (String -> String) -> IO ()
readIO :: Read a => String -> IO a
readLine :: Read a => IO a
Both getChar and getLine raise an exception on end-of-le; the IOError value associated
with end-of-le is dened in a library. The getContents operation returns all user input as
a single string, which is read lazily as it is needed. The interact function takes a function
of type String->String as its argument. The entire input from the standard input device
(normally the user's terminal) is passed to this function as its argument, and the resulting
string is output on the standard output device. The readIO function is similar to read
except that it signals parse failure to the I/O monad instead of terminating the program.
The readLine function combines getLine and readIO.
By default, these input functions echo to standard output. Functions in the I/O library
provide full control over echoing.
The following program simply removes all non-ASCII characters from its standard input
and echoes the result on its standard output. (The isAscii function is dened in a library.)
main = interact (filter isAscii)

Files These functions operate on les of characters. Files are named by strings using some
implementation-specic method to resolve strings as le names.
The writeFile and appendFile functions write or append the string, their second
argument, to the le, their rst argument. The readFile function reads a le and returns
the contents of the le as a string. The le is read lazily, on demand, as with getContents.
type FilePath = String
writeFile :: FilePath -> String -> IO ()
appendFile :: FilePath -> String -> IO ()
readFile :: FilePath -> IO String
Note that writeFile and appendFile write a literal string to a le. To write a value of
any printable type, as with print, use the show function to convert the value to a string
rst.
main = appendFile "squares" (show [(x,x*x) | x <- [0,0.1..2]])
80 7. BASIC INPUT/OUTPUT

7.2 Sequencing I/O Operations

The two monadic binding functions, methods in the Monad class, are used to compose a
series of I/O operations. The >> function is used where the result of the rst operation is
uninteresting, for example when it is (). The >>= operation passes the result of the rst
operation as an argument to the second operation.
(>>=) :: IO a -> (a -> IO b) -> IO b
(>>) :: IO a -> IO b -> IO b
For example,
main = readFile "input-file" >>= \ s ->
writeFile "output-file" (filter isAscii s) >>
putStr "Filtering successful\n"
is similar to the previous example using interact, but takes its input from "input-file"
and writes its output to "output-file". A message is printed on the standard output
before the program completes.
The do notation allows programming in a more imperative syntactic style. A slightly
more elaborate version of the previous example would be:
main = do
putStr "Input file: "
ifile <- getLine
putStr "Output file: "
ofile <- getLine
s <- readFile ifile
writeFile ofile (filter isAscii s)
putStr "Filtering successful\n"

The return function is used to dene the result of an I/O operation. For example,
getLine is dened in terms of getChar, using return to dene the result the monad:
getLine :: IO String
getLine = do c <- getChar
if c == '\n' then return ""
else do s <- getLine
return (c:s)

7.3 Exception Handling in the I/O Monad

The I/O monad includes a simple exception handling system. Any I/O operation may raise
an exception instead of returning a result. Exceptions in the I/O monad are represented by
values of type IOError. This is an abstract type: its constructors are hidden from the user.
The IO library denes functions that construct and examine IOError values. The only
7.3 Exception Handling in the I/O Monad 81

Prelude function that creates an IOError value is userError. User error values include a
string describing the error.
Exceptions are raised and caught using the following functions:
fail :: IOError -> IO a
catch :: IO a -> (IOError -> IO a) -> IO a
The fail function raises an exception; the catch function establishes a handler that receives
any exception raised in the action protected by catch. An exception is caught by the most
recent handler established by catch. These handlers are not selective: all exceptions are
caught. Exception propagation must be explicitly provided in a handler by re-raising any
unwanted exceptions. For example, in
f = catch g (\e -> if IO.isEOFError e then return [] else fail e)

the function f returns [] when an end-of-le exception occurs in g; otherwise, the exception
is propagated to the next outer handler. The isEOFError function is part of IO library.
When an exception propagates outside the main program, the Haskell system prints the
associated IOError value and exits the program.
The exceptions raised by the I/O functions in the Prelude are dened in the Library
Report.
82 A. STANDARD PRELUDE

A Standard Prelude
In this appendix the entire Haskell prelude is given. It is organized into a root module
and three sub-modules. Primitives that are not denable in Haskell, indicated by names
starting with prim, are dened in a system dependent manner in module PreludeBuiltin
and are not shown here. Instance declarations that simply bind primitives to class methods
are omitted. Some of the more verbose instances with obvious functionality have been left
out for the sake of brevity.
Declarations for special types such as Integer, (), or (->) are included in the Prelude
for completeness even though the declaration may be incomplete or syntactically invalid.
 83

module Prelude (
module PreludeList, module PreludeText, module PreludeIO,
Bool(False, True),
Maybe(Nothing, Just),
Either(Left, Right),
Ordering(LT, EQ, GT),
Char, String, Int, Integer, Float, Double, IO, Void,
Ratio, Rational,
-- List type: []((:), [])
-- Tuple types: (,), (,,), etc.
-- Trivial type: ()
-- Functions: (->)
Eq((==), (/=)),
Ord(compare, (<), (<=), (>=), (>), max, min),
Enum(toEnum, fromEnum, enumFrom, enumFromThen,
enumFromTo, enumFromThenTo),
Bounded(minBound, maxBound),
Eval(seq, strict),
Num((+), (-), (*), negate, abs, signum, fromInteger),
Real(toRational),
Integral(quot, rem, div, mod, quotRem, divMod, toInteger),
Fractional((/), recip, fromRational),
Floating(pi, exp, log, sqrt, (**), logBase, sin, cos, tan,
asin, acos, atan, sinh, cosh, tanh, asinh, acosh, atanh),
RealFrac(properFraction, truncate, round, ceiling, floor),
RealFloat(floatRadix, floatDigits, floatRange, decodeFloat,
encodeFloat, exponent, significand, scaleFloat, isNaN,
isInfinite, isDenormalized, isIEEE, isNegativeZero),
Monad((>>=), (>>), return),
MonadZero(zero),
MonadPlus((++)),
Functor(map),
succ, pred,
mapM, mapM_, guard, accumulate, sequence, filter, concat, applyM,
maybe, either,
(&&), (||), not, otherwise,
subtract, even, odd, gcd, lcm, (^), (^^),
fromIntegral, fromRealFrac, atan2,
fst, snd, curry, uncurry, id, const, (.), flip, ($), until,
asTypeOf, error, undefined ) where
84 A. STANDARD PRELUDE

import PreludeBuiltin -- Contains all `prim' values

import PreludeList
import PreludeText
import PreludeIO
import Ratio(Ratio, Rational, (%), numerator, denominator)

infixr 9 .
infixr 8 ^, ^^, **
infixl 7 *, /, `quot`, `rem`, `div`, `mod`
infixl 6 +, -
infixr 5 :, ++
infix 4 ==, /=, <, <=, >=, >
infixr 3 &&
infixr 2 ||
infixl 1 >>, >>=
infixr 0 $, `seq`

-- Standard types, classes, instances and related functions

-- Equality and Ordered classes

class Eq a where
(==), (/=) :: a -> a -> Bool
x /= y = not (x == y)

class (Eq a) => Ord a where

compare :: a -> a -> Ordering
(<), (<=),
(>=), (>) :: a -> a -> Bool
max, min :: a -> a -> a

-- An instance of Ord should define either compare or <=

-- Using compare can be more efficient for complex types.
compare x y
| x == y = EQ
| x <= y = LT
| otherwise = GT
x <= y = compare x y /= GT
x < y = compare x y == LT
x >= y = compare x y /= LT
x > y = compare x y == GT
 85

-- note that (min x y, max x y) = (x,y) or (y,x)

max x y
| x >= y = x
| otherwise = y
min x y
| x < y = x
| otherwise = y

-- Enumeration and Bounded classes

class Enum a where

toEnum :: Int -> a
fromEnum :: a -> Int
enumFrom :: a -> [a] -- [n..]
enumFromThen :: a -> a -> [a] -- [n,n'..]
enumFromTo :: a -> a -> [a] -- [n..m]
enumFromThenTo :: a -> a -> a -> [a] -- [n,n'..m]
enumFromTo x y = map toEnum [fromEnum x .. fromEnum y]
enumFromThenTo x y z =
map toEnum [fromEnum x, fromEnum y .. fromEnum z]

succ, pred :: Enum a => a -> a

succ = toEnum . (+1) . fromEnum
pred = toEnum . (subtract 1) . fromEnum

class Bounded a where

minBound :: a
maxBound :: a

-- Numeric classes
class (Eq a, Show a, Eval a) => Num a where
(+), (-), (*) :: a -> a -> a
negate :: a -> a
abs, signum :: a -> a
fromInteger :: Integer -> a
x - y = x + negate y

class (Num a, Ord a) => Real a where

toRational :: a -> Rational
86 A. STANDARD PRELUDE

class (Real a, Enum a) => Integral a where

quot, rem :: a -> a -> a
div, mod :: a -> a -> a
quotRem, divMod :: a -> a -> (a,a)
toInteger :: a -> Integer
n `quot` d = q where (q,r) = quotRem n d
n `rem` d = r where (q,r) = quotRem n d
n `div` d = q where (q,r) = divMod n d
n `mod` d = r where (q,r) = divMod n d
divMod n d = if signum r == - signum d then (q-1, r+d) else qr
where qr@(q,r) = quotRem n d

class (Num a) => Fractional a where

(/) :: a -> a -> a
recip :: a -> a
fromRational :: Rational -> a
recip x = 1 / x

class (Fractional a) => Floating a where

pi :: a
exp, log, sqrt :: a -> a
(**), logBase :: a -> a -> a
sin, cos, tan :: a -> a
asin, acos, atan :: a -> a
sinh, cosh, tanh :: a -> a
asinh, acosh, atanh :: a -> a
x ** y = exp (log x * y)
logBase x y = log y / log x
sqrt x = x ** 0.5
tan x = sin x / cos x
tanh x = sinh x / cosh x
 87

class (Real a, Fractional a) => RealFrac a where

properFraction :: (Integral b) => a -> (b,a)
truncate, round :: (Integral b) => a -> b
ceiling, floor :: (Integral b) => a -> b

truncate x = m where (m,_) = properFraction x

round x = let (n,r) = properFraction x
m = if r < 0 then n - 1 else n + 1
in case signum (abs r - 0.5) of
-1 -> n
0 -> if even n then n else m
1 -> m
ceiling x = if r > 0 then n + 1 else n
where (n,r) = properFraction x

floor x = if r < 0 then n - 1 else n

where (n,r) = properFraction x

class (RealFrac a, Floating a) => RealFloat a where

floatRadix :: a -> Integer
floatDigits :: a -> Int
floatRange :: a -> (Int,Int)
decodeFloat :: a -> (Integer,Int)
encodeFloat :: Integer -> Int -> a
exponent :: a -> Int
significand :: a -> a
scaleFloat :: Int -> a -> a
isNaN, isInfinite, isDenormalized, isNegativeZero, isIEEE
:: a -> Bool
exponent x = if m == 0 then 0 else n + floatDigits x
where (m,n) = decodeFloat x
significand x = encodeFloat m (- floatDigits x)
where (m,_) = decodeFloat x

scaleFloat k x = encodeFloat m (n+k)

where (m,n) = decodeFloat x

-- Numeric functions

subtract :: (Num a) => a -> a -> a

subtract = flip (-)

even, odd :: (Integral a) => a -> Bool

even n = n `rem` 2 == 0
odd = not . even
88 A. STANDARD PRELUDE

gcd :: (Integral a) => a -> a -> a

gcd 0 0 = error "Prelude.gcd: gcd 0 0 is undefined"
gcd x y = gcd' (abs x) (abs y)
where gcd' x 0 = x
gcd' x y = gcd' y (x `rem` y)

lcm :: (Integral a) => a -> a -> a

lcm _ 0 = 0
lcm 0 _ = 0
lcm x y = abs ((x `quot` (gcd x y)) * y)

(^) :: (Num a, Integral b) => a -> b -> a

x ^ 0 = 1
x ^ n | n > 0 = f x (n-1) x
where f _ 0 y = y
f x n y = g x n where
g x n | even n = g (x*x) (n `quot` 2)
| otherwise = f x (n-1) (x*y)
_ ^ _ = error "Prelude.^: negative exponent"

(^^) :: (Fractional a, Integral b) => a -> b -> a

x ^^ n = if n >= 0 then x^n else recip (x^(-n))

fromIntegral :: (Integral a, Num b) => a -> b

fromIntegral = fromInteger . toInteger

fromRealFrac :: (RealFrac a, Fractional b) => a -> b

fromRealFrac = fromRational . toRational

atan2 :: (RealFloat a) => a -> a -> a

atan2 y x = case (signum y, signum x) of
( 0, 1) -> 0
( 1, 0) -> pi/2
( 0,-1) -> pi
(-1, 0) -> -pi/2
( _, 1) -> atan (y/x)
( _,-1) -> atan (y/x) + pi
( 0, 0) -> error "Prelude.atan2: atan2 of origin"

-- Monadic classes

class Functor f where

map :: (a -> b) -> f a -> f b
 89

class Monad m where

(>>=) :: m a -> (a -> m b) -> m b
(>>) :: m a -> m b -> m b
return :: a -> m a

m >> k = m >>= \_ -> k

class (Monad m) => MonadZero m where

zero :: m a

class (MonadZero m) => MonadPlus m where

(++) :: m a -> m a -> m a

accumulate :: Monad m => [m a] -> m [a]

accumulate = foldr mcons (return [])
where mcons p q = p >>= \x -> q >>= \y -> return (x:y)

sequence :: Monad m => [m a] -> m ()

sequence = foldr (>>) (return ())

mapM :: Monad m => (a -> m b) -> [a] -> m [b]

mapM f as = accumulate (map f as)

mapM_ :: Monad m => (a -> m b) -> [a] -> m ()

mapM_ f as = sequence (map f as)

guard :: MonadZero m => Bool -> m ()

guard p = if p then return () else zero

-- This subsumes the list-based filter function.

filter :: MonadZero m => (a -> Bool) -> m a -> m a
filter p = applyM (\x -> if p x then return x else zero)

-- This subsumes the list-based concat function.

concat :: MonadPlus m => [m a] -> m a
concat = foldr (++) zero

applyM :: Monad m => (a -> m b) -> m a -> m b

applyM f x = x >>= f

-- Eval Class

class Eval a where

seq :: a -> b -> b
strict :: (a -> b) -> a -> b
strict f x = x `seq` f x

-- Trivial type

data () = () deriving (Eq, Ord, Enum, Bounded)

90 A. STANDARD PRELUDE

-- Function type

data a -> b -- No constructor for functions is exported.

-- identity function
id :: a -> a
id x = x

-- constant function
const :: a -> b -> a
const x _ = x

-- function composition
(.) :: (b -> c) -> (a -> b) -> a -> c
f . g = \ x -> f (g x)

-- flip f takes its (first) two arguments in the reverse order of f.

flip :: (a -> b -> c) -> b -> a -> c
flip f x y = f y x

-- right-associating infix application operator (useful in continuation-

-- passing style)
($) :: (a -> b) -> a -> b
f $ x = f x

-- Empty type
data Void -- No constructor for Void is exported. Import/Export
-- lists must use Void instead of Void(..) or Void()

-- Boolean type
data Bool = False | True deriving (Eq, Ord, Enum, Read, Show, Bounded)

-- Boolean functions
(&&), (||) :: Bool -> Bool -> Bool
True && x = x
False && _ = False
True || _ = True
False || x = x

not :: Bool -> Bool

not True = False
not False = True

otherwise :: Bool
otherwise = True
 91

-- Character type

data Char = ... 'a' | 'b' ... -- 2^16 unicode values

instance Eq Char where

c == c' = fromEnum c == fromEnum c'

instance Ord Char where

c <= c' = fromEnum c <= fromEnum c'

instance Enum Char where

toEnum = primIntToChar
fromEnum = primCharToInt
enumFrom c = map toEnum [fromEnum c .. fromEnum (maxBound::Char)]
enumFromThen c c' = [fromEnum c, fromEnum c' .. fromEnum lastChar]
where lastChar :: Char
lastChar | c' < c = minBound
| otherwise = maxBound

instance Bounded Char where

minBound = '\0'
maxBound = '\xffff'

type String = [Char]

-- Maybe type
data Maybe a = Nothing | Just a deriving (Eq, Ord, Read, Show)

maybe :: b -> (a -> b) -> Maybe a -> b

maybe n f Nothing = n
maybe n f (Just x) = f x

instance Functor Maybe where

map f Nothing = Nothing
map f (Just x) = Just (f x)

instance Monad Maybe where

(Just x) >>= k = k x
Nothing >>= k = Nothing
return = Just

instance MonadZero Maybe where

zero = Nothing

instance MonadPlus Maybe where

Nothing ++ ys = ys
xs ++ ys = xs
92 A. STANDARD PRELUDE

-- Either type

data Either a b = Left a | Right b deriving (Eq, Ord, Read, Show)

either :: (a -> c) -> (b -> c) -> Either a b -> c

either f g (Left x) = f x
either f g (Right y) = g y

-- IO type
data IO a -- abstract

instance Functor IO where

map f x = x >>= (return . f)

instance Monad IO where ...

-- Ordering type

data Ordering = LT | EQ | GT
deriving (Eq, Ord, Enum, Read, Show, Bounded)

-- Standard numeric types. The data declarations for these types cannot
-- be expressed directly in Haskell since the constructor lists would be
-- far too large.
data Int = minBound ... -1 | 0 | 1 ... maxBound
instance Eq Int where ...
instance Ord Int where ...
instance Num Int where ...
instance Real Int where ...
instance Integral Int where ...
instance Enum Int where ...
instance Bounded Int where ...

data Integer = ... -1 | 0 | 1 ...

instance Eq Integer where ...
instance Ord Integer where ...
instance Num Integer where ...
instance Real Integer where ...
instance Integral Integer where ...
instance Enum Integer where ...
 93

data Float
instance Eq Float where ...
instance Ord Float where ...
instance Num Float where ...
instance Real Float where ...
instance Fractional Float where ...
instance Floating Float where ...
instance RealFrac Float where ...
instance RealFloat Float where ...

data Double
instance Eq Double where ...
instance Ord Double where ...
instance Num Double where ...
instance Real Double where ...
instance Fractional Double where ...
instance Floating Double where ...
instance RealFrac Double where ...
instance RealFloat Double where ...

-- The Enum instances for Floats and Doubles are slightly unusual.
-- The `toEnum' function truncates numbers to Int. The definitions
-- of enumFrom and enumFromThen allow floats to be used in arithmetic
-- series: [0,0.1 .. 1.0]. However, roundoff errors make these somewhat
-- dubious. This example may have either 10 or 11 elements, depending on
-- how 0.1 is represented.
instance Enum Float where
toEnum = fromIntegral
fromEnum = fromInteger . truncate -- may overflow
enumFrom = numericEnumFrom
enumFromThen = numericEnumFromThen
enumFromTo = numericEnumFromTo
enumFromThenTo = numericEnumFromThenTo

instance Enum Double where

toEnum = fromIntegral
fromEnum = fromInteger . truncate -- may overflow
enumFrom = numericEnumFrom
enumFromThen = numericEnumFromThen
enumFromTo = numericEnumFromTo
enumFromThenTo = numericEnumFromThenTo
94 A. STANDARD PRELUDE

numericEnumFrom :: (Real a) => a -> [a]

numericEnumFromThen :: (Real a) => a -> a -> [a]
numericEnumFromTo :: (Real a) => a -> a -> [a]
numericEnumFromThenTo :: (Real a) => a -> a -> a -> [a]
numericEnumFrom = iterate (+1)
numericEnumFromThen n m = iterate (+(m-n)) n
numericEnumFromTo n m = takeWhile (<= m) (numericEnumFrom n)
numericEnumFromThenTo n n' m
= takeWhile (if n' >= n then (<= m) else (>= m))
numericEnumFromThen n m

-- Lists
data [a] = [] | a : [a] deriving (Eq, Ord)

instance Functor [] where

map f [] = []
map f (x:xs) = f x : map f xs

instance Monad [] where

m >>= k = concat (map k m)
return x = [x]

instance MonadZero [] where

zero = []

instance MonadPlus [] where

xs ++ ys = foldr (:) ys xs

-- Tuples
data (a,b) = (a,b) deriving (Eq, Ord, Bounded)
data (a,b,c) = (a,b,c) deriving (Eq, Ord, Bounded)

-- component projections for pairs:

-- (NB: not provided for triples, quadruples, etc.)
fst :: (a,b) -> a
fst (x,y) = x

snd :: (a,b) -> b

snd (x,y) = y

-- curry converts an uncurried function to a curried function;

-- uncurry converts a curried function to a function on pairs.
curry :: ((a, b) -> c) -> a -> b -> c
curry f x y = f (x, y)

uncurry :: (a -> b -> c) -> ((a, b) -> c)

uncurry f p = f (fst p) (snd p)
 95

-- Misc functions

-- until p f yields the result of applying f until p holds.

until :: (a -> Bool) -> (a -> a) -> a -> a
until p f x
| p x = x
| otherwise = until p f (f x)

-- asTypeOf is a type-restricted version of const. It is usually used

-- as an infix operator, and its typing forces its first argument
-- (which is usually overloaded) to have the same type as the second.
asTypeOf :: a -> a -> a
asTypeOf = const

-- error stops execution and displays an error message

error :: String -> a
error = primError

-- It is expected that compilers will recognize this and insert error

-- messages that are more appropriate to the context in which undefined
-- appears.
undefined :: a
undefined = error "Prelude.undefined"
96 A. STANDARD PRELUDE

A.1 Prelude PreludeList

-- Standard list functions

module PreludeList (
head, last, tail, init, null, length, (!!),
foldl, foldl1, scanl, scanl1, foldr, foldr1, scanr, scanr1,
iterate, repeat, replicate, cycle,
take, drop, splitAt, takeWhile, dropWhile, span, break,
lines, words, unlines, unwords, reverse, and, or,
any, all, elem, notElem, lookup,
sum, product, maximum, minimum, concatMap,
zip, zip3, zipWith, zipWith3, unzip, unzip3)
where

import qualified Char(isSpace)

infixl 9 !!
infix 4 `elem`, `notElem`

-- head and tail extract the first element and remaining elements,
-- respectively, of a list, which must be non-empty. last and init
-- are the dual functions working from the end of a finite list,
-- rather than the beginning.
head :: [a] -> a
head (x:_) = x
head [] = error "PreludeList.head: empty list"

last :: [a] -> a

last [x] = x
last (_:xs) = last xs
last [] = error "PreludeList.last: empty list"

tail :: [a] -> [a]

tail (_:xs) = xs
tail [] = error "PreludeList.tail: empty list"

init :: [a] -> [a]

init [x] = []
init (x:xs) = x : init xs
init [] = error "PreludeList.init: empty list"

null :: [a] -> Bool

null [] = True
null (_:_) = False
A.1 Prelude PreludeList 97

-- length returns the length of a finite list as an Int.

length :: [a] -> Int
length [] = 0
length (_:l) = 1 + length l

-- List index (subscript) operator, 0-origin

(!!) :: [a] -> Int -> a
(x:_) !! 0 = x
(_:xs) !! n | n > 0 = xs !! (n-1)
(_:_) !! _ = error "PreludeList.!!: negative index"
[] !! _ = error "PreludeList.!!: index too large"

-- foldl, applied to a binary operator, a starting value (typically the

-- left-identity of the operator), and a list, reduces the list using
-- the binary operator, from left to right:
-- foldl f z [x1, x2, ..., xn] == (...((z `f` x1) `f` x2) `f`...) `f` xn
-- foldl1 is a variant that has no starting value argument, and thus must
-- be applied to non-empty lists. scanl is similar to foldl, but returns
-- a list of successive reduced values from the left:
-- scanl f z [x1, x2, ...] == [z, z `f` x1, (z `f` x1) `f` x2, ...]
-- Note that last (scanl f z xs) == foldl f z xs.
-- scanl1 is similar, again without the starting element:
-- scanl1 f [x1, x2, ...] == [x1, x1 `f` x2, ...]
foldl :: (a -> b -> a) -> a -> [b] -> a
foldl f z [] = z
foldl f z (x:xs) = foldl f (f z x) xs

foldl1 :: (a -> a -> a) -> [a] -> a

foldl1 f (x:xs) = foldl f x xs
foldl1 _ [] = error "PreludeList.foldl1: empty list"

scanl :: (a -> b -> a) -> a -> [b] -> [a]

scanl f q xs = q : (case xs of
[] -> []
x:xs -> scanl f (f q x) xs)

scanl1 :: (a -> a -> a) -> [a] -> [a]

scanl1 f (x:xs) = scanl f x xs
scanl1 _ [] = error "PreludeList.scanl1: empty list"

-- foldr, foldr1, scanr, and scanr1 are the right-to-left duals of the
-- above functions.

foldr :: (a -> b -> b) -> b -> [a] -> b

foldr f z [] = z
foldr f z (x:xs) = f x (foldr f z xs)
98 A. STANDARD PRELUDE

foldr1 :: (a -> a -> a) -> [a] -> a

foldr1 f [x] = x
foldr1 f (x:xs) = f x (foldr1 f xs)
foldr1 _ [] = error "PreludeList.foldr1: empty list"

scanr :: (a -> b -> b) -> b -> [a] -> [b]

scanr f q0 [] = [q0]
scanr f q0 (x:xs) = f x q : qs
where qs@(q:_) = scanr f q0 xs

scanr1 :: (a -> a -> a) -> [a] -> [a]

scanr1 f [x] = [x]
scanr1 f (x:xs) = f x q : qs
where qs@(q:_) = scanr1 f xs
scanr1 _ [] = error "PreludeList.scanr1: empty list"

-- iterate f x returns an infinite list of repeated applications of f to x:

-- iterate f x == [x, f x, f (f x), ...]
iterate :: (a -> a) -> a -> [a]
iterate f x = x : iterate f (f x)

-- repeat x is an infinite list, with x the value of every element.

repeat :: a -> [a]
repeat x = xs where xs = x:xs

-- replicate n x is a list of length n with x the value of every element

replicate :: Int -> a -> [a]
replicate n x = take n (repeat x)

-- cycle ties a finite list into a circular one, or equivalently,

-- the infinite repetition of the original list. It is the identity
-- on infinite lists.
cycle :: [a] -> [a]
cycle xs = xs' where xs' = xs ++ xs'

-- take n, applied to a list xs, returns the prefix of xs of length n,

-- or xs itself if n > length xs. drop n xs returns the suffix of xs
-- after the first n elements, or [] if n > length xs. splitAt n xs
-- is equivalent to (take n xs, drop n xs).
take :: Int -> [a] -> [a]
take 0 _ = []
take _ [] = []
take n (x:xs) | n > 0 = x : take (n-1) xs
take _ _ = error "PreludeList.take: negative argument"
A.1 Prelude PreludeList 99

drop :: Int -> [a] -> [a]

drop 0 xs = xs
drop _ [] = []
drop n (_:xs) | n > 0 = drop (n-1) xs
drop _ _ = error "PreludeList.drop: negative argument"

splitAt :: Int -> [a] -> ([a],[a])

splitAt 0 xs = ([],xs)
splitAt _ [] = ([],[])
splitAt n (x:xs) | n > 0 = (x:xs',xs'') where (xs',xs'') = splitAt (n-1) xs
splitAt _ _ = error "PreludeList.splitAt: negative argument"

-- takeWhile, applied to a predicate p and a list xs, returns the longest

-- prefix (possibly empty) of xs of elements that satisfy p. dropWhile p xs
-- returns the remaining suffix. Span p xs is equivalent to
-- (takeWhile p xs, dropWhile p xs), while break p uses the negation of p.

takeWhile :: (a -> Bool) -> [a] -> [a]

takeWhile p [] = []
takeWhile p (x:xs)
| p x = x : takeWhile p xs
| otherwise = []

dropWhile :: (a -> Bool) -> [a] -> [a]

dropWhile p [] = []
dropWhile p xs@(x:xs')
| p x = dropWhile p xs'
| otherwise = xs

span, break :: (a -> Bool) -> [a] -> ([a],[a])

span p [] = ([],[])
span p xs@(x:xs')
| p x = (x:xs',xs'') where (xs',xs'') = span p xs
| otherwise = (xs,[])
break p = span (not . p)
100 A. STANDARD PRELUDE

-- lines breaks a string up into a list of strings at newline characters.

-- The resulting strings do not contain newlines. Similary, words
-- breaks a string up into a list of words, which were delimited by
-- white space. unlines and unwords are the inverse operations.
-- unlines joins lines with terminating newlines, and unwords joins
-- words with separating spaces.
lines :: String -> [String]
lines "" = []
lines s = let (l, s') = break (== '\n') s
in l : case s' of
[] -> []
(_:s'') -> lines s''

words :: String -> [String]

words s = case dropWhile Char.isSpace s of
"" -> []
s' -> w : words s''
where (w, s'') = break Char.isSpace s'

unlines :: [String] -> String

unlines = concatMap (++ "\n")

unwords :: [String] -> String

unwords [] = ""
unwords ws = foldr1 (\w s -> w ++ ' ':s) ws

-- reverse xs returns the elements of xs in reverse order. xs must be finite.

reverse :: [a] -> [a]
reverse = foldl (flip (:)) []

-- and returns the conjunction of a Boolean list. For the result to be

-- True, the list must be finite; False, however, results from a False
-- value at a finite index of a finite or infinite list. or is the
-- disjunctive dual of and.
and, or :: [Bool] -> Bool
and = foldr (&&) True
or = foldr (||) False

-- Applied to a predicate and a list, an determines if any element

-- of the list satisfies the predicate. Similarly, for all.
any, all :: (a -> Bool) -> [a] -> Bool
any p = or . map p
all p = and . map p
A.1 Prelude PreludeList 101

-- elem is the list membership predicate, usually written in infix form,

-- e.g., x `elem` xs. notElem is the negation.
elem, notElem :: (Eq a) => a -> [a] -> Bool
elem x = any (== x)
notElem x = all (/= x)

-- lookupB key assocs looks up a key in an association list.

lookup :: (Eq a) => a -> [(a,b)] -> Maybe b
lookup key [] = Nothing
lookup key ((x,y):xys)
| key == x = Just y
| otherwise = lookup key xys

-- sum and product compute the sum or product of a finite list of numbers.
sum, product :: (Num a) => [a] -> a
sum = foldl (+) 0
product = foldl (*) 1

-- maximum and minimum return the maximum or minimum value from a list,
-- which must be non-empty, finite, and of an ordered type.
maximum, minimum :: (Ord a) => [a] -> a
maximum [] = error "PreludeList.maximum: empty list"
maximum xs = foldl1 max xs

minimum [] = error "PreludeList.minimum: empty list"

minimum xs = foldl1 min xs

concatMap :: (a -> [b]) -> [a] -> [b]

concatMap f = concat . map f

-- zip takes two lists and returns a list of corresponding pairs. If one
-- input list is short, excess elements of the longer list are discarded.
-- zip3 takes three lists and returns a list of triples. Zips for larger
-- tuples are in the List library
zip :: [a] -> [b] -> [(a,b)]
zip = zipWith (,)

zip3 :: [a] -> [b] -> [c] -> [(a,b,c)]

zip3 = zipWith3 (,,)
102 A. STANDARD PRELUDE

-- The zipWith family generalises the zip family by zipping with the
-- function given as the first argument, instead of a tupling function.
-- For example, zipWith (+) is applied to two lists to produce the list
-- of corresponding sums.

zipWith :: (a->b->c) -> [a]->[b]->[c]

zipWith z (a:as) (b:bs)
= z a b : zipWith z as bs
zipWith _ _ _ = []

zipWith3 :: (a->b->c->d) -> [a]->[b]->[c]->[d]

zipWith3 z (a:as) (b:bs) (c:cs)
= z a b c : zipWith3 z as bs cs
zipWith3 _ _ _ _ = []

-- unzip transforms a list of pairs into a pair of lists.

unzip :: [(a,b)] -> ([a],[b])

unzip = foldr (\(a,b) ~(as,bs) -> (a:as,b:bs)) ([],[])

unzip3 :: [(a,b,c)] -> ([a],[b],[c])

unzip3 = foldr (\(a,b,c) ~(as,bs,cs) -> (a:as,b:bs,c:cs))
([],[],[])
A.2 Prelude PreludeText 103

A.2 Prelude PreludeText

module PreludeText (
ReadS, ShowS,
Read(readsPrec, readList),
Show(showsPrec, showList),
reads, shows, show, read, lex,
showChar, showString, readParen, showParen ) where

-- The omitted instances can be implemented in standard Haskell but

-- they have been omitted for the sake of brevity
import Char(isSpace, isAlpha, isDigit, isAlphanum, isHexDigit,
showLitChar, readLitChar, lexLitChar)

import Numeric(showSigned, showInt, readSigned, readDec, showFloat,

readFloat, lexDigits)

type ReadS a = String -> [(a,String)]

type ShowS = String -> String

class Read a where

readsPrec :: Int -> ReadS a
readList :: ReadS [a]
readList = readParen False (\r -> [pr | ("[",s) <- lex r,
pr <- readl s])
where readl s = [([],t) | ("]",t) <- lex s] ++
[(x:xs,u) | (x,t) <- reads s,
(xs,u) <- readl' t]
readl' s = [([],t) | ("]",t) <- lex s] ++
[(x:xs,v) | (",",t) <- lex s,
(x,u) <- reads t,
(xs,v) <- readl' u]

class Show a where

showsPrec :: Int -> a -> ShowS
showList :: [a] -> ShowS
showList [] = showString "[]"
showList (x:xs) = showChar '[' . shows x . showl xs
where showl [] = showChar ']'
showl (x:xs) = showString ", " . shows x .
showl xs

reads :: (Read a) => ReadS a

reads = readsPrec 0
104 A. STANDARD PRELUDE

shows :: (Show a) => a -> ShowS

shows = showsPrec 0

read :: (Read a) => String -> a

read s = case [x | (x,t) <- reads s, ("","") <- lex t] of
[x] -> x
[] -> error "PreludeText.read: no parse"
_ -> error "PreludeText.read: ambiguous parse"

show :: (Show a) => a -> String

show x = shows x ""

showChar :: Char -> ShowS

showChar = (:)

showString :: String -> ShowS

showString = (++)

showParen :: Bool -> ShowS -> ShowS

showParen b p = if b then showChar '(' . p . showChar ')' else p

readParen :: Bool -> ReadS a -> ReadS a

readParen b g = if b then mandatory else optional
where optional r = g r ++ mandatory r
mandatory r = [(x,u) | ("(",s) <- lex r,
(x,t) <- optional s,
(")",u) <- lex t ]
A.2 Prelude PreludeText 105

-- This lexer is not completely faithful to the Haskell lexical syntax.

-- Current limitations:
-- Qualified names are not handled properly
-- A `--' does not terminate a symbol
-- Octal and hexidecimal numerics are not recognized as a single token
lex :: ReadS String
lex "" = [("","")]
lex (c:s)
| isSpace c = lex (dropWhile isSpace s)
lex ('\'':s) = [('\'':ch++"'", t) | (ch,'\'':t) <- lexLitChar s,
ch /= "'" ]
lex ('"':s) = [('"':str, t) | (str,t) <- lexString s]
where
lexString ('"':s) = [("\"",s)]
lexString s = [(ch++str, u)
| (ch,t) <- lexStrItem s,
(str,u) <- lexString t ]
lexStrItem ('\\':'&':s) = [("\\&",s)]
lexStrItem ('\\':c:s) | isSpace c
= [("\\&",t) |
'\\':t <-
[dropWhile isSpace s]]
lexStrItem s = lexLitChar s

lex (c:s) | isSingle c = [([c],s)]

| isSym c = [(c:sym,t) | (sym,t) <- [span isSym s]]
| isAlpha c = [(c:nam,t) | (nam,t) <- [span isIdChar s]]
| isDigit c = [(c:ds++fe,t) | (ds,s) <- [span isDigit s],
(fe,t) <- lexFracExp s ]
| otherwise = [] -- bad character
where
isSingle c = c `elem` ",;()[]{}_`"
isSym c = isPrint c && not (isAlphaNum c) &&
not (isSingle c) && not (c `elem` "_'")
isIdChar c = isAlphanum c || c `elem` "_'"
lexFracExp ('.':c:cs) | isDigit c
= [('.':ds++e,u) | (ds,t) <- lexDigits (c:cs),
(e,u) <- lexExp t]
lexFracExp s = [("",s)]
lexExp (e:s) | e `elem` "eE"
= [(e:c:ds,u) | (c:t) <- [s], c `elem` "+-",
(ds,u) <- lexDigits t] ++
[(e:ds,t) | (ds,t) <- lexDigits s]
lexExp s = [("",s)]
106 A. STANDARD PRELUDE

instance Show Int where

showsPrec = showSigned showInt

instance Read Int where

readsPrec p = readSigned readDec

instance Show Integer where

showsPrec = showSigned showInt

instance Read Integer where

readsPrec p = readSigned readDec

instance Show Float where

showsPrec = showFloat

instance Read Float where

readsPrec p = readFloat

instance Show Double where

showsPrec = showFloat

instance Read Double where

readsPrec p = readFloat

instance Show () where

showsPrec p () = showString "()"

instance Read () where

readsPrec p = readParen False
(\r -> [((),t) | ("(",s) <- lex r,
(")",t) <- lex s ] )
instance Show Char where
showsPrec p '\'' = showString "'\\''"
showsPrec p c = showChar '\'' . showLitChar c . showChar '\''

showList cs = showChar '"' . showl cs

where showl "" = showChar '"'
showl ('"':cs) = showString "\\\"" . showl cs
showl (c:cs) = showLitChar c . showl cs
A.2 Prelude PreludeText 107

instance Read Char where

readsPrec p = readParen False
(\r -> [(c,t) | ('\'':s,t)<- lex r,
(c,'\'') <- readLitChar s])

readList = readParen False (\r -> [(l,t) | ('"':s, t) <- lex r,

(l,_) <- readl s ])
where readl ('"':s) = [("",s)]
readl ('\\':'&':s) = readl s
readl s = [(c:cs,u) | (c ,t) <- readLitChar s,
(cs,u) <- readl t ]

instance (Show a) => Show [a] where

showsPrec p = showList

instance (Read a) => Read [a] where

readsPrec p = readList

-- Tuples
instance (Show a, Show b) => Show (a,b) where
showsPrec p (x,y) = showChar '(' . shows x . showChar ',' .
shows y . showChar ')'

instance (Read a, Read b) => Read (a,b) where

readsPrec p = readParen False
(\r -> [((x,y), w) | ("(",s) <- lex r,
(x,t) <- reads s,
(",",u) <- lex t,
(y,v) <- reads u,
(")",w) <- lex v ] )

-- Other tuples have similar Read and Show instances

-- Functions
instance Show (a->b) where
showsPrec p f = showString "<<function>>"

instance Show (IO a) where

showsPrec p f = showString "<<IO action>>"
108 A. STANDARD PRELUDE
A.3 Prelude PreludeIO 109

A.3 Prelude PreludeIO

module PreludeIO (
FilePath, IOError, fail, userError, catch,
putChar, putStr, putStrLn, print,
getChar, getLine, getContents, interact,
readFile, writeFile, appendFile, readIO, readLn
) where

import PreludeBuiltin

type FilePath = String

data IOError -- The internals of this type are system dependent

instance Show IOError where ...

instance Eq IOError where ...

fail :: IOError -> IO a

fail = primFail

userError :: String -> IOError

userError = primUserError

catch :: IO a -> (IOError -> IO a) -> IO a

catch = primCatch

putChar :: Char -> IO ()

putChar = primPutChar

putStr :: String -> IO ()

putStr s = mapM_ s putChar

putStrLn :: String -> IO ()

putStrLn s = do putStr s
putStr "\n"

print :: Show a => a -> rIO ()

print x = putStrLn (show x)

getChar :: IO Char
getChar = primGetChar

getLine :: IO String
getLine = do c <- getChar
if c == '\n' then return "" else
do s <- getLine
return (c:s)
110 A. STANDARD PRELUDE

getContents :: IO String
getContents = primGetContents

interact :: (String -> String) -> IO ()

interact f = do s <- getContents
putStr (f s)

readFile :: FilePath -> IO String

readFile = primReadFile

writeFile :: FilePath -> String -> IO ()

writeFile = primWriteFile

appendFile :: FilePath -> String -> IO ()

appendFile = primAppendFile
-- raises an exception instead of an error
readIO :: Read a => String -> IO a
readIO s = case [x | (x,t) <- reads s, ("","") <- lex t] of
[x] -> return x
[] -> fail (userError "PreludeIO.readIO: no parse")
_ -> fail (userError
"PreludeIO.readIO: ambiguous parse")

readLn :: Read a => IO a

readLn = do l <- getLine
r <- readIO l
return r
 111

B Syntax
B.1 Notational Conventions
These notational conventions are used for presenting syntax:
[pattern ] optional
fpattern g zero or more repetitions
(pattern ) grouping
pat1 j pat2 choice
pathpat i dierence|elements generated by pat
0

except those generated by pat 0

fibonacci terminal syntax in typewriter font

BNF-like syntax is used throughout, with productions having the form:

nonterm ! alt1 j alt2 j : : : j altn
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 precedence-
level variable i ranges from 0 to 9; an associativity variable a varies over fl ; r ; n g. Thus,
for example
aexp ! ( exp i +1 qop (a ;i ) )
actually stands for 30 productions, with 10 substitutions for i and 3 for a .
In both the lexical and the context-free syntax, there are some ambiguities that are to
be resolved by making grammatical phrases as long as possible, proceeding from left to
right (in shift-reduce parsing, resolving shift/reduce con icts by shifting). In the lexical
syntax, this is the \consume longest lexeme" rule. In the context-free syntax, this means
that conditionals, let-expressions, and lambda abstractions extend to the right as far as
possible.

B.2 Lexical Syntax

program ! f lexeme j whitespace g
lexeme ! varid j conid j varsym j consym j literal j special j reservedop j reservedid
literal ! integer j oat j char j string
special ! (j)j,j;j[j]j_jj{j}
whitespace ! whitestu fwhitestu g
whitestu ! whitechar j comment j ncomment
whitechar ! newline j return j linefeed j vertab j formfeed
112 B. SYNTAX

j space j tab j UNIwhite

newline ! a newline (system dependent)
return ! a carriage return
linefeed ! a line feed
space ! a space
tab ! a horizontal tab
vertab ! a vertical tab
formfeed ! a form feed
uniWhite ! any UNIcode character dened as whitespace
comment ! -- fany g newline
ncomment ! {- ANYseq fncomment ANYseq g -}
ANYseq ! fANY ghfANY g ( {- j -} ) fANY gi
ANY ! any j newline j vertab j formfeed
any ! graphic j space j tab j nonbrkspc
graphic ! large j small j digit j symbol j special j : j " j '
small ! ASCsmall j UNIsmall
ASCsmall ! a j b j : : : j z
UNIsmall ! any Unicode lowercase letter
large ! ASClarge j UNIlarge
ASClarge ! A j B j : : : j Z
UNIlarge ! any uppercase or titlecase Unicode letter
symbol ! ASCsymbol j UNIsymbol
ASCsymbol ! ! j # j $ j % j & j * j + j . j / j < j = j > j ? j @
j \ j^j|j-j~
UNIsymbol ! Any Unicode symbol or punctuation
digit ! 0 j 1 j ::: j 9
udigit ! digit j UNIdigit
UNIdigit ! A Unicode numberic
octit ! 0 j 1 j ::: j 7
hexit ! digit j A j : : : j F j a j : : : j f

varid ! (small fsmall j large j udigit j ' j _g)hreservedid i

conid ! large fsmall j large j udigit j ' j _g
reservedid ! case j class j data j default j deriving j do j else
j j j j j
if import in infix infixl infixr instance j j
j j j j
let module newtype of then type where j j j
specialid ! j
as qualified hiding j
varsym ! ( symbol fsymbol j :g )hreservedopi
consym ! (: fsymbol j :g)hreservedopi
reservedop ! .. j :: j = j \ j | j <- j -> j @ j ~ j =>
B.3 Layout 113

specialop ! - j!
varid (variables)
conid (constructors)
tyvar ! varid (type variables)
tycon ! conid (type constructors)
tycls ! conid (type classes)
modid ! conid (modules)
qvarid ! [ modid . ] varid
qconid ! [ modid . ] conid
qtycon ! [ modid . ] tycon
qtycls ! [ modid . ] tycls
qvarsym ! [ modid . ] varsym
qconsym ! [ modid . ] consym
decimal ! digit fdigit g
octal ! octit foctit g
hexadecimal! hexit fhexit g
integer ! decimal
j 0o octal j 0O octal
j 0x hexadecimal j 0X hexadecimal
oat ! decimal . decimal [(e j E)[- j +]decimal ]
char ! ' (graphich' j \i j space j escapeh\&i) '
string ! " fgraphich" j \i j space j escape j gap g "
escape ! \ ( charesc j ascii j decimal j o octal j x hexadecimal )
charesc ! ajbjfjnjrjtjvj\j"j'j&
ascii ! ^cntrl j NUL j SOH j STX j ETX j EOT j ENQ j ACK
j BEL j BS j HT j LF j VT j FF j CR j SO j SI j DLE
j DC1 j DC2 j DC3 j DC4 j NAK j SYN j ETB j CAN
j EM j SUB j ESC j FS j GS j RS j US j SP j DEL
cntrl ! ASClarge j @ j [ j \ j ] j ^ j _
gap ! \ whitechar fwhitechar g \

B.3 Layout
Denitions: The indentation of a lexeme is the column number indicating the start of that
lexeme; the indentation of a line is the indentation of its leftmost lexeme. To determine
the column number, assume a xed-width font with this tab convention: tab stops are 8
characters apart, and a tab character causes the insertion of enough spaces to align the
current position with the next tab stop.
114 B. SYNTAX

In the syntax given in the rest of the report, layout lists are always preceded by the key-
word where, let, do, or of, and are enclosed within curly braces ({ }) with the individual
declarations separated by semicolons (;). Layout lists usually contain declarations, but do
and case introduce lists of other sorts. For example, the syntax of a let expression is:
let { decl1 ; decl2 ; ::: ; decln [;] } in exp
Haskell permits the omission of the braces and semicolons by using layout to convey the
same information. This allows both layout-sensitive and -insensitive styles of coding, which
can be freely mixed within one program. Because layout is not required, Haskell programs
can be straightforwardly produced by other programs.
The layout (or \o-side") rule takes eect whenever the open brace is omitted after the
keyword where, let, do, or of. When this happens, the indentation of the next lexeme
(whether or not on a new line) is remembered and the omitted open brace is inserted (the
whitespace preceding the lexeme may include comments). For each subsequent line, if it
contains only whitespace or is indented more, then the previous item is continued (nothing
is inserted); if it is indented the same amount, then a new item begins (a semicolon is
inserted); and if it is indented less, then the layout list ends (a close brace is inserted). A
close brace is also inserted whenever the syntactic category containing the layout list ends;
that is, if an illegal lexeme is encountered at a point where a close brace would be legal, a
close brace is inserted. The layout rule matches only those open braces that it has inserted;
an explicit open brace must be matched by an explicit close brace. Within these explicit
open braces, no layout processing is performed for constructs outside the braces, even if a
line is indented to the left of an earlier implicit open brace.
Given these rules, a single newline may actually terminate several layout lists. Also,
these rules permit:
f x = let a = 1; b = 2
g y = exp2
in exp1
making a, b and g all part of the same layout list.
To facilitate the use of layout at the top level of a module (an implementation may
allow several modules may reside in one le), the keyword module and the end-of-le token
are assumed to occur in column 0 (whereas normally the rst column is 1). Otherwise, all
top-level declarations would have to be indented.
Section 1.5 gives an example that uses the layout rule.
B.4 Context-Free Syntax 115

B.4 Context-Free Syntax

module ! module modid [exports ] where body
j body
body ! { [impdecls ;] [[xdecls ;] topdecls [;]] }
j { impdecls [;] }
impdecls ! impdecl1 ; : : : ; impdecln (n  1 )

exports ! ( export1 , : : : , exportn [ , ] ) (n  0 )

export ! qvar
j qtycon [(..) j ( qcname1 , : : : , qcnamen )] (n  0 )
j qtycls [(..) j ( qvar1 , : : : , qvarn )] (n  0 )
j module modid
qcname ! qvar j qcon

impdecl ! import [qualified] modid [as modid ] [impspec ]

impspec ! ( import1 , :::
, importn [ , ] ) (n  0 )
j hiding ( import1 , :::
, importn [ , ] ) (n  0 )
import ! var
j tycon [ (..) j ( cname1 , : : : , cnamen )] (n  1 )
j tycls [(..) j ( var1 , : : : , varn )] (n  0 )
cname ! var j con

xdecls ! x1 ; : : : ; xn (n  1 )
x ! infixl [digit ] ops
j infixr [digit ] ops
j infix [digit ] ops
ops ! op1 , : : : , opn (n  1 )

topdecls ! topdecl1 ; : : : ; topdecln (n  0 )

topdecl ! type simpletype = type
j data [context =>] simpletype = constrs [deriving ]
j newtype [context =>] simpletype = con atype [deriving ]
j class [context =>] simpleclass [where { cbody [;] }]
j instance [context =>] qtycls inst [where { valdefs [;] }]
j default (type1 , : : : , typen ) (n  0 )
j decl
116 B. SYNTAX

decls ! decl1 ; : : : ; decln (n  0 )

decl ! signdecl
j valdef
decllist ! { decls [;] }
signdecl ! vars :: [context =>] type
vars ! var1 , : : : , varn (n  1 )

type ! btype [-> type ] (function type)

btype ! [btype ] atype (type application)
atype ! gtycon
j tyvar
j ( type1 , : : : , typek ) (tuple type; k  2 )
j [ type ] (list type)
j ( type ) (parenthesized constructor)
gtycon ! qtycon
j () (unit type)
j [] (list constructor)
j (->) (function constructor)
j (,f,g) (tupling constructors)
context ! class
j ( class1 , : : : , classn ) (n  1 )
class ! qtycls tyvar
simpletype ! tycon tyvar1 : : : tyvark (k  0 )
constrs ! constr1 | : : : | constrn (n  1 )
constrs ! constr1 | : : : | constrn (n  1 )
constr ! con [!] atype1 : : : [!] atypek (arity con = k ; k  0 )
j (btype j ! atype ) conop (btype j ! atype ) (inx conop )
j con { elddecl1 , : : : , elddecln } (n  1 )
elddecl ! vars :: (type j ! atype )
deriving ! deriving (dclass j (dclass1 , : : : , dclassn ))(n  0 )
dclass ! qtycls

simpleclass ! tycls tyvar

cbody ! [ cmethods [ ; cdefaults ] ]
cmethods ! signdecl1 ; : : : ; signdecln (n  1 )
cdefaults ! valdef1 ; : : : ; valdefn (n  1 )
B.4 Context-Free Syntax 117

inst ! gtycon
j ( gtycon tyvar1 : : : tyvark ) (k  0 ; tyvars distinct)
j ( tyvar1 , : : : , tyvark ) (k  2 ; tyvars distinct)
j [ tyvar ]
j ( tyvar1 -> tyvar2 ) tyvar1 and tyvar2 distinct
valdefs ! valdef1 ; : : : ; valdefn (n  0 )

valdef ! lhs = exp [where decllist ]

j lhs gdrhs [where decllist ]
lhs ! pat 0
j funlhs
funlhs ! var apat f apat g
j pat i +1 varop (a ;i ) pat i +1
j lpat i varop ( l;i ) pat i +1
j pat i +1 varop ( r;i ) rpat i
gdrhs ! gd = exp [gdrhs ]
gd ! | exp 0

exp ! exp 0 :: [context =>] type (expression type signature)

j exp 0
exp i ! exp i +1 [qop ( n;i ) exp i +1 ]
j lexp i
j rexp i
lexp i ! (lexp i j exp i +1 ) qop ( l;i ) exp i +1
lexp 6 ! - exp 7
rexp i ! exp i +1 qop ( r;i ) (rexp i j exp i +1 )
exp 10 ! \ apat1 : : : apatn -> exp (lambda abstraction; n  1 )
j let decllist in exp (let expression)
j if exp then exp else exp (conditional)
j case exp of { alts [;] } (case expression)
j do { stmts [;] } (do expression)
j fexp
fexp ! [fexp ] aexp (function application)

aexp ! qvar (variable)

j gcon (general constructor)
j literal
j ( exp ) (parenthesized expression)
118 B. SYNTAX

j ( exp1 , : : : , expk ) (tuple; k  2 )

j [ exp1 , : : : , expk ] (list; k  1 )
j [ exp1 [, exp2 ] .. [exp3 ] ] (arithmetic sequence)
j [ exp | qual1 , : : : , qualn ] (list comprehension; n  1 )
j ( exp i +1 qop (a ;i ) ) (left section)
j ( qop (a ;i ) exp i +1 ) (right section)
j qcon { fbind1 , : : : , fbindn } (labeled construction; n  0 )
j aexpfqcon g { fbind1 , : : : , fbindn } (labeled update; n  1 )

qual ! pat <- exp

j let decllist
j exp
alts ! alt1 ; : : : ; altn (n  1 )
alt ! pat -> exp [where decllist ]
j pat gdpat [where decllist ]
gdpat ! gd -> exp [ gdpat ]
stmts ! exp [; stmts ]
j pat <- exp ; stmts
j let decllist ; stmts
fbinds ! { fbind1 , : : : , fbindn } (n  0 )
fbind ! var j qvar = exp

pat ! var + integer (successor pattern)

j pat 0
pat i ! pat i +1 [qconop ( n;i ) pat i +1 ]
j lpat i
j rpat i
lpat i ! (lpat i j pat i +1 ) qconop ( l;i ) pat i +1
lpat 6 ! - (integer j oat ) (negative literal)
rpat i ! pat i +1 qconop ( r;i ) (rpat i j pat i +1 )
pat 10 ! apat
j gcon apat1 : : : apatk (arity gcon = k ; k  1 )

apat ! var [ @ apat ] (as pattern)

j gcon (arity gcon = 0 )
j qcon { fpat1 , : : : , fpatk } (labeled pattern; k  0 )
j literal
B.4 Context-Free Syntax 119

j _ (wildcard)
j ( pat ) (parenthesized pattern)
j ( pat1 , : : : , patk ) (tuple pattern; k  2 )
j [ pat1 , : : : , patk ] (list pattern; k  1 )
j ~ apat (irrefutable pattern)
fpat ! var = pat
j var

gcon ! ()
j []
j (,f,g)
j qcon
var ! varid j ( varsym ) (variable)
qvar ! qvarid j ( qvarsym ) (qualied variable)
con ! conid j ( consym ) (constructor)
qcon ! qconid j ( qconsym ) (qualied constructor)
varop ! varsym j  varid (variable operator)
qvarop ! qvarsym j  qvarid (qualied variable operator)
conop ! consym j  conid (constructor operator)
qconop ! qconsym j  qconid (qualied constructor operator)
op ! varop j conop (operator)
qop ! qvarop j qconop (qualied operator)
120 C. LITERATE COMMENTS

C Literate comments
The \literate comment" convention, rst developed by Richard Bird and Philip Wadler for
Orwell, and inspired in turn by Donald Knuth's \literate programming", is an alternative
style for encoding Haskell source code. The literate style encourages comments by making
them the default. A line in which \>" is the rst character is treated as part of the program;
all other lines are comment. Within the program part, the usual \--" and \{- -}" comment
conventions may still be used. To capture some cases where one omits an \>" by mistake,
it is an error for a program line to appear adjacent to a non-blank comment line, where a
line is taken as blank if it consists only of whitespace.
By convention, the style of comment is indicated by the le extension, with \.hs"
indicating a usual Haskell le and \.lhs" indicating a literate Haskell le. Using this style,
a simple factorial program would be:
This program prompts the user for a number and prints the factorial
of that number:
> main :: IO ()
> main = do putStr "Enter a number: "
> l <- readLine
> putStr "n!= "
> print (fact (read l))
This is the factorial function.
> fact :: Integer -> Integer
> fact 0 = 1
> fact n = n * fact (n-1)

An alternative style of literate programming is particularly suitable for use with the
LaTeX text processing system. In this convention, only those parts of the literate program
that are entirely enclosed between \begin{code}: : :\end{code} delimiters are treated as
program text; all other lines are comment. It is not necessary to insert additional blank
lines before or after these delimiters, though it may be stylistically desirable. For example,
\documentstyle{article}
\begin{document}

\section{Introduction}

This is a trivial program that prints the first 20 factorials.

\begin{code}
main :: IO ()
main = print [ (n, product [1..n]) | n <- [1..20]]
\end{code}
\end{document}
 121

This style uses the same le extension. It is not advisable to mix these two styles in the
same le.
122 D. SPECIFICATION OF DERIVED INSTANCES

D Specication of Derived Instances

A derived instance is an instance declaration that is generated automatically in conjunction
with a data or newtype declaration. The body of a derived instance declaration is derived
syntacticly from the denition of the associated type. Derived instances are possible only
for classes known to the compiler: those dened in either the Prelude or a standard library.
In this appendix, we describe the derivation of classes dened by the Prelude.
If T is an algebraic datatype declared by:
data c => T u 1 : : : uk = K1 t11 : : : t1k1 |


| Kn tn1 : : : tnkn
deriving (C1 , : : : , Cm )

(where m  0 and the parentheses may be omitted if m = 1 ) then a derived instance

declaration is possible for a class C if these conditions hold:
1. C is one of Eq, Ord, Enum, Bounded, Show, or Read.
2. There is a context c 0 such that c 0 ) C tij holds for each of the constituent types tij .
3. If C is Bounded, the type must be either an enumeration (all constructors must by
nullary) or have only one constructor.
4. If C is Enum, the type must be an enumeration.
5. There must be no explicit instance declaration elsewhere in the program that makes
T u1 : : : uk an instance of C .
For the purposes of derived instances, a newtype declaration is treated as a data declaration
with a single constructor.
If the deriving form is present, an instance declaration is automatically generated for
T u1 : : : uk over each class Ci . If the derived instance declaration is impossible for any of
the Ci then a static error results. If no derived instances are required, the deriving form
may be omitted or the form deriving () may be used.
Each derived instance declaration will have the form:
instance (c , C10 u10 , : : : , Cj0 uj0 ) => Ci (T u1 : : : uk ) where { d }

where d is derived automatically depending on Ci and the data type declaration for T (as
will be described in the remainder of this section), and u10 through uj0 form a subset of u1
through uk . When inferring the context for the derived instances, type synonyms must be
expanded out rst. Free names in the declarations d are all dened in the Prelude; the
qualier `Prelude.' is implicit here. The remaining details of the derived instances for each
of the derivable Prelude classes are now given.
 123

Derived instances of Eq and Ord. The class methods automatically introduced by de-
rived instances of Eq and Ord are (==), (/=), compare, (<), (<=), (>), (>=), max, and min.
The latter seven operators are dened so as to compare their arguments lexicographically
with respect to the constructor set given, with earlier constructors in the datatype declara-
tion counting as smaller than later ones. For example, for the Bool datatype, we have that
(True > False) == True.

Derived comparisons always traverse constructors from left to right. These examples
illustrate this property:
(1,undefined) == (2,undefined) ) False
(undefined,1) == (undefined,2) ) ?

Derived instances of Enum Derived instance declarations for the class Enum are only
possible for enumerations. The nullary constructors are assumed to be numbered left-
to-right with the indices 0 through n ? 1. Enum introduces the class methods toEnum,
fromEnum, enumFrom, enumFromThen, enumFromTo, and enumFromThenTo, which are used to
dene arithmetic sequences as described in Section 3.10.
The toEnum and fromEnum operators map enumerated values to and from the Int type.
enumFrom n returns a list corresponding to the complete enumeration of n's type starting at
the value n. Similarly, enumFromThen n n' is the enumeration starting at n, but with second
element n', and with subsequent elements generated at a spacing equal to the dierence
between n and n'. enumFromTo and enumFromThenTo are as dened by the default class
methods for Enum (see Figure 5, page 67). For example, given the datatype:
data Color = Red | Orange | Yellow | Green deriving (Enum)

we would have:
[Orange..] == [Orange, Yellow, Green]
fromEnum Yellow == 2

Derived instances of Bounded. The Bounded class introduces the class methods minBound
and maxBound, which dene the minimal and maximal elements of the type. For an enumer-
ation, the rst and last constructors listed in the data declaration are the bounds. For a
type with a single constructor, the constructor is applied to the bounds for the constituent
types. For example, the following datatype:
data Pair a b = Pair a b deriving Bounded

would generate the following Bounded instance:

instance (Bounded a,Bounded b) => Bounded (Pair a b) where
minBound = Pair minBound minBound
maxBound = Pair maxBound maxBound
124 D. SPECIFICATION OF DERIVED INSTANCES

Derived instances of Read and Show. The class methods automatically introduced by
derived instances of Read and Show are showsPrec, readsPrec, showList, and readList.
They are used to coerce values into strings and parse strings into values.
The function showsPrec d x r accepts a precedence level d (a number from 0 to 10),
a value x, and a string r. It returns a string representing x concatenated to r. showsPrec
satises the law:
showsPrec d x r ++ s == showsPrec d x (r ++ s)

The representation will be enclosed in parentheses if the precedence of the top-level con-
structor operator in x is less than d. Thus, if d is 0 then the result is never surrounded in
parentheses; if d is 10 it is always surrounded in parentheses, unless it is an atomic expres-
sion. The extra parameter r is essential if tree-like structures are to be printed in linear
time rather than time quadratic in the size of the tree.
The function readsPrec d s accepts a precedence level d (a number from 0 to 10) and
a string s, and returns a list of pairs (x,r) such that showsPrec d x r == s. readsPrec
is a parse function, returning a list of (parsed value, remaining string) pairs. If there is no
successful parse, the returned list is empty.
showList and readList allow lists of objects to be represented using non-standard
denotations. This is especially useful for strings (lists of Char).
readsPrec will parse any valid representation of the standard types apart from lists, for
which only the bracketed form [. . . ] is accepted. See Appendix A for full details.
A precise denition of the derived Read and Show instances for general types is beyond
the scope of this report. However, the derived Read and Show instances have the following
properties:
 The result of show is a syntactically correct Haskell expression containing only con-
stants given the xity declarations in force at the point where the type is declared.
 The result of show is readable by read if all component types are readable. (This
is true for all instances dened in the Prelude but may not be true for user-dened
instances.)
 The instance generated by Read allows arbitrary whitespace between tokens on the
input string. Extra parenthesis are also allowed.
 The result of show contains only the constructor names dened in the data type,
parenthesis, and spaces. When labeled constructor elds are used, braces, commas,
eld names, and equal signs are also used. No leading or trailing spaces are generated.
Parenthesis are only added where needed. No line breaks are added.
 If a constructor is dened using labeled eld syntax then the derived show for that
constructor will this same syntax; the elds will be in the order declared in the data
declaration. The derived Read instance will use this same syntax: all elds must be
present and the declared order must be maintained.
D.1 An example 125

 If a constructor is dened in the inx style, the derived Show instance will also use
inx style. The derived Read instance will require that the constructor be inx.
The derived Read and Show instances may be unsuitable for some uses. Some problems
include:
 Circular structures cannot be printed or read by these instances.
 The printer loses shared substructure; the printed representation of an object may be
much larger that necessary.
 The parsing techniques used by the reader are very inecient; reading a large structure
may be quite slow.
 There is no user control over the printing of types dened in the Prelude. For example,
there is no way to change the formatting of oating point numbers.

D.1 An example
As a complete example, consider a tree datatype:
data Tree a = Leaf a | Tree a :^: Tree a
deriving (Eq, Ord, Read, Show)
Automatic derivation of instance declarations for Bounded and Enum are not possible, as Tree
is not an enumeration or single-constructor datatype. The complete instance declarations
for Tree are shown in Figure 8, Note the implicit use of default class method denitions|for
example, only <= is dened for Ord, with the other class methods (<, >, >=, max, and min)
being dened by the defaults given in the class declaration shown in Figure 5 (page 67).
126 D. SPECIFICATION OF DERIVED INSTANCES

infix 4 :^:
data Tree a = Leaf a | Tree a :^: Tree a

instance (Eq a) => Eq (Tree a) where

Leaf m == Leaf n = m==n
u:^:v == x:^:y = u==x && v==y
_ == _ = False

instance (Ord a) => Ord (Tree a) where

Leaf m <= Leaf n = m<=n
Leaf m <= x:^:y = True
u:^:v <= Leaf n = False
u:^:v <= x:^:y = u<x || u==x && v<=y
instance (Show a) => Show (Tree a) where
showsPrec d (Leaf m) = showParen (d >= 10) showStr
where
showStr = showString "Leaf " . showsPrec 10 m
showsPrec d (u :^: v) = showParen (d > 4) showStr
where
showStr = showsPrec 5 u .
showString " :^: " .
showsPrec 5 v
instance (Read a) => Read (Tree a) where
readsPrec d r = readParen (d > 4)
(\r -> [(u:^:v,w) |
(u,s) <- readsPrec 5 r,
(":^:",t) <- lex s,
(v,w) <- readsPrec 5 t]) r

++ readParen (d > 9)
(\r -> [(Leaf m,t) |
("Leaf",s) <- lex r,
(m,t) <- readsPrec 10 s]) r

Figure 8: Example of Derived Instances

 127

E Compiler Pragmas
Some compiler implementations support compiler pragmas, which are used to give additional
instructions or hints to the compiler, but which do not form part of the Haskell language
proper and do not change a program's semantics. This section summarizes this existing
practice. An implementation is not required to respect any pragma, but the pragma should
be ignored if an implementation is not prepared to handle it. Lexically, pragmas appear as
comments, except that the enclosing syntax is {-# #-}.

E.1 Inlining
decl ! {-# inline [digit ] qvars #-}
decl ! {-# notInline qvars #-}

The optional digit represents the level of optimization at which the inlining is to occur. If
omitted, it is assumed to be 0. A compiler may use a numeric optimization level setting
in which increasing level numbers indicate increasing amounts of optimization. Trivial
inlinings that have no impact on compilation time or code size should have an optimization
level of 0; more complex inlinings that may lead to slow compilation or large executables
should be associated with higher optimization levels.
Compilers will often automatically inline simple expressions. This may be prevented by
the notInline pragma.

E.2 Specialization
decl ! {-# specialize spec1 , : : : , speck #-} (k  1 )
spec ! vars :: type
Specialization is used to avoid ineciencies involved in dispatching overloaded functions.
For example, in
factorial :: Num a => a -> a
factorial 0 = 0
factorial n = n * factorial (n-1)
{-# specialize factorial :: Int -> Int,
factorial :: Integer -> Integer #-}
calls to factorial in that the compiler can detect that the parameter is either Int or
Integer will use specialized versions of factorial which do not involved overloaded nu-
meric operations.
128 E. COMPILER PRAGMAS

E.3 Optimization
decl ! optdecl
exp 0 ! optdecl exp 0
optdecl ! {-# optimize optd1 , : : : , optdk #-} (k  1 )
optd ! digit
j speed digit
j space digit
j compilationSpeed digit
j debug digit
The optimize pragma provides explicit control over the optimization levels of the compiler.
If used as a declaration, this applies to all values dened in the declaration group (and
recursively to any nested values). Used as an expression, it applies only to the prexed
expression. If no attribute is named, the speed attribute is assumed.
REFERENCES 129

References
[1] J. Backus. Can programming be liberated from the von Neumann style? A functional
style and its algebra of programs. CACM, 21(8):613{641, August 1978.
[2] H.B. Curry and R. Feys. Combinatory Logic. North-Holland Pub. Co., Amsterdam,
1958.
[3] L. Damas and R. Milner. Principal type schemes for functional programs. In Pro-
ceedings of the 9th ACM Symposium on Principles of Programming Languages, pages
207{212, Albuquerque, N.M., January 1982.
[4] R. Hindley. The principal type scheme of an object in combinatory logic. Transactions
of the American Mathematical Society, 146:29{60, December 1969.
[5] P. Hudak, J. Fasel, and J. Peterson. A gentle introduction to Haskell. Technical Report
YALEU/DCS/RR-901, Yale University, May 1996.
[6] Mark P. Jones. A system of constructor classes: overloading and implicit higher-order
polymorphism. Journal of Functional Programming, 5(1), January 1995.
[7] P. Peneld, Jr. Principal values and branch cuts in complex APL. In APL '81 Con-
ference Proceedings, pages 248{256, San Francisco, September 1981.
[8] J. Peterson (editor). The Haskell Library Report. Technical Report YALEU/DCS/RR-
1105, Yale University, May 1996.
[9] S.L. Peyton Jones. The Implementation of Functional Programming Languages.
Prentice-Hall International, Englewood Clis, New Jersey, 1987.
[10] Unicode Consortium. Unicode Character Data and Mappings. unicode.org.
[11] P. Wadler and S. Blott. How to make ad hoc polymorphism less ad hoc. In Proceedings
of the 16th ACM Symposium on Principles of Programming Languages, pages 60{76,
Austin, Texas, January 1989.
130 REFERENCES
Index
Index entries that refer to nonterminals in the Haskell syntax are shown in an italic font.
Code entities dened in the standard prelude (Appendix A) or in the Haskell Library
Report[8] are shown in typewriter font. Ordinary index entries are shown in a roman
font.

!!, 63, 96, 97 abbreviated module, 55

$, 63, 84, 90 abs, 74, 75, 85
&&, 64, 84, 90 abstract datatype, 37, 62
(), see trivial type and unit expression accumulate, 71, 89
*, 63, 73, 74, 84, 85 acos, 74, 86
**, 63, 74, 75, 84, 86 acosh, 74, 86
+, 63, 73, 74, 84, 85 aexp, 12, 16{18, 118
+, see also n +k pattern algebraic datatype, 36, 56, 122
++, 63, 70, 84, 89 all, 100
-, 63, 73, 74, 84, 85 alt, 20, 118
-, see also negation alts, 20, 118
., 63, 65, 84, 90 ambiguous type, 44
/, 63, 73, 74, 84, 86 and, 100
/=, 63, 68, 84 ANY, 7, 112
/=, 123 any, 7, 112
:, 63, 65, 84 any, 100
::, 24 ANYseq, 7, 112
<, 63, 68, 84 apat, 25, 119
<, 123 appendFile, 79, 110
<=, 63, 68, 84 application, 15
<=, 123 function, see function application
==, 63, 68, 84 operator, see operator application
==, 123 applyM, 89
>, 63, 68, 84 approxRational, 75, 76
>, 123 arctangent, 76
>=, 63, 68, 84 arithmetic operator, 73
>=, 123 arithmetic sequence, 17, 65
>>, 63, 70, 80, 84, 89 as-pattern (@), 25, 27
>>=, 63, 70, 80, 84, 89 ascii, 10, 113
@, see as-pattern ASCII character set, 6
[] (nil), 65 ASClarge, 7, 112
?, 13 ASCsmall, 7, 112
^, 63, 75, 84, 88 ASCsymbol, 7, 112
^^, 63, 75, 84, 88 asin, 74, 86
_, see wildcard pattern asinh, 74, 86
||, 63, 64, 84, 90 asTypeOf, 95
~, see irrefutable pattern atan, 74, 76, 86

131
132 INDEX

atan2, 75, 76, 88 comment, 7

atanh, 74, 86 end-of-line, 7
atype, 33, 116 nested, 7
comment, 7, 112
basic input/output, 78 compare, 68, 84, 123
binding, 31 con, 14, 119
function, see function binding concat, 89
pattern, see pattern binding concatMap, 101
simple pattern, see simple pattern bind- conditional expression, 16
ing conid, 8, 9, 113
body, 31, 55, 115 conop, 14, 119
Bool (datatype), 64, 90 const, 65, 90
boolean, 64 constr, 36, 116
Bounded (class), 71, 85 constrs, 36, 116
derived instance, 43, 123 constructed pattern, 26
instance for Char, 91 constructor class, v, 31
break, 99 constructor expression, 33
btype, 33, 116 consym, 8, 113
case expression, 20 context, 34
catch, 81, 109
context, 34, 116
cbody, 41, 117 context reduction, 49
cos, 74, 86
cdefaults, 41, 117
cosh, 74, 86
ceiling, 75, 76, 87
Char (datatype), 64, 91
cosine, 76
curry, 65, 94
Char (module), 103
char, 10, 113 Curry, Haskell B., iii
cycle, 98
character, 64
literal syntax, 10 data declaration, 22, 36
character set datatype, 36
ASCII, see ASCII character set abstract, see abstract datatype
transparent, see transparent charac- algebraic, see algebraic datatype
ter set declaration, see data declaration
charesc, 10, 113 recursive, see recursive datatype
class, 31, 41 renaming, see newtype declaration
class, 34, 116 dclass, 36, 116
class assertion, 34 decimal, 9, 113
class declaration, 41, 56 decl, 31, 47, 116
with an empty where part, 41 declaration, 31
class environment, 35 class, see class declaration
class method, 32, 41, 42 datatype, see data declaration
closure, 60 default, see default declaration
cmethods, 41, 117 xity, see xity declaration
cname, 57, 115 import, see import declaration
cntrl, 10, 113 instance, see instance declaration
coercion, 76
INDEX 133

within a class declaration, 41 superclass of Ord, 84

within a let expression, 19 error, 2, 13
within an instance declaration, 42 error, 13, 95
declaration group, 48 escape, 10, 113
decllist, 31, 116 Eval (class), 38, 71, 89
decls, 31, 116 superclass of Num, 85
decodeFloat, 75, 76, 87 even, 74, 87
default class method, 41, 42, 123, 125 exception handling, 80
default declaration, 44 exp i , 12, 117
dependency analysis, 48 exp, 12, 16, 19{21, 24, 117
derived instance, 43, see also instance dec- exp, 74, 75, 86
laration exponent, 75, 77, 87
deriving, 36, 116 exponentiation, 75
digit, 7, 112 export, 56, 115
div, 63, 73, 74, 84, 86 export list, 56
divMod, 74, 86 exports, 56, 115
do expression, iv, 21, 80 expression, 2, 11
do expressions, 70 case, see case expression
Double (datatype), 73, 75, 93 conditional, see conditional expression
drop, 99 let, see let expression
dropWhile, 99 simple case, see simple case expres-
sion
Either (datatype), 66, 92 type, see type expression
either, 66, 92 unit, see unit expression
elem, 63, 96, 101 expression type-signature, 24, 44
encodeFloat, 75, 77, 87
entity, 55 fail, 81, 109
Enum (class), 18, 44, 70, 85 False, 64
derived instance, 43, 123 fbind, 23, 118
instance for Char, 91 fbinds, 118
instance for Double, 93 fexp, 12, 15, 117
instance for Float, 93 eld label, see label, 37
superclass of Integral, 86 construction, 22
enumFrom, 70, 85, 123 selection, 22
enumFromThen, 70, 85, 123 update, 23
enumFromThenTo, 70, 85, 123 eld names, v
enumFromTo, 70, 85, 123 elddecl, 36, 116
environment FilePath (type synonym), 79, 109
class, see class environment filter, 89
type, see type environment x, 63, 115
EQ, 66 xdecls, 63, 115
Eq (class), 68, 72, 84 xity, 14
derived instance, 43, 123 xity declaration, 62
instance for Char, 91 flip, 65, 90
superclass of Num, 85 Float (datatype), 72, 75, 93
134 INDEX

oat, 9 getContents, 79, 110

floatDigits, 75, 76, 87 getLine, 79, 109
Floating (class), 72, 74, 86 graphic, 7, 112
superclass of RealFloat, 87 GT, 66
oating literal pattern, 27 gtycon, 33, 42, 116
floatRadix, 75, 76, 87 guard, 18, 20, 28
floatRange, 75, 76, 87 guard, 71, 89
floor, 75, 76, 87
foldl, 97 Haskell, iii, 1
foldl1, 97 Haskell implementations, vi
foldr, 97 Haskell kernel, 2
foldr1, 98 Haskell mailing list, vi
formal semantics, 1 Haskell web pages, vi
formfeed, 7, 112 head, 96
fpat, 25, 118 hexadecimal, 9, 113
fpats, 25, 118 hexit, 7, 112
Fractional (class), 14, 72, 74, 86 hiding, 58, 61
superclass of Floating, 86 Hindley-Milner type system, 2, 31, 48
superclass of RealFrac, 87 id, 65, 90
fromEnum, 70, 85, 123 identier, 8
fromInteger, 14, 73, 74, 85
if-then-else expression, see conditional ex-
fromIntegral, 75, 77, 88 pression
fromRational, 14, 73, 74, 86
impdecl, 57, 115
fromRealFrac, 75, 77, 88 impdecls, 55, 115
fst, 65, 94 import, 57, 115
function, 65 import declaration, 57
function binding, 46, 47 impspec, 57, 115
function type, 33, 34 init, 96
functional language, iii inlining, 127
Functor (class), 70, 88
input/output, iv
instance for [], 94 inst, 42, 117
instance for IO, 92 instance declaration, 42, see also derived
instance for Maybe, 91 instance
funlhs, 47, 117 importing and exporting, 59
gap, 10, 113 with an empty where part, 41
Int (datatype), 72, 75, 92
gcd, 74, 75, 88
Integer (datatype), 75, 92
gcon, 14, 119
gd, 20, 47, 117 integer, 9
gdpat, 20, 118 integer literal pattern, 27
Integral (class), 72, 74, 86
gdrhs, 47, 117
interact, 79, 110
generalization, 49
generalization order, 35 interface le, v
IO (datatype), 66, 92
generator, 18
IOError (datatype), 66, 109
getChar, 79, 109
irrefutable pattern, 19, 26, 28, 48
INDEX 135

iterate, 98 max, 68, 84, 123

maxBound, 71, 85, 123
Just, 66 maximum, 101
maxInt, 75
kind, 33, 34, 36, 39, 42, 53 Maybe (datatype), 66, 91
kind inference, 34, 36, 39, 42, 53 maybe, 66, 91
label, 22 method, see class method
lambda abstraction, 15 min, 68, 84, 123
large, 7, 112 minBound, 71, 85, 123
last, 96 minimum, 101
layout, 3, 113, see also o-side rule minInt, 75
lcm, 74, 75, 88 mod, 63, 73, 74, 84, 86
Left, 66 modid, 9, 55, 113, 115
length, 97 module, 55
let expression, 19 module, 31, 55, 115
in do expressions, 21 Monad (class), 21, 70, 89
in list comprehensions, 18 instance for [], 94
lex, 105 instance for Maybe, 91
lexeme, 7, 112 superclass of MonadZero, 89
lexical structure, 6 monad, iv, 21, 70, 78
lexp i , 12, 117 monad comprehension
lhs, 47, 117 special, see list comprehension
libraries, iv, 60 MonadPlus (class), 70, 89
linear pattern, 15, 25, 47 instance for [], 94
linearity, 15, 25, 47 instance for Maybe, 91
lines, 100 MonadZero (class), 21, 70, 89
list, 16, 33, 65 instance for [], 94
list comprehension, vi, 18, 65 instance for Maybe, 91
list type, 34 superclass of MonadPlus, 89
literal, 7, 112 monomorphic type variable, 29, 50, 51
literate comments, 120 monomorphism restriction, 51
log, 74, 75, 86 Moose, Bullwinkle J., vi
logarithm, 75 n +k pattern, v, 27
logBase, 74, 75, 86
longest lexeme rule, 8, 10 name
lookup, 101
qualied, see qualied name
lpat i , 25, 118 special, see special name
LT, 66
namespaces, 2, 9
ncomment, 7, 112
magnitude, 75 negate, 15, 73, 74, 85
Main (module), 55 negation, 13, 15, 16
main, 55 newline, 7, 112
map, 70, 88 newtype declaration, v, vi, 26, 29, 39
mapM, 71, 89 nonbrkspc, 7, 112
mapM_, 71, 89 not, 64, 90
136 INDEX

notElem, 63, 96, 101 irrefutable, 21, see irrefutable pattern

Nothing, 66 linear, see linear pattern
null, 96 n +k , see n +k pattern
Num (class), 14, 44, 72, 74, 85 refutable, see refutable pattern
superclass of Fractional, 86 pattern binding, 46, 48
superclass of Real, 85 pattern-matching, 24
number, 72 overloaded constant, 29
literal syntax, 9 pi, 74, 86
translation of literals, 14 polymorphic recursion, 46
Numeric (module), 103 polymorphism, 2
numeric type, 73 pragmas, 127
numericEnumFrom, 94 precedence, 36, see also xity
numericEnumFromThen, 94 pred, 85
numericEnumFromThenTo, 94 Prelude, 11
numericEnumFromTo, 94 implicit import of, 61
Prelude (module), 60, 61, 83
octal, 9, 113 PreludeBuiltin (module), 84, 109
octit, 7, 112 PreludeIO (module), 84, 109
odd, 74, 87 PreludeList (module), 83, 84, 96
o-side rule, 3, 114, see also layout PreludeText (module), 84, 103
op, 14, 63, 119 principal type, 35, 46
operator, 8, 15 print, 78, 109
operator application, 15 product, 101
ops, 63, 115 program, 7, 112
or, 100 program structure, 1
Ord (class), 68, 72, 84 properFraction, 75, 76, 87
derived instance, 43, 123 putChar, 78, 109
instance for Char, 91 putStr, 78, 109
superclass of Real, 85 putStrLn, 78, 109
Ordering (datatype), 66, 92
otherwise, 64, 90 qcname, 56, 115
overloaded functions, 31 qcon, 14, 119
overloaded pattern, see pattern-matching qconid, 9, 113
overloading, 41 qconop, 14, 119
ambiguous, 44 qconsym, 9, 113
defaults, 44 qop, 14, 15, 119
qtycls, 9, 113
pat i , 25, 118 qtycon, 9, 113
pat, 25, 118 qual, 18, 118
pattern, 20, 25 qualied name, 9, 58
@, see as-pattern
qualier, 18
_, see wildcard pattern
quantication, 34
constructed, see constructed pattern quot, 73, 74, 84, 86
failure-free, 21 quotRem, 74, 86
oating, see oating literal pattern qvar, 14, 119
integer, see integer literal pattern
INDEX 137

qvarid, 9, 113 scanl1, 97

qvarop, 14, 119 scanr, 98
qvarsym, 9, 113 scanr1, 98
section, 8, 16, see also operator applica-
Ratio (module), 84 tion
Read (class), 69, 103 semantics
derived instance, 43, 124 formal, see formal semantics
instance for [a], 107 separate compilation, 62
instance for Char, 107 seq, 71, 84, 89
instance for Double, 106 sequence, 71, 89
instance for Float, 106 Show (class), 69, 103
instance for Integer, 106 derived instance, 43, 124
instance for Int, 106 instance for [a], 107
read, 69, 104 instance for Char, 106
readFile, 79, 110 instance for Double, 106
readIO, 79, 110 instance for Float, 106
readLine, 79 instance for Integer, 106
readList, 69, 103, 124 instance for Int, 106
readLn, 110 instance for IO, 107
readParen, 104 superclass of Num, 85
ReadS (type synonym), 69, 103 show, 69, 104
reads, 69, 103 showChar, 104
readsPrec, 69, 103, 124 showList, 69, 103, 124
Real (class), 72, 74, 85 showParen, 104
superclass of Integral, 86 ShowS (type synonym), 69, 103
superclass of RealFrac, 87 shows, 69, 104
RealFloat (class), 75, 76, 87 showsPrec, 69, 103, 124
RealFrac (class), 75, 87 showString, 104
superclass of RealFloat, 87 sign, 75
recip, 74, 86 signature, see type signature
recursive datatype, 39 signdecl, 41, 45, 116
refutable pattern, 26 significand, 75, 77, 87
rem, 63, 73, 74, 84, 86 signum, 74, 75, 85
repeat, 98 simple pattern binding, 48
replicate, 98 simpleclass, 34, 117
reservedid, 8, 113 simpletype, 36, 38, 39, 116
reservedop, 8, 113 sin, 74, 86
return, 70, 89 sine, 76
reverse, 100 sinh, 74, 86
rexp i , 12, 117 small, 7, 112
Right, 66 snd, 65, 94
round, 75, 76, 87 space, 7, 112
rpat i , 25, 118 span, 99
scaleFloat, 75, 87
special, 7, 112
scanl, 97
special name, 8, 11
138 INDEX

specialid, 8 tuple, 17, 33, 65

specialop, 8 tuple type, 34
splitAt, 99 tycls, 9, 34, 113
sqrt, 74, 75, 86 tycon, 9, 113
standard prelude, 60, see also Prelude type, 2, 32, 35
stmts, 21, 118 ambiguous, see ambiguous type
strict, 71, 89 constructed, see constructed type
strictness annotations, v function, see function type
strictness ag, 37 list, see list type
strictness ags, 72 monomorphic, see monomorphic type
String (type synonym), 64, 91 numeric, see numeric type
string, 64 principal, see principal type
literal syntax, 10 trivial, see trivial type
transparent, see transparent string tuple, see tuple type
string, 10, 113 type, 33, 116
subtract, 87 type class, v, 2, 31, see class
succ, 85 type environment, 35
sum, 101 type expression, 33
superclass, 41 type renaming, see newtype declaration
symbol, 7, 112, 113 type signature, 35, 42, 45
synonym, see type synonym for an expression, see expression type-
syntax, 111 signature
type synonym, 38, 42, 56, 122, see also
tab, 7, 112 datatype
tail, 96 recursive, 39
take, 98 tyvar, 9, 34, 113
takeWhile, 99
tan, 74, 86 uncurry, 65, 94
tangent, 76 undefined, 13, 95
tanh, 74, 86 Unicode character set, vi, 6, 10
toEnum, 70, 85, 123 UNIlarge, 7, 112
toInteger, 86 UNIsmall, 7, 112
topdecl (class), 41 UNIsymbol, 7, 112
topdecl (data), 36 unit datatype, see trivial type
topdecl (default), 44 unit expression, 17
topdecl (instance), 42 UNIwhite, 7, 112
topdecl (newtype), 39 unlines, 100
topdecl (type), 38 until, 65, 95
topdecl, 31, 116 unwords, 100
topdecls, 31, 55, 116 unzip, 102
toRational, 74, 76, 85 unzip3, 102
trigonometric function, 76 userError, 109
trivial type, 17, 33, 65
True, 64
valdef, 41, 47, 117
truncate, 75, 76, 87
valdefs, 42, 117
value, 2
 INDEX 139

var, 14, 119

varid, 8, 9, 113
varop, 14, 119
vars, 45, 116
varsym, 8, 113
vertab, 7, 112
Void (datatype), 65, 90

whitechar, 7, 112
whitespace, 7, 112
whitestu, 7, 112
wildcard pattern (_), 25
words, 100
writeFile, 79, 110

zero, 70, 89
zip, 65, 101
zip3, 101
zipWith, 102
zipWith3, 102

View publication stats