Commit bc0f44e9 authored by Simon Peyton Jones's avatar Simon Peyton Jones
Browse files

Lexical mainly

parent b6ac497e
......@@ -16,10 +16,14 @@
<h1>Errata in the
<a href="http://haskell.cs.yale.edu/definition/">Haskell 98 Language Report</a></h1>
All references are to the original Haskell 98 Report, dated 1 Feburary 1999.
<ul>
<p><li> <strong>Title page</strong>. Remove "[editor]" from after John Hughes.
<p><li> <strong>Title page</strong>. Add the paragraph:
<p>
"Copyright (c) Simon Peyton Jones and John Hughes.
"Copyright (c) Simon Peyton Jones.
<p>
The authors intend this Report to belong to the entire Haskell
community, and so we grant permission to copy and
......@@ -50,6 +54,26 @@ useful guidelines for implementors of the language."
is a formally specified thing.)
<p><li> <strong>Page 5, Section 2.2, Lexical program structure; and Appendix B.2, p120.</strong>
<ul>
<li> Add <em>return</em>, <em>linefeed</em>, and <em>uniWhite</em> to the production for <em>ANY</em>.
<li> Replace the production for <em>lexeme</em> with:
<pre>
lexeme -> qvarid | qconid | qop | literal | special | reservedop | reservedid
</pre>
</ul>
(These changes, and the next one, justify the productions for <em>program</em> which claims that a program is
a sequence of lexemes and white space.)
<p><li> <strong>Page 7, Section 2.4, Identifiers and operators; and Appendix B.2, p121.</strong>
Add <em>dashes</em> to <em>reservedop</em> in the exclusion set of the
production for <em>varsym</em>. (This ensures that "<tt>--</tt>" and
"<tt>---</tt>" are not legal lexemes.
<p><li> <strong>Page 9, Section 2.4, Identifiers and operators; and Page 68, Section 5.5.1, Qualified names.</strong>
Move the first paragraph of 5.5.1, and the following table, and the paragraph starting "The qualifier does not change...",
to the end of Section 2.4. (These paragraphs deal with lexical matters, which do not belong in Chapter 5.)
<p><li> <strong>Page 9, Section 2.6, Character and String Literals.</strong>
In the production for "cntrl" replace "ASClarge" by "ascLarge".
......@@ -69,10 +93,6 @@ should be
size :: Stack a -> Int
</pre>
<p><li> [Aug 2001] <strong>Page 13, Section 3, Expressions.</strong>
Remove Table 1, and the associated paragraph beginning "As an aid to
understanding...". (The table causes more confusion than it clears up.)
<p><li> [July 2001] <strong>Page 12, Section 3, Expressions.</strong>
Replace the last two sentences of the first paragrah of the section by:
<p>
......@@ -85,9 +105,17 @@ comprehension is used."
<p>
(Clarification only.)
<p><li> [Aug 2001] <strong>Page 13, Section 3, Expressions.</strong>
Remove Table 1, and the associated paragraph beginning "As an aid to
understanding...". (The table causes more confusion than it clears up.)
<p><li> [Apr 2001] <strong>Page 14, Section 3.1, Errors.</strong> In the first sentence of
the section, after "indistinguishable" add "by a Haskell program".
<p><li> [Apr 2001] <strong>Page 15, Section 3.2, Variables, Constructors, Operators, and Literals.</strong>
Remove the paragraph starting "Qualified names may only ...", and the following example, and the
concluding paragraph starting "incorrectly uses a qualifier". (This is all covered in 2.4 and 5.5.1.)
<p><li> [July 2001] <strong>Page 20, Section 3.10, Arithmetic sequences.</strong>
In the second paragraph, in the sentence "For the type <tt>Integer</tt>,
arithmetic sequences have the following meaning...", replace "type <tt>Integer</tt>"
......@@ -118,9 +146,26 @@ Change the production for <em>stmts</em> to read:
That is, every list of statements must end in an expression, optionally
followed by a semicolon.
<p><li> [Aug 2001] <strong>Page ???, Section 3.15, Datatypes with Field Labels.</strong>.
<p><li> [Aug 2001] <strong>Page 24, Section 3.15, Datatypes with Field Labels.</strong>.
Add an example to illustrate the final point in para 2.
<p><li> [Aug 2001] <strong>Page 26, Section 3.15.3, Updates Using Field Labels</strong>.
In the translation box:
<ul>
<li> replace the first un-subscripted "C" by "C1", and the second by "Cj".
(The "1" and "j" should be subscripts of course!)
<li> Change "b" to "bs" in the "where..." part.
</ul>
<p><li> [Aug 2001] <strong>Page 31, Section 3.17.2, Informal Semantics of Case Expressions.</strong>
Replace the example at the foot of Page 31, following the paragraph "The guard semantics...",
with the following:
<pre>
f :: (Int,Int,Int) -> [Int] -> Int
f ~(x,y,z) [a] | (a == y) = 1
</pre>
(The previous example use boolean and, which is non-strict in its second argument!)
<p><li> [Apr 2001] <strong>Page 31,33, Figures 3 and 4, Semantics of Case Expressions.</strong>
Replace "completely new variable" by "new variable" in these two figures. (Some clauses
said "new" and some "completely new" which is misleadingly inconsistent.)
......@@ -128,7 +173,7 @@ said "new" and some "completely new" which is misleadingly inconsistent.)
<p><li> [Apr 2001] <strong>Page 33, Figure 4, Semantics of Case Expressions Part 2.</strong>
In clause (r) replace "e0" by "v" throughout.
<p><li> [Aug 2001] <strong>Page ???, Section 3.17.1, Patterns.</strong>.
<p><li> [Aug 2001] <strong>Page 28, Section 3.17.1, Patterns.</strong>.
Give an example to illustrate an illegal non-linear pattern.
<p><li> <strong>Page 40, Section 4.2.1, Algebraic Datatype Declarations.</strong>
......@@ -163,7 +208,17 @@ The new phrase is "if v appears only in constraints of the
form (C v) where C is a class". Without this condition the rest of the
sentence does not make sense.
<p><li> [Apr 2001] <strong>Page 53, Section 4.3.3.</strong> Replace "For example, these two function
<p><li> [Aug 2001] <strong>Page 51, Section 4.4.2, Fixity Declarations.</strong>
<ul>
<li> In the prodution for <em>gendecl</em> change <em>digit</em> to <em>integer</em>.
<li> Make the same change in the syntax at the start of Section 4 and in Appendix B.
<li> After "A fixity declaration gives the fixity and binding
precedence of one or more operators." add the sentence "The <em>integer</em> in a fixity declaration
must be in the range 0 to 9."
</ul>
(Previously, "digit" was used, and it isn't a lexeme.)
<p><li> [Apr 2001] <strong>Page 53, Section 4.4.3.</strong> Replace "For example, these two function
definitions are equivalent:", and the two lines of code that follow by:
<br>
"For example, these three function definitions are all equivalent:
......@@ -175,15 +230,6 @@ definitions are equivalent:", and the two lines of code that follow by:
(This change makes explicit that an infix operator with more than two arguments
can have all of them on the LHS.)
<p><li> [Aug 2001] <strong>Page ???, Section 4.4.2, Fixity Declarations.</strong>
<ul>
<li> In the prodution for <em>gendecl</em> change <em>digit</em> to <em>integer</em>.
<li> Make the same change in the syntax at the start of Section 4 and in Appendix B.
<li> After "A fixity declaration gives the fixity and binding
precedence of one or more operators." add the sentence "The <em>integer</em> in a fixity declaration
must be in the range 0 to 9."
</ul>
<p><li> [Apr 2001] <strong>Page 54, Section 4.4.3, subsection Function Bindings.</strong>
In the first translation scheme ("The general binding form for functions..."),
the <em>xn</em> should be <em>xk</em> (suitably subscripted in both cases!),
......@@ -257,6 +303,15 @@ The last example in the section should read:
import Foo as A(f)
</pre>
<p><li> <strong>Page 68, Section 5.5.1, Qualified names.</strong>
Replace the second example in the first bullet by:
<pre>
module M where
M.f x = ... -- ILLEGAL
g x = let M.y = x+1 in ... -- ILLEGAL
</pre>
(This just clarifies that qualifiers aren't legal in local decls either.)
<p><li> <strong>Page 69, Section 5.5.2, Name clashes.</strong>
At the very end of the section, add the following clarification:
<p>
......@@ -300,10 +355,10 @@ reference to <tt>null</tt> must also resolve the ambiguous use of <tt>null</tt>
just as <tt>A</tt> does. Thus there is little danger of accidentally shadowing
Prelude names."
<p><li> [Aug 2001] <strong>Page ???, Section 6.1.3, Lists.</strong> In the last sentence,
<p><li> [Aug 2001] <strong>Page 74, Section 6.1.3, Lists.</strong> In the last sentence,
after "@Monad@" add ", @Functor@". (The list type is an instance of @Functor@.)
<p><li> [May 2001] <strong>Page 74, Section 6.1.6, Tuples.</strong>
<p><li> [May 2001] <strong>Page 74, Section 6.1.4, Tuples.</strong>
Replace the first paragraph of this section with:
<p>
"Tuples are algebraic datatypes with special syntax, as defined
......@@ -323,7 +378,7 @@ of 7."
<p><li> [Apr 2001] <strong>Page 74, Section 6.1.6, Function Types.</strong>
Delete the sentence "Functions are an instance of the <tt>Show</tt> class but not <tt>Read</tt>".
<p><li> [Aug 2001] <strong>Page ???, Section 6.1.7, The IO and IOError Types.</strong>
<p><li> [Aug 2001] <strong>Page 75, Section 6.1.7, The IO and IOError Types.</strong>
In the second sentence, replace "<tt>Show</tt>" by "<tt>Functor</tt>".
(@IO@ is an instance of @Functor@, but not @Show@.)
......@@ -399,6 +454,9 @@ After the default method for <tt>enumFromTo</tt> add
enumFromThen x y = map toEnum [fromEnum x, fromEnum y ..]
</pre>
<p><li><strong>Page 95, Appendix A, Standard Prelude, class <tt>Floating</tt>.</strong>
Add <tt>asin, acos, atan</tt> to the comment giving the list of minimal complete definitions.
<p><li> [Apr 2001] <strong>Page 101, Appendix A, <tt>instance Monad IO</tt>.</strong>
Replace the definition of <tt>fail</tt> in <tt>instance Monad IO</tt> by
<pre>
......@@ -409,7 +467,7 @@ Replace the definition of <tt>fail</tt> in <tt>instance Monad IO</tt> by
<tt>instance Enum Float</tt>.</strong>
Replace "<tt>1.0</tt>" by "<tt>0.95</tt>".
<p><li> [Aug 2001] <strong>Page ???, Appendix A, instance of <tt>Monad IO</tt>.</strong>
<p><li> [Aug 2001] <strong>Page 101, Appendix A, instance of <tt>Monad IO</tt>.</strong>
Delete defintion for <tt> >> </tt>. (The default definition will do.)
<p> <li> [Apr 2001] <strong>Page 105, Appendix A.1, line 11.</strong>
......@@ -489,7 +547,7 @@ Replace the instances for <tt>Show Int</tt> and <tt>Read Int</tt> with
</pre>
The previous definitions (which are simply specifications, remember) failed on minInt.
<p><li> [Aug 2001] <strong>Page ???, Appendix B.3, Layout</strong>.
<p><li> [Aug 2001] <strong>Page 124, Appendix B.3, Layout</strong>.
Near the end of the sub-section, delete from "Another place where..." to the end of the
sub-section. (Note 5 covers the top-level case.)
......@@ -506,6 +564,23 @@ the empty string, resulting in the following:
</pre>
(The old, stronger, equation is simply false.)
<p><li> [Aug 2001] <strong>Page 138, Appendix E, Compiler pragmas</strong>.
<ul>
<li> Change <tt>inline</tt> to <tt>INLINE</tt>.
<li> Change <tt>notInline</tt> to <tt>NOINLINE</tt>.
<li> Change <tt>specialize</tt> to <tt>SPECIALIZE</tt>.
<li> Remove the optional digit from the <tt>INLINE</tt> pragma, and replace the first para of E.1 by:
<p>
"The <tt>INLINE</tt> pragma instructs the compiler to inline the specified variables
at their use sites.
Compilers will often automatically inline simple expressions. This
may be prevented by the <tt>NOINLINE</tt> pragma."
<p> <li> Delete the whole of E.3.
</ul>
(These changes simplify the pramga story, and bring it into line with what
is usually implemented.)
<p><li> [Apr 2001] <strong>Page 141, Bibliograpy</strong>.
Citation [4] should read "JR Hindley".
......@@ -528,9 +603,11 @@ Haskell 98 Programming Language, 1 February 1999".
<a href="http://haskell.cs.yale.edu/definition/">Haskell 98 Library Report</a></h1>
<ul>
<p><li> <strong>Title page</strong>. Remove "[editor]" from after John Hughes.
<p><li> <strong>Title page</strong>. Add the paragraph:
<p>
"Copyright (c) Simon Peyton Jones and John Hughes.
"Copyright (c) Simon Peyton Jones.
<p>
The authors intend this Report to belong to the entire Haskell
community, and so we grant permission to copy and
......
%
% $Header: /home/cvs/root/haskell-report/libraries/library.verb,v 1.6 2001/08/20 07:57:52 simonpj Exp $
% $Header: /home/cvs/root/haskell-report/libraries/library.verb,v 1.7 2001/08/23 16:16:57 simonpj Exp $
%
% NOTE:--------------------------------------------------------------
% The formatting of this report and the ``new font selection scheme''
......@@ -418,11 +418,11 @@
\vspace{.15in}
\begin{center} \large
\begin{tabular}{l@@{\hspace{5mm}}l}
Simon Peyton Jones$^8$ [editor] & John Hughes$^3$ [editor] \\
Lennart Augustsson$^9$ & Dave Barton$^7$ \\
Brian Boutel$^4$ & Warren Burton$^5$ \\
Joseph Fasel$^6$ & Kevin Hammond$^2$ \\
Ralf Hinze$^{12}$ & Paul Hudak$^1$ \\
Simon Peyton Jones$^8$ [editor] & Lennart Augustsson$^9$ \\
Dave Barton$^7$ & Brian Boutel$^4$ \\
Warren Burton$^5$ & Joseph Fasel$^6$ \\
Kevin Hammond$^2$ & Ralf Hinze$^{12}$ \\
Paul Hudak$^1$ & John Hughes$^3$ \\
Thomas Johnsson$^3$ & Mark Jones$^{14}$ \\
John Launchbury$^{14}$ & Erik Meijer$^{10}$ \\
John Peterson$^1$ & Alastair Reid$^{15}$ \\
......@@ -451,7 +451,7 @@ Authors' affiliations:
\end{quotation}
\vspace{.2in}
\begin{center}
Copyright (c) Simon Peyton Jones and John Hughes.
Copyright (c) Simon Peyton Jones.
\end{center}
{\em The authors intend this Report to belong to the entire Haskell
......
......@@ -169,6 +169,7 @@ class (Fractional a) => Floating a where
-- Minimal complete definition:
-- pi, exp, log, sin, cos, sinh, cosh
-- asin, acos, atan
-- asinh, acosh, atanh
x ** y = exp (log x * y)
logBase x y = log y / log x
......
%
% $Header: /home/cvs/root/haskell-report/report/decls.verb,v 1.5 2001/08/20 07:57:53 simonpj Exp $
% $Header: /home/cvs/root/haskell-report/report/decls.verb,v 1.6 2001/08/23 16:16:57 simonpj Exp $
%
%**<title>The Haskell 98 Report: Declarations</title>
%*section 4
......@@ -141,7 +141,7 @@ user-defined function. The first declaration above may be read
``@Int@ is an instance of the class @Num@ as witnessed by these
definitions (i.e.~class methods)\index{class method} for @(+)@ and @negate@.''
More examples of type and constructor classes can be found in
More examples of type classes can be found in
the papers by Jones \cite{jones:cclasses} or Wadler and Blott
\cite{wadler:classes}.
The term `type class' was used to describe the original \Haskell{} 1.0
......@@ -499,8 +499,7 @@ expressions---normal constructor application has higher precedence
than infix 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:
An algebraic datatype declaration has the form:
\[
"@data@ cx @=>@ T u_1 ... u_k @=@ K_1 t_{11} ... t_{1k_1} @|@ \cdots @|@ \
K_n t_{n1} ... t_{nk_n}"
......@@ -508,8 +507,12 @@ and constructors over that type and has the form:
where "cx" is a context.
%\index{context!in data declaration@@in {\tt data} declaration}
This declaration
introduces a new type constructor "T" with constituent data
constructors "K_1, ..., K_n" whose types are given by:
introduces a new \emph{type constructor} "T" with one or more constituent \emph{data
constructors} "K_1, ..., K_n".
\index{data constructor}\index{type constructor}
In this Report, the unqualified term ``constructor'' always means ``data constructor''.
The types of the data constructors are given by:
\[
"K_i :: \forall u_1 ... u_k.~ cx_i \Rightarrow t_{i1} \rightarrow \cdots \rightarrow t_{ik_i} \rightarrow (T u_1 ... u_k)"
\]
......
%
% $Header: /home/cvs/root/haskell-report/report/exps.verb,v 1.5 2001/08/20 07:57:53 simonpj Exp $
% $Header: /home/cvs/root/haskell-report/report/exps.verb,v 1.6 2001/08/23 16:16:57 simonpj Exp $
%
%*section 3
%**<title>The Haskell 98 Report: Expressions</title>
......@@ -78,6 +78,7 @@ aexp -> qvar & (\tr{variable})
\indexsyn{aexp}%
\indexsyn{fexp}%
% Removed Aug 2001: more misleading than helpful. SLPJ
% As an aid to understanding this grammar,
% Table~\ref{syntax-precedences} shows the relative precedence of
% expressions, patterns and definitions, plus an extended associativity.
......@@ -255,17 +256,19 @@ or constructor by enclosing it in parentheses. If "op" is an infix
operator, then an expression or pattern of the form \mbox{"x op y"} is
equivalent to {"@(@op@)@ x y"}.
Qualified names may only be used to reference an imported variable or
constructor (see Section~\ref{import})
but not in the definition of a new variable or constructor. Thus
\bprog
@
let F.x = 1 in F.x -- invalid
@
\eprog
incorrectly uses a qualifier in the definition of @x@, regardless of
the module containing this definition. Qualification does not affect
the nature of an operator: @F.+@ is an infix operator just as @+@ is.
% This para is covered by Section 2.4 and 5.5.1
% A qualified name may only be used to refer to a variable or
% constructor imported from another module (see Section~\ref{import}), or
% defined at the top level,
% but not in the definition of a new variable or constructor. Thus
% \bprog
% @
% let F.x = 1 in F.x -- invalid
% @
% \eprog
% incorrectly uses a qualifier in the definition of @x@, regardless of
% the module containing this definition. Qualification does not affect
% the nature of an operator: @F.+@ is an infix operator just as @+@ is.
Special syntax is used to name some constructors for some of the
built-in types, as found
......@@ -855,15 +858,18 @@ 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 individual alternatives. The matches are tried sequentially,
from top to bottom. The first successful match causes evaluation of
the corresponding alternative body, in the environment of the case
expression extended by the bindings created during the matching of
that alternative and by the "decls_i" associated with that
alternative. If no
match succeeds, the result is "\bot". Pattern matching is described
in Section~\ref{pattern-matching}, with the formal semantics of case
expressions in Section~\ref{case-semantics}.
against the individual alternatives. The alternatives are tried
sequentially, from top to bottom. If "e" matches the pattern in the
alternative, the guards for that alternative are tried sequentially
from top to bottom, in the environment of the case expression extended
by the bindings created during the matching of the pattern and by the
"decls_i" associated with that alternative. If one of the guards
evaluates to @True@, the corresponding right-hand side is evaluated.
If all the guards evaluate to @False@, matching continues with the
next alternative. If no match succeeds, the result is "\bot".
Pattern matching is described in Section~\ref{pattern-matching}, with
the formal semantics of case expressions in
Section~\ref{case-semantics}.
\subsection{Do Expressions}
\index{do expression}
......@@ -1051,14 +1057,14 @@ Using the prior definition of "pick",
\bt{lcl}
\struthack{17pt}%
"e" @{@ "bs" @}@ &=& @case@ "e" @of@\\
&&@ @"C_1 v_1 ... v_{k_1}" @->@ "C (pick^{C_1}_1 bs v_1) ... (pick^{C_1}_{k_1} bs v_{k_1})"\\
&&@ @"C_1 v_1 ... v_{k_1}" @->@ "C_1 (pick^{C_1}_1 bs v_1) ... (pick^{C_1}_{k_1} bs v_{k_1})"\\
&&@ @ ... \\
&&@ @"C_j v_1 ... v_{k_j}" @->@ "C (pick^{C_j}_1 bs v_1) ... (pick^{C_j}_{k_j} bs v_{k_j})"\\
&&@ @"C_j v_1 ... v_{k_j}" @->@ "C_j (pick^{C_j}_1 bs v_1) ... (pick^{C_j}_{k_j} bs v_{k_j})"\\
&&@ _ -> error "Update error"@\\
\et
\end{center}
where "\{C_1,...,C_j\}" is the set of constructors containing all labels
in "b", and "k_i" is the arity of "C_i".
in "bs", and "k_i" is the arity of "C_i".
}
Here are some examples using labeled fields:
\bprog
......@@ -1414,7 +1420,8 @@ particular, an otherwise irrefutable pattern
may be evaluated because of a guard. For example, in
\bprog
@
f ~(x,y,z) [a] | a && y = 1
f :: (Int,Int,Int) -> [Int] -> Int
f ~(x,y,z) [a] | (a == y) = 1
@
\eprog
% \bprog
......
%
% $Header: /home/cvs/root/haskell-report/report/haskell.verb,v 1.6 2001/08/20 07:57:53 simonpj Exp $
% $Header: /home/cvs/root/haskell-report/report/haskell.verb,v 1.7 2001/08/23 16:16:57 simonpj Exp $
%
% NOTE:--------------------------------------------------------------
......@@ -431,11 +431,11 @@
\vspace{.15in}
\begin{center} \large
\begin{tabular}{l@@{\hspace{5mm}}l}
Simon Peyton Jones$^8$ [editor] & John Hughes$^3$ [editor] \\
Lennart Augustsson$^9$ & Dave Barton$^7$ \\
Brian Boutel$^4$ & Warren Burton$^5$ \\
Joseph Fasel$^6$ & Kevin Hammond$^2$ \\
Ralf Hinze$^{12}$ & Paul Hudak$^1$ \\
Simon Peyton Jones$^8$ [editor] & Lennart Augustsson$^9$ \\
Dave Barton$^7$ & Brian Boutel$^4$ \\
Warren Burton$^5$ & Joseph Fasel$^6$ \\
Kevin Hammond$^2$ & Ralf Hinze$^{12}$ \\
Paul Hudak$^1$ & John Hughes$^3$ \\
Thomas Johnsson$^3$ & Mark Jones$^{14}$ \\
John Launchbury$^{14}$ & Erik Meijer$^{10}$ \\
John Peterson$^1$ & Alastair Reid$^{15}$ \\
......@@ -465,7 +465,7 @@ Authors' affiliations:
\vspace{.2in}
\begin{center}
Copyright (c) Simon Peyton Jones and John Hughes.
Copyright (c) Simon Peyton Jones.
\end{center}
{\em The authors intend this Report to belong to the entire Haskell
community, and so we grant permission to copy and distribute it for
......
......@@ -31,8 +31,6 @@
<div align=center>
<a href="http://research.microsoft.com/Users/simonpj">
Simon Peyton Jones</a> [editor], Microsoft Research, Cambridge <br>
<a href="http://www.cs.chalmers.se/~rjmh">
John Hughes</a> [editor], Chalmers University of Technology <br>
<a href="http://www.cs.chalmers.se/~augustss">
Lennart Augustsson</a>, Sandburst Corporation <br>
<a href="http://www.inmet.com/~dlb">
......@@ -49,6 +47,8 @@ Kevin Hammond</a>, University of St. Andrews <br>
Ralf Hinze</a>, University of Bonn <br>
<a href="http://www.cs.yale.edu/homes/hudak-paul.html">
Paul Hudak</a>, Yale University <br>
<a href="http://www.cs.chalmers.se/~rjmh">
John Hughes</a>, Chalmers University of Technology <br>
<a href="http://www.cs.chalmers.se/~johnsson">
Thomas Johnsson</a>, Chalmers University of Technology <br>
<a href="http://www.cse.ogi.edu/~mpj">
......@@ -67,7 +67,7 @@ Colin Runciman</a>, York University <br>
Philip Wadler</a>, Avaya Labs <br>
</div>
<p>
Copyright (c) Simon Peyton Jones and John Hughes.
Copyright (c) Simon Peyton Jones.
<br>
<em> The authors intend this Report to belong to the entire Haskell
community, and so we grant permission to copy and distribute it for
......
%
% $Header: /home/cvs/root/haskell-report/report/lexemes.verb,v 1.3 2001/08/14 07:48:25 simonpj Exp $
% $Header: /home/cvs/root/haskell-report/report/lexemes.verb,v 1.4 2001/08/23 16:16:57 simonpj Exp $
%
%*section 2
%**<title>Haskell 98 Lexical Structure</title>
......@@ -110,21 +110,21 @@ Comments\index{comment} are valid whitespace.
An ordinary comment\index{comment!end-of-line} begins with a sequence of
two or more consecutive dashes (e.g. @--@) and extends to the following newline.
\emph{The sequence of dashes must not be the prefix of a legal lexeme.}
For example, ``@-->@'' or ``@--|@'' do {\em not} begin
a comment, because both of these are legal lexemes.
\emph{The sequence of dashes must not form part of a legal lexeme.}
For example, ``@-->@'' or ``@|--@'' do {\em not} begin
a comment, because both of these are legal lexemes; however ``@--foo@''
does start a commment.
A nested comment\index{comment!nested} begins with ``@{-@''
and ends with ``@-}@''. No legal lexeme starts with ``@{-@'';
hence, for exmaple, ``@{---@'' starts a nested comment despite the trailing dashes.
The comment itself is not lexically analysed. Instead the first
unmatched occurrence of the string ``@-}@'' terminates the nested comment.
Nested comments may be
nested to any depth: any occurrence of the string ``@{-@'' within the nested
comment starts a new nested comment, terminated by ``@-}@''. Within
a nested comment, each ``@{-@'' is matched by a corresponding
occurrence of ``@-}@''.
unmatched occurrence of the string ``@-}@'' terminates the nested
comment. Nested comments may be nested to any depth: any occurrence
of the string ``@{-@'' within the nested comment starts a new 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 significance, and, in a
......@@ -227,11 +227,11 @@ four do not. Namespaces are also discussed in
Section~\ref{namespaces}.
\index{qualified name}
External names may optionally be {\em qualified} in certain
A name may optionally be {\em qualified} in certain
circumstances by prepending them with a module identifier. This
applies to variable, constructor, type constructor and type class
names, but not type variables or module names. Qualified
names are discussed in detail in Section~\ref{import}.
names are discussed in detail in Section~\ref{modules}.
@@@
qvarid -> [modid @.@] varid
qconid -> [modid @.@] conid
......@@ -246,6 +246,23 @@ qconsym -> [modid @.@] consym
\indexsyn{qtycls}%
\indexsyn{qvarsym}%
\indexsyn{qconsym}%
Since a qualified name is a lexeme, no spaces are
allowed between the qualifier and the name.
Sample lexical analyses are shown below.
\[\bto{|l|l|}
\hline
This & Lexes as this \\
\hline
@f.g@ & @f . g@ (three tokens) \\
@F.g@ & @F.g@ (qualified `g') \\
@f..@ & @f ..@ (two tokens) \\
@F..@ & @F..@ (qualified `.') \\
@F.@ & @F .@ (two tokens) \\
\hline\eto\]
The qualifier does not change the syntactic treatment of a name;
for example, @Prelude.+@ is an infix operator with the same fixity as the
definition of @+@ in the Prelude (Section~\ref{fixity}).
\subsection{Numeric Literals}\index{number!literal syntax}
\label{lexemes-numeric}
......@@ -353,7 +370,8 @@ String literals are actually abbreviations for lists of characters
\subsection{Layout}\index{layout}
\label{lexemes-layout}
\Haskell{} permits the omission of the braces and semicolons by
\Haskell{} permits the omission of the braces and semicolons used in several
grammar productions, by
using {\em layout} to convey the same information. This allows both
layout-sensitive and layout-insensitive styles of coding, which
can be freely mixed within one program. Because layout is
......
%
% $Header: /home/cvs/root/haskell-report/report/modules.verb,v 1.5 2001/08/20 07:57:53 simonpj Exp $
% $Header: /home/cvs/root/haskell-report/report/modules.verb,v 1.6 2001/08/23 16:16:57 simonpj Exp $
%
%**<title>The Haskell 98 Report: Modules</title>
%*section 5
......@@ -459,20 +459,7 @@ declarations can have an empty export list. For example
\subsubsection{Qualified names}\index{qualified name}
\label{qualifiers}
A {\em qualified name} is written as "modid"@.@"name".
Since qualifier names are part of the lexical syntax, no spaces are
allowed between the qualifier and the name.
Sample lexical analyses are shown below.
\[\bto{|l|l|}
\hline
This & Lexes as this \\
\hline
@f.g@ & @f . g@ (three tokens) \\
@F.g@ & @F.g@ (qualified `g') \\
@f..@ & @f ..@ (two tokens) \\
@F..@ & @F..@ (qualified `.') \\
@F.@ & @F .@ (two tokens) \\
\hline\eto\]
A {\em qualified name} is written as "modid"@.@"name" (Section~\ref{ids}).
A qualified name is brought into scope:
\begin{itemize}
......@@ -486,22 +473,18 @@ the qualified name of the entity being defined. Thus:
g x = M.f x x
@
\eprog
is legal. The {\em defining} occurrence must mention the unqualified name; therefore, it is
is legal. The {\em defining} occurrence must mention the {\em unqualified} name; therefore, it is
illegal to write
\bprog
@
module M where
M.f x = ...
M.f x = ... -- ILLEGAL
g x = let M.y = x+1 in ... -- ILLEGAL
@
\eprog
\item {\em By an @import@ declaration.} An @import@ declaration, whether @qualified@ or not,
always brings into scope the qualified name of the imported entity (Section~\ref{import}).
\end{itemize}
The qualifier does not change the syntactic treatment of a name;
for example, @Prelude.+@ is an infix operator with the same fixity as the
definition of @+@ in the Prelude (Section~\ref{fixity}).
Qualifiers may also be applied to
names imported by an unqualified import; this allows a qualified
import to be replaced with an unqualified one without forcing changes
......
%
% $Header: /home/cvs/root/haskell-report/report/pragmas.verb,v 1.1 2001/03/28 14:13:42 simonpj Exp $
% $Header: /home/cvs/root/haskell-report/report/pragmas.verb,v 1.2 2001/08/23 16:16:57 simonpj Exp $
%
%**<title>The Haskell 98 Report: Pragmas</title>
%*section E
......@@ -21,24 +21,26 @@ syntax is @{-#@ @#-}@.
\subsection{Inlining}
\index{inlining}
@@@
decl -> @{-#@ @inline@ [digit] qvars @#-}@
decl -> @{-#@ @notInline@ qvars @#-}@
decl -> @{-#@ @INLINE@ qvars @#-}@
decl -> @{-#@ @NOINLINE@ 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.
% 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.
The @INLINE@ pragma instructs the compiler to inline the specified variables
at their use sites.
Compilers will often automatically inline simple expressions. This
may be prevented by the @notInline@ pragma.
may be prevented by the @NOINLINE@ pragma.