The Haskell 1.3 Report: Preface

Preface
(May 1, 1996)

" 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 , 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' , so some familiarity with functional languages is assumed.

Version 1.3 of the report was unveiled in 1996. It corrects some minor errors in the 1.2 report and adds important new functionality, especially for input/output. This new functionality is summarized in the following section. Unlike earlier versions of Haskell, version 1.3 is described in two separate documents: the Haskell Language Report (this document) and the Haskell Library Report.

Highlights

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 which reference fields by name rather than position are now available.
The newtype declaration defines a type which 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.

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@dcs.gla.ac.uk forwards mail to all subscribers of the Haskell list.
majordomo@dcs.gla.ac.uk 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, 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, Erik Meijer, 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 ; 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.

Next section: Introduction
The Haskell 1.3 Report

Preface (May 1, 1996)

Preface
(May 1, 1996)