to the functional programming community, Haskell programmers have
requested a number of new language features.  Most of these features
have been implemented and tested in the various Haskell systems and we
need on the part of the community.  This revision to the Haskell
report is much more substantial than previous ones: many significant
of Haskell, eliminating features which have been little used and
complicate the language.

The final version of the Haskell 1.3 is expected to be complete in
October, 1995.  A preliminary version of the report will be available
soon.  All significant changes to the Haskell language, as well as
their motivation, are described here.  We are still open to comments
and suggestions; please send mail to [EMAIL PROTECTED]
regarding Haskell 1.3.  I will be happy to answer any questions or
forward mail to either the Haskell mailing list or the 1.3 committee,
proposed extensions to Haskell is available on the web at

There will be some minor incompatibilities with Haskell 1.2.  These
should not be serious and implementors are encouraged to provide a

Overview

Haskell 1.3 introduces the following major features:
* Standardized libraries and a reduced prelude
* Constructor classes (as in Gofer)
* Strictness annotations in type definitions
* Simple records
* A new type mechanism
* Qualified names
* All names are now redefinable
* The character set has been expanded to ISO-8559-1

Many other smaller changes to Haskell 1.2 have also been made.  A
complete description of new, changed, and eliminated features follows.

Prelude Changes

Haskell 1.3 will make a number of minor changes to the standard prelude.
Many prelude functions will be moved to libraries, reducing the size
of the Haskell core language.  These changes will be described separately.

Standard Libraries

As Haskell has grown, many informal libraries of useful functions have
been created.  In Haskell 1.3, we have decided to standardize a set of
libraries to accompany the core language.  Some of the functions
formerly in the prelude are now in libraries, decreasing the size of
the core language and giving the user more names in the default
namespace.  We are dividing the Haskell report into two separate
documents: a language report and a library report.  The prelude, now a
little smaller, will be described in the language report.  The library
report will continue to evolve after the 1.3 language report is complete.
We have moved much of the I/O, complex and rational arithmetic, many
lesser used list functions, and arrays to the libraries and also
developed a number of completely new libraries.  An initial Haskell
library report will be available at the same time as the 1.3 language
report.

Constructor Classes

to use Gofer's constructor classes.  Since constructor
classes are well understood, widely used, and easily implemented we
remove the restriction that types be first order'.  That is, T
a' is a valid Haskell type, but t a' is not since
t' is a type variable.
Constructor classes increase the power of the class system.  For
example, this class definition uses constructor classes:

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

Here, the type variable m' must be instantiated to a polymorphic data
type, as in

f >>= g = concat (map g f)
return x = [x]

No changes to the expression language are necessary; constructor
classes are an extension of the type language only.

Constructor classes require an extra level of type information called
kinds'.  Before type inference, the compiler must perform kind
inference to compute a kinding for each type constructor.  Kinds are
much simpler than types and are not ordinarily noticed by the programmer.

The changes to Haskell required to support constructor classes are:

* The syntax of types includes type application.
* Built-in types have names: [] for lists, (->)
for arrow, and  (,) for tuples.  Using type application,
the type (,) a b' is identical to (a,b)'.
* Type constructors (but not type synonyms) can be partially applied.
* Type variables in interface files may be annotated with a kind.
This will not affect any type variables used by Haskell 1.2
programs.
* The basic monadic operations: >>, >>=,
and return, will be placed in the Monad class.
All monads will share the same basic operations.

Haskell systems.  We have chosen a fairly conservative, but extensible
basic design (an IO monad with error handling),
the details of which are documented at
This hasn't changed recently.
The old I/O systems (continuation & stream) have been totally
scrapped.  Most of the I/O system has been moved out to
libraries.

comprehensibility of programs that make heavy use of I/O.

Strict Constructors

To achieve reasonable efficiency, Haskell programmers often use
implementation-specific annotations to mark fields of data structures as
strict.  These strict components are evaluated when the structure is
created instead of delayed until demanded.  This avoids the extra
overhead involved with delays and can result in much more compact
structures.  To help improve efficiency, we now supply a
simple strictness annotation on the types in a data declaration (or
record declaration - see below).  Using !' in front of a type in a
data declaration marks a structure component as strict.  (The !'
symbol is not a keyword; it has no special meaning outside data
declarations).  Only top-level types may be marked as strict; using
!' elsewhere in a type is not allowed.  Any type in a structure
component may be marked as strict.

data Foo a = F Int !Bool a a

This declares F as a constructor containing four fields: a
(non-strict) Int, a strict Bool and two (non-strict)
polymorphic fields.

Fully polymorphic strictness implies that values of any type may be
evaluated when placed into a strict data structure.  There are
compelling arguments for preventing functions from being evaluated in
this manner.  Without going into detail about the problems associated
with forcing functions, we have chosen to prevent function
forcing by using a special class, Data, to explicitly mark type
variables which must not be instantiated as functions.  Every data
type, except ->, is a member of the Data class.
If we want to make a polymorphic component strict, we must add
a "Data" context to the declaration:

data Data a => Foo a = F Int !Bool !a a

The prelude will use strictness annotations in the definition of
Ratio and Complex, making these numeric types much
more efficient.   To avoid unnecessary propagation of the Data class,
it is a superclass of Num.

The functions strict' and seq' have been added to
the prelude to give the user additional control over evaluation.
While no strictness annotations have been proposed for functions,
these primitives can be used to implement strict evaluation when needed.

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

The seq function evaluates its first argument before
returning the second one.  strict turns an ordinary function
into a strict one.

Strict data constructors accumulate all arguments before evaluating
them:

data R = R !Int !Int

R x y = seq x (seq y (makeR x y)) -- just to show the semantics of R

y = R undefined  -- Not an error

Haskell 1.3 will not provide strictness annotations for functions.
These can be constructed explicitly using seq if needed.  We
are not sure how strictness should interact with partial application.

Records

The individual components of data types in Haskell 1.2 are completely
anonymous: the type definition only names the type and the
constructors, not the fields of a constructor.  It is
inconvenient to select from, construct, or modify values associated with
a constructor which has many components.  A number of more general
record structures have been proposed and implemented.  After much
discussion, we have decided to avoid the issues of inheritance or
object oriented programming for the moment and provide a simple syntax
which will allow the fields of a single-constructor data type to have
names.  Selection, construction, and update operations which use field
names are provided.  The layout rule applies to all uses of
{;} in the following syntax.

Records are declared using a new type declaration:

topdecl -> data [context =>] simple = con with {sig1;sig2; ...}  [deriving classes]
sig -> var1, ..., varn :: [!]type    n >= 1

Example:

date Point = Point with pointX, pointY :: Float deriving Text

This names a type, Point, a constructor, also Point,
and two fields: pointX and pointY.  Field names are
in the same namespace as other Haskell values; a field may not share a
name with other field names or variables in scope.  At present,
records are restricted to single constructor data types.

The field labels in the record can be used as selection functions.  In
this example, the functions

pointX, pointY :: Point -> Float

can be used to access the fields of a point.

Construction of a new record uses the constructor and a
with' clause to initialize fields.  Any fields which have
been marked as strict must be mentioned during construction.
Non-strict fields are initialized to bottom if not mentioned.

exp -> con with {fdef1,...,fdefn}    n >= 0
fdef -> var := exp

Example:

p = Point with
pointX := 1
pointY := 2

The with construct can also be used to (non-destructively) update
record values:

exp <- exp with {fdef1,...,fdefn}    n >= 1

Example:

q = p with pointX := pointX p + 1

The :=' operation can also be used by itself as an anonymous
update function:

exp -> var := exp

Example:

f :: Point -> Point
f = pointX := 1

Record types cannot be referenced in the pattern language.

Aside from the special syntax needed to access record fields, records
are ordinary algebraic data types.

The design of a record system for Haskell has been difficult.  There
are many obvious and useful extensions to the basic notion of records
which have been considered.  In the end, instead of endorsing any more
advanced record features (inheritance, object oriented programming,
defaulting field values on construction, enhanced polymorphism,
pattern matching) we have decided to introduce the bare minimum of new
functionality to the language.

New Types

Haskell users have often needed to declare a new name for an existing
type.  There were two ways of doing this: declaring a synonym, as in

type Foo = Int

or creating a type wrapper, as in

data Foo = Foo Int

This first approach has no runtime overhead, but does not distinguish
the new type from the old.  More seriously, instances cannot be attached to
the new type, only the old one.  The other approach incurs an

An additional type declaration will provide a more efficient way of
creating a new type from an existing one:

newtype context => simple = con type [deriving classes]

Examples:

newtype Foo = Foo Int deriving Text
newtype Bar a = Bar [a] deriving (Text,Eq)
newtype LongName = L Int

This new type is used in the same manner as a wrapper type and,
similarly, the type name need not match the constructor name.  The
constructor is used for explicit coercion between the new and existing
types.  Derived instances simply re-use instances already attached to
the existing type (except for Text, which prints the
constructor as it would for a wrapper type).

At first glance, it looks as though the newtype "Foo" could have been
defined using normal data types and strictness annotations.

data Foo = Foo !Int deriving Text

The difference between the two is rather subtle (but important):
* Using strictness annotations, evaluation of the field occurs when a
Foo is created.  That is:

case Foo undefined of Foo _ -> True = undefined

* Using newtype, evaluation of the field occurs when the field is
used.  That is

case Foo undefined of Foo _ -> True = True

*It is perfectly legal to write:

newtype ST s a = ST (s -> (s,a))

but not to write:

data    ST s a = ST !(s -> (s,a))

since that would require a Data context for function spaces.

Syntax:                            Expansion:
exp  -> do {stmt}
stmt -> exp                        exp
stmt -> pat <- exp ; stmt         exp >>= \pat -> do stmt
stmt -> exp ; stmt                 exp >> do stmt
stmt -> let decls ; stmt           let decls in do stmt

let
x = 1
y = 2
in x + y

as an abbreviation for:

let { x = 1; y = 2 } in x + y

By the same rules, it is possible to write:

do
x <- getInt
y <- getInt
return (x + y)

as an abbreviation for:

do {
x <- getInt;
y <- getInt;
return (x + y)
}

C programmers might prefer the latter.

As in a list comprehension, variables bound by patterns are scoped
over the following statements in the do.  Unlike list
comprehensions, pattern match failure results in a runtime error.  The
do has the same type as the last statement.

A let in a do is scoped over all remaining statements.  Note there is
no in; this distinguishes this from an ordinary let.

Haskell 1.3 omits several features from earlier proposals and
the Gofer implementation.  In particular, there is no support for "guards".

do
x <- foo
if even x
bar

The problem is that in some monads, guard failure should yield a zero
while in others it should cause an exception or even an error (with
an appropriate error message).  Fortunately, there's no need to wrestle
with these thorny semantic issues since it's trivial for programmers to
define and use their own "guard functions".

-- raise an error if condition fails.
assert :: Monad m => Bool -> String -> m ()
assert p msg = if p then return () else error ("Assertion failed: " ++ msg)

-- return a zero if condition fails.
guard :: MonadZero m => Bool -> m ()
guard p msg = if p then return () else zero

do
x <- foo
assert (even x) "foo didn't return an even result at line 32 of Bar.lhs"
y <- bar x
guard (x elem y)
return y

Qualified Names

Current Haskell practice is for all outside names to be brought into
scope using import'.  This has some disadvantages: renaming
is required to resolve name clashes between different modules and the
names themselves provide no hint of where they come from.  In the
worst case (infrequently used names which have been imported without
explicitly listing what is being imported), this forces programmers to
use grep (or similar technology) to locate the definition of the name.

Qualified names are built from a module name and a local name,
separated by a .'. Thus,
Prelude.foldr' refers to the foldr exported from
Prelude.  (Note that qualified names are not the same as
original names': an
original name uses the defining module; here, the exporting module is
named).  Qualified

* Using qualified names prevents or resolves name clashes between
different modules.
* Qualified names result in more readable code since import declarations
need not be consulted to find the defining module for a name.

A qualified name can be used for any entity.  Short names, omitting
the module and separating .' can be used only for locally defined
names, or for entities which are imported unqualified (i.e. ones
mentioned in an import declaration which does not use the "qualified"
keyword).

For example, the following import declaration brings a module name into scope,
but only for use with qualified names.  The module may be locally
renamed, allowing
a shorter or more descriptive module name to be used in the importing module,
or allowing the
imported module to change with minimal effect on the program.

topdecl -> import qualified con [as con]

Only modules brought into scope using a qualified import can appear in
qualified names.

Qualified names are defined in the lexical syntax.  Thus,
Foo.a' and Foo . a' are quite different.  No whitespace is permitted in
a qualified name.  Symbols may also be qualified: Prelude.+' is
an operator which can be used in exactly the same manner as +'.

Note that the .' operator presents a syntactic problem.  It causes
Foo..', which is widely used in export lists and occasionally in
arithmetic sequences, to parse as a qualified name instead of a usage
of the ..' token.  Inserting a space before the
..' will resolve this problem.

Redefinable Names

PreludeCore cannot be redefined in any way.  Since many operators,
like +, -, >, and ==, are defined in PreludeCore this has made some
users deeply unhappy --  this restriction prevents any sort of
alternative numeric class structure which uses the standard symbols,
for example.  There is no real reason for stealing all these names
>from the user; in Haskell 1.3 PreludeCore is no longer special: all
ordinary names are redefinable.  Special syntax will remain attached
to Prelude names; thus [x]' would always refer to lists as defined in
the Prelude.

As before, the Prelude module is implicitly
imported (in unqualified form) unless an explicit import is found.
There is also an implicit (and unavoidable) qualified import of the
Prelude which is used to define the meaning of various pieces of
syntactic sugar.  This eliminates the need to make PreludeCore symbols
immutable.
Since qualified names can always be used for imported entities,
any Prelude entities that the programmer has chosen to shadow
can still be referred to using Prelude.'.

Expanded Character Set

This change in character set supports both an expanded Char type at
execution time and a greatly increased vocabulary for constructing
program names.  Many new characters have been added to small',
large', and symbol' in the lexical syntax.  The
revised report will have full details.

C-T Rule relaxation

The C-T rule restricts the placement of instance declarations to the
module containing either the class or data type definition associated
with an instance.  This is unnecessarily restrictive and will be

The new restriction will be that no more than one instance for a given
class - datatype pair is allowed in a program.  (Sadly, there's little
hope of detecting violations of this rule before link time.)

The visibility of instance declarations presents a problem.  Unlike
classes or types, instances cannot be mentioned explicitly in export
lists.  Instead of changing the syntax of the export list, we have adopted a
simple rule: when a module exports a class or a type, any associated
instances in scope are also exported.  Thus, the module

module I where
import M(C,T)

instance C T where ...

would not export the instance C T.  On the other hand, adding
either C or T to the export list of I would
cause the instance to be exported from I.  Any module
importing C or T from I would have this instance
declaration in scope.  This will not break any existing applications
since instances must appear in the module defining C or
T and will thus be exported with them if they are used elsewhere.

Polymorphic Recursion

This is a simple extension to the type system which allows the user to
attach a more general type to a recursive function than would be
normally be inferred.  For example, in

f x y = if f True False then x else y

the type of f would normally be inferred as Bool -> Bool -> Bool'.
However, polymorphic recursion allows the user to add a type signature
to f such as f :: a -> a -> a' to give it a more general type.  While
polymorphic recursion is not likely to be needed by the average
Haskell user, it occasionally will prevent the type checker from
complaining about a quite sensible looking program.

Interface Files

The current report requires that interface files be transitively
closed and that the original names of all entities be supplied.  Such
interfaces are appropriate for compilers to generate, but are not
necessarily useful to the programmer.  Although individual compilers
can still support the old style of interface, the report will be
changed to allow interfaces which use exactly the same imports found
in the implementation.  Only locally defined entities need appear in
these interfaces.

List Comprehension Let Bindings

The syntax of list comprehensions is being expanded to include

qual -> let {decls}

(The absence of in' distinguishes this from a "let"-expression in a
guard).  These decls are scoped over the remaining qualifiers and the
generated expression.  Binding is irrefutable: pattern match failure
is a program error.  The expansion of this is trivial: it expands
directly into a conventional let.

Standard Annotations

A number of pragmas, already widely used, will be standardized.
Currently, the proposal calls for

{-# Inline f #-}
{-# NotInline f #-}
{-# Specialize f :: type #-}

Exact syntax has not yet been worked out.

Minor Syntax

Minor syntax changes include:

* There is a new syntax for hex and octal constants
* The interaction of layout and explicit braces has been clarified
* The types listed in a default declaration must always be in parentheses
* Empty export lists are now allowed
* Presymbols are gone; this allows "~" and "-" to be embedded in a symbol
* Modules with an omitted module name export only main'
* Extra commas are allowed in import / export / hiding lists
* Interfaces cannot use deriving'
* \begin{code} - \end{code} is now allowed in literate files
as an alternative to ">" ("Bird tracks")

A number of features have been removed from Haskell.

Import declarations no longer have a renaming clause.  Qualified
names should be used to handle name clashes.  This also removes the
need for the single name' rule (see Section 5.1.2 of the report).

n+k patterns are being removed from the language.  While this will no
doubt break some existing code, it removes a highly irregular case in
both the syntax and semantics.  (The convoluted decl syntax came as a
result something like x+1 = 2', which could either be an
infix definition of + or a pattern binding of x to
1.  The parse for  x+1 = 2' and (x+1) = 2' is completely different
at the moment!)

These issues are still being debated.

* The syntax for newtype' is not certain.  It would be possible to
fold this into an ordinary data declaration:

current:   newtype N a = N (T a)
proposed:  data N a as N (T a)  --? not sure of this syntax

Separate keywords would perhaps be less confusing.  On the other hand,
there is no distinction between these sorts of declarations in the
type language.
* Records could be
allowed for any constructor of a multi-constructor type.  If
multi-constructor types are used, pattern matching must be able to (at
least) discriminate on the constructor:

data R = R1 with f1 :: Int |
R2 with f2 :: Bool

f :: R -> Int
f x = case
R1 -> = f1 x   -- No fields allowed in pattern match
_ -> 0

f :: R -> Int
f (R1 with f1 <- f) = f  -- Allows pattern match against fields
f _ = 0

* Record updates could be either strict or lazy:

record Point = Point with pointX, pointY :: Int
a = pointX (undefined with pointX <- 1)

With a lazy implementation, a is 1, while with a
strict implementation a is undefined.   The lazy semantics
allow records to be created by adding slots to a totally uninitialized
value (undefined) while, to accomodate strict slots, the strict
semantics require an explicit record creation construct.
Mark Jones sums up the debate thusly:

Lazy semantics                      Strict semantics
--------------------                ----------------

Point is a first class value,       Point with ... is a language
the uninitialized record            construct for building new points

expr with fields is a construct     expr with fields is a construct
for updating a record, non-strict   for updating a record, strict in
in the expr part.                   the expr part.

Arguably more in-line with          Arguably, not an issue.

Performance hit in naive            Easier to obtain a relatively
implementations.                    efficient implementation.

At the naive implementation level, lazy semantics require fresh thunks
for all slots not being updated.  With the strict semantics, thunks in
the old record can be recycled.  Implementors wonder whether the naive
implementation can be easily optimized.

* The field name namespace issue is (perhaps) unresolved.  The
other candidate is ML style localized namespaces for field names.
This would allow for simpler field names (x instead of
pointX) but would make type inference more difficult.  Type
hints may be required to disambiguate field names.
* A qualified name could be made available either through an
explicit qualified import or via any mention of a module in an import.
Consider:

module Foo where
import M(x)
y = M.z + x

If explicit qualified imports are required, this would be an error
since there is no import qualified M(z) or just import
qualified M.
* Instead of a separate qualified import, module could be imported
with an empty list of entities:

import M()

This would allow M to be used as a qualifier.
* There is a proposal in the works to make export lists more
explicit, as in

module E (
module M(..),
class C,
type T(..),
instance M.C E.T,
N.v,
x
) where ...

This would avoid the syntax problem associated with M.. at
the moment.  It would also allow the class and type namespaces to
overlap.
* Pattern match failure inside do could be
a "zero" in a monad with zero instead of an error.  Unfortunately, the
IO monad does not have a true zero ( failWith "error" doesn't
quite work).  It would be possible to allow do syntax to be used
disallowing refutable patterns when the monad is not in
`