The Haskell 1.4 Report
top | back | next | contents | function index
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 refractory. 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 unfortunate situation
in the functional programming community: there had come into being
more than a dozen non-strict, purely functional programming languages,
all similar in expressive 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 efforts: 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
satisfied these constraints:
- It should be suitable for teaching, research, and applications,
including building large systems.
- It should be completely described via the publication of a formal
syntax and semantics.
- It should be freely available. Anyone should be permitted to
implement the language and distribute it to whomever they please.
- It should be based on ideas that enjoy a wide consensus.
- 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.
This Report
This report is the official specification 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 first time, we distinguish between Prelude and Library
entities. Entities defined by the Prelude, a module named Prelude,
are in scope unless explicitly
hidden. Entities defined in library modules
are in scope only if that module is explicitly
imported. The library modules specified 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 definition.
-
We define 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 define a new type of handles, to mediate I/O operations on
files and other I/O devices. Handles are part of the I/O library.
-
We define 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.
Constructor Classes
Constructor classes are a natural generalization of the original Haskell
type system, supporting 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
efficient manner.
-
The components of a constructor may be labeled using field names.
Selection, construction, and update operations that
reference fields by name rather than position are now available.
-
The newtype declaration defines a type that renames an existing
datatype without changing the underlying object representation.
Unlike type synonyms, types defined by newtype are distinct from
their definition.
Improvements in the Module System
A number of substantial changes to the module system have been made.
Instead of renaming, qualified names are used to resolve
name conflicts. All names are now redefinable; there is no
longer a PreludeCore module containing names that cannot be
reused. Interface files are no longer specified 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:
- 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.
- Qualified names may now be used as field 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 fixity 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:
- haskell@haskell.org forwards mail to all subscribers of
the Haskell list.
- haskell-request@haskell.org is used to add and remove
subscribers from the mailing 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 bjm@wotsamatta.edu
Please do not send subscription requests direct to the mailing list.
- Each implementation has an email address for discussions of
specific 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:
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 Hallgren,
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 Plasmeijer,
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 influence of many noteworthy programming languages
developed over the years. Although it is difficult to pinpoint the
origin of many ideas, we particularly wish to acknowledge the
influence 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. (Miranda is a trademark of Research
Software Ltd.) Without these forerunners Haskell would not have
been possible.
The Haskell 1.4 Report
top | back | next | contents | function index
March 27, 1997