update from Haddock
[haskell-report.git] / report / intro.verb
1 %
2 % $Header: /home/cvs/root/haskell-report/report/intro.verb,v 1.7 2002/12/10 11:51:11 simonpj Exp $
3 %
4 %**<title>The Haskell 2010 Report: Introduction</title>
5 %*section 1
6 %**~header
7 \section{Introduction}
8 \label{introduction}
9
10 \Haskell{}\index{Haskell@@\Haskell{}} is a general purpose, purely functional
11 programming language incorporating many recent innovations in
12 programming language design.  \Haskell{} provides 
13 higher-order functions,
14 non-strict semantics, static polymorphic typing, user-defined
15 algebraic datatypes, pattern-matching, list comprehensions, a module
16 system, a monadic I/O system, and a rich set of primitive datatypes,
17 including lists,
18 arrays, arbitrary and fixed precision integers, and floating-point
19 numbers.  \Haskell{} is both the culmination
20 and solidification of many years of research on non-strict functional
21 languages.
22
23 % Although the initial emphasis was on standardization, \Haskell{}
24 % also has several new features that both simplify and
25 % generalize the design.  For example,
26 % \begin{enumerate}
27 % \item Rather than using {\em ad hoc} techniques for
28 % overloading,\index{overloading}
29 % \Haskell{} provides an explicit overloading facility, integrated with
30 % the polymorphic type system\index{type system}, that allows the
31 % precise definition of overloading behavior for any operator or function.
32
33 % \item The conventional notion of ``abstract data
34 % type''\index{abstract datatype}
35 % has been unbundled
36 % into two orthogonal components:
37 % data abstraction\index{data abstraction}
38 % and information hiding.\index{information hiding}
39
40 % \item \Haskell{} has a flexible I/O facility based on the use of
41 % monads~\cite{Imperative-Functional-Programming}.  The system supports
42 % most of the standard operations provided by conventional operating
43 % systems while retaining referential transparency within a program.
44
45 % \item Recognising the importance of arrays, \Haskell{} has a
46 % family of multidimensional non-strict immutable arrays\index{array}
47 % whose special interaction with list comprehensions provides a
48 % convenient ``array comprehension'' syntax for defining arrays
49 % monolithically.
50 % \end{enumerate}
51
52 This report defines the syntax for \Haskell{} programs and an
53 informal abstract semantics for the meaning of such
54 programs.
55 %; the formal abstract semantics is in preparation.%
56 \index{formal semantics}
57 We leave as implementation
58 dependent the ways in which \Haskell{} programs are to be
59 manipulated, interpreted, compiled, etc.  This includes such issues as
60 the nature of programming environments and
61 the error messages returned for undefined programs
62 (i.e.~programs that formally evaluate to $\bot$).
63
64 \subsection{Program Structure}\index{program structure}
65 \label{programs}
66
67 In this section, we describe the abstract syntactic and semantic structure of
68 \Haskell{}, as well as how it relates to the organization of the
69 rest of the report.
70 \begin{enumerate}
71 \item At the topmost level a \Haskell{} program is a set
72 of {\em modules}, described in Chapter~\ref{modules}.  Modules provide
73 a way to control namespaces
74 and to re-use software in large programs.
75
76 \item The top level of a module consists of a collection of
77 {\em declarations}, of which there are several kinds, all described
78 in Chapter~\ref{declarations}.  Declarations
79 define things such as ordinary values, datatypes, type
80 classes, and fixity information.
81
82 \item At the next lower level are {\em expressions}, described
83 in Chapter~\ref{expressions}.  An expression denotes a {\em value}
84 and has a {\em static type}; expressions are at the heart of
85 \Haskell{} programming ``in the small.''
86
87 \item At the bottom level is \Haskell{}'s {\em
88 lexical structure}, defined in Chapter~\ref{lexical-structure}.  The
89 lexical structure captures the concrete
90 representation of \Haskell{} programs in text files.
91
92 \end{enumerate}
93 This report proceeds bottom-up with respect
94 to \Haskell{}'s syntactic structure.
95
96 The chapters not mentioned above are
97 Chapter~\ref{basic-types-and-classes}, which
98 describes the standard built-in datatypes and classes in \Haskell{}, and
99 Chapter~\ref{io}, which discusses the I/O facility in \Haskell{}
100 (i.e.~how \Haskell{} programs communicate with the outside world).
101 Also, there are several chapters describing the Prelude,
102 the concrete syntax, literate programming, the specification of derived
103 instances, and pragmas supported by most \Haskell{} compilers.
104
105 Examples of \Haskell{} program fragments in running text are given
106 in typewriter font:
107 % highlighted with a vertical line to the left of the text:
108 % as in:
109 \bprog
110 @
111  let x = 1
112      z = x+y
113  in  z+1
114 @
115 \eprog
116 ``Holes'' in program fragments representing arbitrary
117 pieces of \Haskell{} code are written in italics, as in 
118 "@if@ e_1 @then@ e_2 @else@ e_3".  Generally the italicized names are
119 mnemonic, such as "e" for expressions, "d" for
120 declarations, "t" for types, etc.
121
122 \subsection{The \Haskell{} Kernel}
123 \index{Haskell kernel@@\Haskell{} kernel}
124 \label{intro-kernel}
125
126 \Haskell{} has adopted many of the convenient syntactic structures
127 that have become popular
128 in functional programming.  In this Report, the meaning of such
129 syntactic sugar is given by translation into simpler constructs.
130 If these translations are applied exhaustively, the result is a program
131 written in a small subset of Haskell that we call the \Haskell{} {\em kernel}.
132
133 Although the kernel is not formally specified, it is essentially a
134 slightly sugared variant of the lambda calculus with a straightforward
135 denotational semantics.  The translation of each syntactic structure
136 into the kernel is given as the syntax is introduced.  This modular
137 design facilitates reasoning about \Haskell{} programs and provides
138 useful guidelines for implementors of the language.
139
140 % In specifying the translation of special syntax, named entities are
141 % often referred to ``as defined in the standard prelude.''  This means
142 % that even if these names are rebound (i.e.~the standard prelude name
143 % is not currently in scope), the translation still takes on the meaning
144 % as defined in the standard prelude.  In other words, the meaning of
145 % \Haskell{}'s syntax is invariant.
146
147 \subsection{Values and Types}
148 \index{value}\index{type}
149 \label{errors}\index{error}
150
151 An expression\index{expression} evaluates to a {\em value} and has a
152 static {\em type}.  Values and types are not mixed in
153 \Haskell{}.
154 However, the type system
155 allows user-defined datatypes of various sorts, and permits not only
156 parametric polymorphism\index{polymorphism} (using a
157 traditional Hindley-Milner\index{Hindley-Milner type system} type structure) but
158 also {\em ad hoc} polymorphism, or {\em overloading} (using
159 {\em type classes}).\index{type class}
160
161 Errors in \Haskell{} are semantically equivalent to
162 $\bot$.  Technically, they are not distinguishable
163 from nontermination, so the language includes no mechanism
164 for detecting or acting upon errors.  However, implementations
165 will probably try to provide useful information about
166 errors.  See Section~\ref{basic-errors}.
167
168
169 \subsection{Namespaces}
170 \index{namespaces}
171 \label{namespaces}
172
173 There are six kinds of names in \Haskell{}: those for {\em variables} and
174 {\em constructors} denote values; those for {\em type variables}, {\em
175 type constructors}, and {\em type classes} refer to entities related
176 to the type system; and {\em module names} refer to modules.
177 There are two constraints on naming:\nopagebreak[4]
178 \begin{enumerate}
179 \item Names for variables and type variables are identifiers beginning
180       with lowercase letters or underscore; the other four kinds of names are
181       identifiers beginning with uppercase letters.
182 \item An identifier must not be used as the name of a type constructor
183       and a class in the same scope.
184 \end{enumerate}
185 These are the only constraints; for example,
186 @Int@ may simultaneously be the name of a module, class, and constructor
187 within a single scope.
188
189
190 %\subsection{Conformance}
191
192 %A strictly-conforming \Haskell{} implementation implements this
193 %language definition completely and exactly.  A mostly-conforming
194 %\Haskell{} implementation implements a large subset of this
195 %definition, and provides full and complete documentation of any
196 %extensions to or deviations from the specification given here.  For
197 %any conforming implementation, all implementation dependencies which
198 %are allowed by the standard must be explicitly documented.
199
200 %**~footer
201 % Local Variables: 
202 % mode: latex
203 % End: