Removed scala latex documentation from the scal...

Removed scala latex documentation from the scala core module.

16 files changed, 0 insertions, 14392 deletions

diff --git a/doc/introduction/Makefile b/doc/introduction/Makefile
deleted file mode 100644
index 3bcb5d75cc..0000000000
--- a/doc/introduction/Makefile
+++ /dev/null
@@ -1,163 +0,0 @@
-############################################################-*-Makefile-*-####
-# Scala Introduction
-##############################################################################
-# $Id$
-
-##############################################################################
-# Configuration
-
-ROOT			 = ../..
-
-include $(ROOT)/Makefile.import
-
-##############################################################################
-# Variables
-
-WEBSITE_PROJECT_ROOT	?= $(ROOT)/../scala-website
-WEBSITE_SOURCEDIR	?= $(WEBSITE_PROJECT_ROOT)/sources
-
-# project
-PROJECT_SOURCES		+= default.dtd
-PROJECT_SOURCES		+= $(XML_SOURCES)
-
-PROJECT_XSLFILE		 = ScalaIntro.xsl
-PROJECT_BUILDDATE	 = $(shell date "+%B %d, %Y")
-
-#XML_SOURCES		+= index.xml
-#XML_SOURCES		+= $(shell cd $(WEBSITE_SOURCEDIR); ls intro/*.xml)
-
-# We preserve section order of PDF document generated by Acrobat
-XML_FILES		+= index
-XML_FILES		+= intro/unifiedtypes
-XML_FILES		+= intro/classes
-XML_FILES		+= intro/traits
-XML_FILES		+= intro/subclassing
-XML_FILES		+= intro/mixin
-XML_FILES		+= intro/funsyntax
-XML_FILES		+= intro/hofuns
-XML_FILES		+= intro/funnesting
-XML_FILES		+= intro/currying
-XML_FILES		+= intro/caseclasses
-XML_FILES		+= intro/patmatch
-XML_FILES		+= intro/xml
-XML_FILES		+= intro/regexppat
-XML_FILES		+= intro/comprehensions
-XML_FILES		+= intro/generics
-XML_FILES		+= intro/variances
-XML_FILES		+= intro/upbounds
-XML_FILES		+= intro/lowbounds
-XML_FILES		+= intro/innerclasses
-XML_FILES		+= intro/abstracttypes
-XML_FILES		+= intro/compoundtypes
-XML_FILES		+= intro/selfrefs
-XML_FILES		+= intro/views
-XML_FILES		+= intro/polymethods
-XML_FILES		+= intro/inference
-XML_FILES		+= intro/operators
-XML_FILES		+= intro/targettyping
-XML_FILES		+= intro/coercions
-XML_SOURCES		+= $(XML_FILES:%=%.xml)
-
-PNG_FILES		+= images/classhierarchy
-PNG_FILES		+= images/colpoint2d
-PNG_FILES		+= images/colpoint3d
-PNG_FILES		+= images/scala_logo
-PNG_SOURCES		+= $(PNG_FILES:%=%.png)
-
-# latex
-LATEX_FORMATS		+= dvi
-LATEX_FORMATS		+= ps
-LATEX_FORMATS		+= pdf
-
-LATEX_TARGETS		+= $(LATEX_FORMATS:%=ScalaIntro.%)
-
-LATEX_SOURCES		+= MainPart.tex
-LATEX_SOURCES		+= ScalaIntro.tex
-
-# latex
-TEXINPUTS		:= $(PROJECT_SUPPORTDIR)/latex:$(TEXINPUTS):
-
-##############################################################################
-# Includes
-
-include $(PROJECT_SUPPORTDIR)/make/latex.mk
-
-AWK			?= awk
-CYGWIN			?= $(filter CYGWIN%,$(shell uname))
-
-##############################################################################
-# XSLT processor
-
-XSLTPROC		?= xsltproc
-XSLTPROC_FLAGS		+=
-
-##############################################################################
-# convert
-
-CONVERT			?= convert
-CONVERT_FLAGS		+= -sharpen 0.1 -flatten -trim
-
-##############################################################################
-# PDF viewer
-
-ACROREAD_WIN32		?= c:/Progra~1/Adobe/Acrobat\ 7.0/Reader/AcroRd32.exe
-ACROREAD_UNIX		?= acroread
-
-PDF_VIEWER		?= $(if $(CYGWIN),$(ACROREAD_WIN32),$(ACROREAD_UNIX))
-
-##############################################################################
-# PS viewer
-
-GSVIEW_WIN32		?= gsview32
-GSVIEW_UNIX		?= gv
-
-PS_VIEWER		?= $(if $(CYGWIN),$(GSVIEW_WIN32),$(GSVIEW_UNIX))
-
-##############################################################################
-# Commands
-
-clean:
-	@$(RM) -r images intro MainPart.tex default.dtd index.xml ScalaIntro.out
-
-view: viewpdf
-
-viewpdf: ScalaIntro.pdf
-	$(PDF_VIEWER) $< &
-
-viewps: ScalaIntro.ps
-	$(PS_VIEWER) $< &
-
-.PHONY: clean
-.PHONY: view
-.PHONY: viewpdf
-.PHONY: viewps
-
-##############################################################################
-# Rules
-
-images		:
-	@[ -d $@ ] || $(MKDIR) -p $@
-	for file in $(PNG_SOURCES); do \
-	  $(CONVERT) $(CONVERT_FLAGS) \
-	    PNG:$(WEBSITE_SOURCEDIR)/$$file EPS:images/`$(BASENAME) $$file .png`.eps; \
-	  $(CONVERT) $(CONVERT_FLAGS) \
-	    PNG:$(WEBSITE_SOURCEDIR)/$$file PDF:images/`$(BASENAME) $$file .png`.pdf; \
-	done
-
-intro		:
-	@[ -d $@ ] || $(MKDIR) -p $@
-	@for file in $(PROJECT_SOURCES); do \
-	  $(AWK) '/<src/{on=1};/<\/src>/{on=0};{if(on){gsub("{","\\{");gsub("}","\\}")};print $0}' \
-	    $(WEBSITE_SOURCEDIR)/$$file > $$file; \
-	done
-
-MainPart.tex	: images intro $(PROJECT_XSLFILE)
-	$(ECHO) "%% Generated file: $@" > $@
-	$(ECHO) "%% Build date    : $(PROJECT_BUILDDATE)" >> $@
-	$(XSLTPROC) $(XSLTPROC_FLAGS) $(PROJECT_XSLFILE) $(XML_SOURCES) | \
-	  $(SED) -e 's/% 2/\\% 2/g' | \
-	  $(SED) -e 's/<%/<\\%/g' | \
-	  $(SED) -e 's/#Node/\\#Node/g' | \
-	  $(SED) -e 's/{_/{\\_/g' >> $@
-
-##############################################################################
diff --git a/doc/introduction/ScalaIntro.tex b/doc/introduction/ScalaIntro.tex
deleted file mode 100644
index 9498b987d8..0000000000
--- a/doc/introduction/ScalaIntro.tex
+++ /dev/null
@@ -1,52 +0,0 @@
-% $Id$
-
-\documentclass[a4paper,12pt,twoside,titlepage]{book}
-
-\usepackage{alltt}% Verbatim extended with the ability to use normal commands
-\usepackage{color}
-\usepackage{scaladoc}
-\usepackage{url}
-
-\newcommand{\docversion}{1.1}
-\renewcommand{\doctitle}{An Introduction \\ to Scala}
-\renewcommand{\docsubtitle}{Version \docversion}
-\renewcommand{\docauthor}{Martin Odersky \\
-Philippe Altherr \\
-Vincent Cremet \\
-Burak Emir \\ 
-St\'ephane Micheloud \\
-Nikolay Mihaylov \\
-Michel Schinz \\
-Erik Stenman \\
-Matthias Zenger \\[25mm]\ }
-
-\newcommand{\langname}[1]{#1{}}
-\newcommand{\CSharp}{\langname{C\#}}
-\newcommand{\DotNet}{\langname{.NET}}
-\newcommand{\Scala}{\langname{Scala}}
-
-\renewcommand{\sectionmark}[1]{%
-  \markright{#1}}
-\fancyhead[RE]{An Introduction to \Scala}  % Chapter in the right on even pages
-
-\definecolor{darkgreen}{rgb}{0,0.5,0.3} 
-
-\begin{document}
-\frontmatter
-\makedoctitle
-\clearemptydoublepage
-\tableofcontents
-\mainmatter
-
-%\begin{center}
-%\LARGE\textbf{\\ An Introduction to \Scala}
-%\end{center}
-
-% disables chapter, section and subsection numbering
-\setcounter{secnumdepth}{-1}
-
-\section{The \Scala{} Programming Language}
-
-\input{MainPart}
-
-\end{document}
diff --git a/doc/introduction/ScalaIntro.xsl b/doc/introduction/ScalaIntro.xsl
deleted file mode 100644
index 3de1ab09cd..0000000000
--- a/doc/introduction/ScalaIntro.xsl
+++ /dev/null
@@ -1,174 +0,0 @@
-<?xml version="1.0" encoding="utf-8"?>
-<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
-                version="1.0">
-  <xsl:output method="text" encoding="iso-8859-1" indent="no" />
-
-  <!-- ##################### Match Rules ####################### -->
-
-  <xsl:template match="/"><xsl:apply-templates /></xsl:template>
-
-
-  <!-- ELEMENT source -->
-
-  <xsl:template match="source">
-<xsl:apply-templates />
-\newpage
-  </xsl:template>
-
-
-  <!-- ELEMENT header -->
-
-  <xsl:template match="header">
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-%% Author: <xsl:value-of select="author" />
-%% Keywords: <xsl:value-of select="keywords" />
-  </xsl:template>
-
-
-  <!-- ELEMENT content -->
-
-  <xsl:template match="content">
-<xsl:apply-templates />
-  </xsl:template>
-
-
-  <!-- ELEMENT csharp, dotnet, scala -->
-
-  <xsl:template match="csharp">\CSharp</xsl:template>
-  <xsl:template match="dotnet">\DotNet</xsl:template>
-  <xsl:template match="scala">\href{http://scala.epfl.ch/}{\Scala}</xsl:template>
-
-
-  <!-- ELEMENT title, h, h3 -->
-
-  <xsl:template match="title">
-    <xsl:variable name="_subtitle"><xsl:apply-templates /></xsl:variable>
-    <xsl:variable name="subtitle"><xsl:value-of select="substring-after($_subtitle, ': ')" /></xsl:variable>
-\section{<xsl:value-of select="$subtitle" />}
-  </xsl:template>
-  <xsl:template match="h">
-\subsection*{<xsl:apply-templates />}
-  </xsl:template>
-  <xsl:template match="h3">
-\subsubsection*{<xsl:apply-templates />}
-  </xsl:template>
-
-  <!-- ELEMENT a, code, em, i, p, tt -->
-
-  <xsl:template match="a">
-    <xsl:choose>
-      <xsl:when test="starts-with(@href, 'http://')">
-\href{<xsl:value-of select="@href" />}{<xsl:apply-templates />}
-      </xsl:when>
-<!--
-      <xsl:when test="starts-with(@href, 'intro/')">
-\hypertarget{<xsl:value-of select="translate(substring-before(@href, '.html'), '/', ':')" />}{<xsl:apply-templates />}
-      </xsl:when>
-      <xsl:when test="not(@name)">
-<xsl:apply-templates /> [\nolinkurl{<xsl:value-of select="@href" />}]
-      </xsl:when>
--->
-      <xsl:otherwise>
-        <xsl:apply-templates />
-      </xsl:otherwise>
-    </xsl:choose>
-  </xsl:template>
-  <xsl:template match="code">\texttt{<xsl:apply-templates />}</xsl:template>
-  <xsl:template match="em">\emph{<xsl:apply-templates />}</xsl:template>
-  <xsl:template match="i">\emph{<xsl:apply-templates />}</xsl:template>
-  <xsl:template match="p">
-\noindent <xsl:apply-templates />
-  </xsl:template>
-  <xsl:template match="tt">\texttt{<xsl:apply-templates />}</xsl:template>
-  
-
-  <!-- ELEMENT img -->
-
-  <xsl:template match="img">
-    <xsl:variable name="_src">
-      <xsl:value-of select="substring-before(substring-after(@src, '/'), '.')" />
-    </xsl:variable>
-\begin{figure}[ht] <!-- h:here, t:top, b:bottom, p:separate page -->
-\begin{center}
-    <xsl:choose>
-      <xsl:when test="contains($_src,'classhierarchy')">
-\scalebox{0.75}[0.75]{\includegraphics{<xsl:value-of select="$_src" />}}
-      </xsl:when>
-      <xsl:otherwise>
-\includegraphics{<xsl:value-of select="$_src" />}
-      </xsl:otherwise>
-    </xsl:choose>
-\end{center}
-\end{figure}
-  </xsl:template>
-
-
-  <!-- ELEMENT ul, li -->
-
-  <xsl:template match="ul">
-\begin{list}{-}{\setlength{\topsep}{0.0em}\setlength{\itemsep}{0.0em}}
-    <xsl:apply-templates />
-\end{list}
-  </xsl:template>
-  <xsl:template match="li">
-\item<xsl:apply-templates />
-  </xsl:template>
-
-
-  <!-- ELEMENT pre -->
-
-  <xsl:template match="pre">
-\begin{small}
-\begin{alltt}<xsl:apply-templates />\end{alltt}
-\end{small}
-  </xsl:template>
-
-
-  <!-- ELEMENT src (Scala source code) -->
-
-  <xsl:template match="src">
-    <xsl:if test="not(@action) or @action!='hide'">
-\begin{small}
-\begin{alltt}<xsl:apply-templates />\end{alltt}
-\end{small}
-    </xsl:if>
-  </xsl:template>
-
-
-  <!-- ELEMENT key (Scala keyword) -->
-
-  <xsl:template match="key">\textbf{<xsl:apply-templates />}</xsl:template>
-
-
-  <!-- ELEMENT chr (character literal) -->
-
-  <xsl:template match="chr"><xsl:apply-templates /></xsl:template>
-
-
-  <!-- ELEMENT str (string literal) -->
-
-  <xsl:template match="str">\textcolor{darkgreen}{<xsl:apply-templates />}</xsl:template>
-
-
-  <!-- ELEMENT cmt (comment) -->
-
-  <xsl:template match="cmt">\emph{<xsl:apply-templates />}</xsl:template>
-
-
-  <!-- ELEMENT div, hidden -->
-
-  <xsl:template match="div" />
-  <xsl:template match="hidden"></xsl:template>
-
-
-  <!-- otherwise -->
-
-  <xsl:template match="*">
-     <xsl:copy>
-       <xsl:copy-of select="@*"/>
-       <xsl:apply-templates/>       
-     </xsl:copy>
-  </xsl:template>
-
-
-</xsl:stylesheet>
diff --git a/doc/reference/ExamplesPart.tex b/doc/reference/ExamplesPart.tex
deleted file mode 100644
index c90ecffa24..0000000000
--- a/doc/reference/ExamplesPart.tex
+++ /dev/null
@@ -1,6862 +0,0 @@
-\def\exercise{
-   \def\theresult{Exercise~\thesection.\arabic{result}}
-   \refstepcounter{result}
-   \trivlist\item[\hskip
-   \labelsep{\bf \theresult}]}
-\def\endexercise{\endtrivlist}
- 
-\newcommand{\rewriteby}[1]{\mbox{\tab\tab\rm(#1)}}
-
-\chapter{\label{chap:example-one}A First Example}
-
-As a first example, here is an implementation of Quicksort in Scala.
-
-\begin{lstlisting}
-def sort(xs: Array[int]): unit = {
-  def swap(i: int, j: int): unit = {
-    val t = xs(i); xs(i) = xs(j); xs(j) = t;
-  }
-  def sort1(l: int, r: int): unit = {
-    val pivot = xs((l + r) / 2);
-    var i = l, j = r;
-    while (i <= j) {
-      while (xs(i) < pivot) { i = i + 1 }
-      while (xs(j) > pivot) { j = j - 1 }
-      if (i <= j) { 
-        swap(i, j);
-        i = i + 1;
-        j = j - 1;
-      }
-    } 
-    if (l < j) sort1(l, j);
-    if (j < r) sort1(i, r);
-  }
-  sort1(0, xs.length - 1);
-}
-\end{lstlisting}
-
-The implementation looks quite similar to what one would write in Java
-or C.  We use the same operators and similar control structures.
-There are also some minor syntactical differences. In particular:
-\begin{itemize}
-\item
-Definitions start with a reserved word. Function definitions start
-with \code{def}, variable definitions start with \code{var} and
-definitions of values (i.e. read only variables) start with \code{val}.
-\item
-The declared type of a symbol is given after the symbol and a colon.
-The declared type can often be omitted, because the compiler can infer
-it from the context.
-\item
-We use \code{unit} instead of \code{void} to define the result type of
-a procedure.
-\item
-Array types are written \code{Array[T]} rather than \code{T[]}, 
-and array selections are written \code{a(i)} rather than \code{a[i]}.
-\item
-Functions can be nested inside other functions. Nested functions can
-access parameters and local variables of enclosing functions. For
-instance, the name of the array \code{a} is visible in functions
-\code{swap} and \code{sort1}, and therefore need not be passed as a
-parameter to them.
-\end{itemize}
-So far, Scala looks like a fairly conventional language with some
-syntactic peculiarities. In fact it is possible to write programs in a
-conventional imperative or object-oriented style. This is important
-because it is one of the things that makes it easy to combine Scala
-components with components written in mainstream languages such as
-Java, C\# or Visual Basic.
-
-However, it is also possible to write programs in a style which looks
-completely different. Here is Quicksort again, this time written in
-functional style.
-
-\begin{lstlisting}
-def sort(xs: List[int]): List[int] = 
-  if (xs.length <= 1) xs
-  else {
-    val pivot = xs(xs.length / 2);
-    sort(xs.filter(x => x < pivot))
-      :::  xs.filter(x => x == pivot)
-      :::  sort(xs.filter(x => x > pivot))
-  }
-\end{lstlisting}
-
-The functional program works with lists instead of arrays.\footnote{In
-a future complete implementation of Scala, we could also have used arrays
-instead of lists, but at the moment arrays do not yet support
-\code{filter} and \code{:::}.}
-It captures the essence of the quicksort algorithm in a concise way:
-\begin{itemize}
-\item If the list is empty or consists of a single element, 
-      it is already sorted, so return it immediately.
-\item If the list is not empty, pick an an element in the middle of
-      it as a pivot.
-\item Partition the lists into two sub-lists containing elements that
-are less than, respectively greater than the pivot element, and a
-third list which contains elements equal to pivot.
-\item Sort the first two sub-lists by a recursive invocation of
-the sort function.\footnote{This is not quite what the imperative algorithm does;
-the latter partitions the array into two sub-arrays containing elements
-less than or greater or equal to pivot.}
-\item The result is obtained by appending the three sub-lists together.
-\end{itemize}
-Both the imperative and the functional implementation have the same
-asymptotic complexity -- $O(N;log(N))$ in the average case and
-$O(N^2)$ in the worst case. But where the imperative implementation
-operates in place by modifying the argument array, the functional
-implementation returns a new sorted list and leaves the argument
-list unchanged. The functional implementation thus requires more
-transient memory than the imperative one.
-
-The functional implementation makes it look like Scala is a language
-that's specialized for functional operations on lists. In fact, it
-is not; all of the operations used in the example are simple library
-methods of a class \code{List[t]} which is part of the standard
-Scala library, and which itself is implemented in Scala.
-
-In particular, there is the method \code{filter} which takes as
-argument a {\em predicate function} that maps list elements to
-boolean values. The result of \code{filter} is a list consisting of
-all the elements of the original list for which the given predicate
-function is true.  The \code{filter} method of an object of type
-\code{List[t]} thus has the signature
-
-\begin{lstlisting}
-def filter(p: t => boolean): List[t]
-\end{lstlisting}
-
-Here, \code{t => boolean} is the type of functions that take an element
-of type \code{t} and return a \code{boolean}.  Functions like
-\code{filter} that take another function as argument or return one as
-result are called {\em higher-order} functions.
-
-In the quicksort program, \code{filter} is applied three times to an
-anonymous function argument.  The first argument,
-\code{x => x <= pivot} represents the function that maps its parameter
-\code{x} to the boolean value \code{x <= pivot}. That is, it yields
-true if \code{x} is smaller or equal than \code{pivot}, false
-otherwise. The function is anonymous, i.e.\ it is not defined with a
-name. The type of the \code{x} parameter is omitted because a Scala
-compiler can infer it automatically from the context where the
-function is used. To summarize, \code{xs.filter(x => x <= pivot)}
-returns a list consisting of all elements of the list \code{xs} that are
-smaller than \code{pivot}.
-
-\comment{
-It is also possible to apply higher-order functions such as
-\code{filter} to named function arguments. Here is functional
-quicksort again, where the two anonymous functions are replaced by
-named auxiliary functions that compare the argument to the
-\code{pivot} value.
-
-\begin{lstlisting}
-def sort (xs: List[int]): List[int] = {
-  val pivot = xs(xs.length / 2);
-  def leqPivot(x: int) = x <= pivot;
-  def gtPivot(x: int) = x > pivot;
-  def eqPivot(x: int) = x == pivot;
-  sort(xs filter leqPivot)  
-    ::: sort(xs filter eqPivot)  
-    ::: sort(xs filter gtPivot)
-}
-\end{lstlisting}
-}
-
-An object of type \code{List[t]} also has a method ``\code{:::}''
-which takes an another list and which returns the result of appending this
-list to itself. This method has the signature
-
-\begin{lstlisting}
-def :::(that: List[t]): List[t]
-\end{lstlisting}
-
-Scala does not distinguish between identifiers and operator names. An
-identifier can be either a sequence of letters and digits which begins
-with a letter, or it can be a sequence of special characters, such as
-``\code{+}'', ``\code{*}'', or ``\code{:}''.  The last definition thus
-introduced a new method identifier ``\code{:::}''.  This identifier is
-used in the Quicksort example as a binary infix operator that connects
-the two sub-lists resulting from the partition. In fact, any method
-can be used as an operator in Scala.  The binary operation $E;op;E'$
-is always interpreted as the method call $E.op(E')$. This holds also
-for binary infix operators which start with a letter. The recursive call
-to \code{sort} in the last quicksort example is thus equivalent to
-\begin{lstlisting}
-sort(a.filter(x => x < pivot))
-  .:::(sort(a.filter(x => x == pivot)))
-  .:::(sort(a.filter(x => x > pivot)))
-\end{lstlisting}
-
-Looking again in detail at the first, imperative implementation of
-Quicksort, we find that many of the language constructs used in the
-second solution are also present, albeit in a disguised form.
-
-For instance, ``standard'' binary operators such as \code{+},
-\code{-}, or \code{<} are not treated in any special way. Like
-\code{append}, they are methods of their left operand. Consequently,
-the expression \code{i + 1} is regarded as the invocation
-\code{i.+(1)} of the \code{+} method of the integer value \code{x}.
-Of course, a compiler is free (if it is moderately smart, even expected)
-to recognize the special case of calling the \code{+} method over
-integer arguments and to generate efficient inline code for it.
-
-For efficiency and better error diagnostics the \code{while} loop is a
-primitive construct in Scala. But in principle, it could have just as
-well been a predefined function. Here is a possible implementation of it:
-\begin{lstlisting}
-def While (p: => boolean) (s: => unit): unit =
-      if (p) { s ; While(p)(s) }
-\end{lstlisting}
-The \code{While} function takes as first parameter a test function,
-which takes no parameters and yields a boolean value. As second
-parameter it takes a command function which also takes no parameters
-and yields a trivial result. \code{While} invokes the command function
-as long as the test function yields true. 
-
-
-\chapter{Programming with Actors and Messages}
-\label{chap:example-auction}
-
-Here's an example that shows an application area for which Scala is
-particularly well suited. Consider the task of implementing an
-electronic auction service. We use an Erlang-style actor process
-model to implement the participants of the auction. Actors are
-objects to which messages are sent. Every process has a ``mailbox'' of
-its incoming messages which is represented as a queue. It can work
-sequentially through the messages in its mailbox, or search for
-messages matching some pattern.
-
-\begin{lstlisting}[style=floating,label=fig:simple-auction-msgs,caption=Implementation of an Auction Service]
-trait AuctionMessage;
-case class Offer(bid: int, client: Actor)  extends AuctionMessage;
-case class Inquire(client: Actor)          extends AuctionMessage;       
-
-trait AuctionReply;
-case class  Status(asked: int, expire: Date) extends AuctionReply;
-case object BestOffer                        extends AuctionReply;
-case class  BeatenOffer(maxBid: int)         extends AuctionReply;
-case class  AuctionConcluded(seller: Actor, client: Actor) 
-                                             extends AuctionReply;
-case object AuctionFailed                    extends AuctionReply;
-case object AuctionOver                      extends AuctionReply;
-\end{lstlisting}
-
-For every traded item there is an auctioneer process that publishes
-information about the traded item, that accepts offers from clients
-and that communicates with the seller and winning bidder to close the
-transaction. We present an overview of a simple implementation
-here.
-
-As a first step, we define the messages that are exchanged during an
-auction. There are two abstract base classes (called {\em traits}):
-\code{AuctionMessage} for messages from clients to the auction
-service, and \code{AuctionReply} for replies from the service to the
-clients.  For both base classes there exists a number of cases, which
-are defined in Figure~\ref{fig:simple-auction-msgs}.
-
-\begin{lstlisting}[style=floating,label=fig:simple-auction,caption=Implementation of an Auction Service]
-class Auction(seller: Actor, minBid: int, closing: Date) extends Actor {
-  val timeToShutdown = 36000000; // msec
-  val bidIncrement = 10;
-  override def run() = {
-    var maxBid = minBid - bidIncrement;
-    var maxBidder: Actor = _;
-    var running = true;
-    while (running) {
-      receiveWithin ((closing.getTime() - new Date().getTime())) {
-        case Offer(bid, client) =>
-          if (bid >= maxBid + bidIncrement) { 
-            if (maxBid >= minBid) maxBidder send BeatenOffer(bid);
-            maxBid = bid; maxBidder = client; client send BestOffer;
-          } else {
-            client send BeatenOffer(maxBid);
-          }
-        case Inquire(client) =>
-          client send Status(maxBid, closing);
-        case TIMEOUT =>
-          if (maxBid >= minBid) {
-            val reply = AuctionConcluded(seller, maxBidder);
-            maxBidder send reply; seller send reply;
-          } else {
-            seller send AuctionFailed;
-          }
-          receiveWithin(timeToShutdown) {
-            case Offer(_, client) => client send AuctionOver
-            case TIMEOUT => running = false;
-          }
-      }
-    }
-  } 
-}
-\end{lstlisting}
-
-For each base class, there are a number of {\em case classes} which
-define the format of particular messages in the class. These messages
-might well be ultimately mapped to small XML documents. We expect
-automatic tools to exist that convert between XML documents and
-internal data structures like the ones defined above.
-
-Figure~\ref{fig:simple-auction} presents a Scala implementation of a
-class \code{Auction} for auction processes that coordinate the bidding
-on one item. Objects of this class are created by indicating
-\begin{itemize}
-\item a seller process which needs to be notified when the auction is over,
-\item a minimal bid,
-\item the date when the auction is to be closed.
-\end{itemize}
-The process behavior is defined by its \code{run} method. That method
-repeatedly selects (using \code{receiveWithin}) a message and reacts to it,
-until the auction is closed, which is signaled by a \code{TIMEOUT}
-message. Before finally stopping, it stays active for another period
-determined by the \code{timeToShutdown} constant and replies to
-further offers that the auction is closed.  
-
-Here are some further explanations of the constructs used in this
-program:
-\begin{itemize}
-\item
-The \code{receiveWithin} method of class \code{Actor} takes as
-parameters a time span given in milliseconds and a function that
-processes messages in the mailbox. The function is given by a sequence
-of cases that each specify a pattern and an action to perform for
-messages matching the pattern. The \code{receiveWithin} method selects
-the first message in the mailbox which matches one of these patterns
-and applies the corresponding action to it.
-\item
-The last case of \code{receiveWithin} is guarded by a
-\code{TIMEOUT} pattern. If no other messages are received in the meantime, this
-pattern is triggered after the time span which is passed as argument
-to the enclosing \code{receiveWithin} method. \code{TIMEOUT} is a
-particular instance of class \code{Message}, which is triggered by the
-\code{Actor} implementation itself.
-\item
-Reply messages are sent using syntax of the form
-\code{destination send SomeMessage}. \code{send} is used here as a
-binary operator with a process and a message as arguments. This is
-equivalent in Scala to the method call
-\code{destination.send(SomeMessage)}, i.e. the invocation of
-the \code{send} of the destination process with the given message as
-parameter.
-\end{itemize}
-The preceding discussion gave a flavor of distributed programming in
-Scala. It might seem that Scala has a rich set of language constructs
-that support actor processes, message sending and receiving,
-programming with timeouts, etc. In fact, the opposite is true. All the
-constructs discussed above are offered as methods in the library class
-\code{Actor}. That class is itself implemented in Scala, based on the underlying 
-thread model of the host language (e.g. Java, or .NET).
-The implementation of all features of class \code{Actor} used here is
-given in Section~\ref{sec:actors}.
-
-The advantages of the library-based approach are relative simplicity
-of the core language and flexibility for library designers. Because
-the core language need not specify details of high-level process
-communication, it can be kept simpler and more general. Because the
-particular model of messages in a mailbox is a library module, it can
-be freely modified if a different model is needed in some
-applications.  The approach requires however that the core language is
-expressive enough to provide the necessary language abstractions in a
-convenient way. Scala has been designed with this in mind; one of its
-major design goals was that it should be flexible enough to act as a
-convenient host language for domain specific languages implemented by
-library modules. For instance, the actor communication constructs
-presented above can be regarded as one such domain specific language,
-which conceptually extends the Scala core.
-
-\chapter{\label{chap:simple-funs}Expressions and Simple Functions}
-
-The previous examples gave an impression of what can be done with
-Scala.  We now introduce its constructs one by one in a more
-systematic fashion. We start with the smallest level, expressions and
-functions.
-
-\section{Expressions And Simple Functions}
-
-A Scala system comes with an interpreter which can be seen as a fancy
-calculator. A user interacts with the calculator by typing in
-expressions. The calculator returns the evaluation results and their
-types. Example:
-
-\begin{lstlisting}
-> 87 + 145
-232: scala.Int
-
-> 5 + 2 * 3
-11: scala.Int
-
-> "hello" + " world!"
-hello world: scala.String
-\end{lstlisting}
-It is also possible to name a sub-expression and use the name instead
-of the expression afterwards:
-\begin{lstlisting}
-> def scale = 5
-def scale: int
-
-> 7 * scale
-35: scala.Int
-\end{lstlisting}
-\begin{lstlisting}
-> def pi = 3.141592653589793
-def pi: scala.Double
-
-> def radius = 10
-def radius: scala.Int
-
-> 2 * pi * radius
-62.83185307179586: scala.Double
-\end{lstlisting}
-Definitions start with the reserved word \code{def}; they introduce a
-name which stands for the expression following the \code{=} sign.  The
-interpreter will answer with the introduced name and its type.
-
-Executing a definition such as \code{def x = e} will not evaluate the
-expression \code{e}.  Instead \code{e} is evaluated whenever \code{x}
-is used. Alternatively, Scala offers a value definition 
-\code{val x = e}, which does evaluate the right-hand-side \code{e} as part of the
-evaluation of the definition. If \code{x} is then used subsequently,
-it is immediately replaced by the pre-computed value of
-\code{e}, so that the expression need not be evaluated again.
- 
-How are expressions evaluated? An expression consisting of operators
-and operands is evaluated by repeatedly applying the following
-simplification steps.
-\begin{itemize}
-\item pick the left-most operation
-\item evaluate its operands
-\item apply the operator to the operand values.
-\end{itemize}
-A name defined by \code{def}\ is evaluated by replacing the name by the
-(unevaluated) definition's right hand side. A name defined by \code{val} is
-evaluated by replacing the name by the value of the definitions's
-right-hand side.  The evaluation process stops once we have reached a
-value. A value is some data item such as a string, a number, an array,
-or a list.
-
-\example
-Here is an evaluation of an arithmetic expression.
-\begin{lstlisting}
-$\,\,\,$   (2 * pi) * radius
-$\rightarrow$  (2 * 3.141592653589793) * radius
-$\rightarrow$  6.283185307179586 * radius
-$\rightarrow$  6.283185307179586 * 10
-$\rightarrow$  62.83185307179586
-\end{lstlisting}
-The process of stepwise simplification of expressions to values is
-called {\em reduction}.
-
-\section{Parameters}
-
-Using \code{def}, one can also define functions with parameters. Example:
-\begin{lstlisting}
-> def square(x: double) = x * x
-def (x: double): scala.Double
-
-> square(2)
-4.0: scala.Double
-
-> square(5 + 3)
-64.0: scala.Double
-
-> square(square(4))
-256.0: scala.Double
-
-> def sumOfSquares(x: double, y: double) = square(x) + square(y)
-def sumOfSquares(scala.Double,scala.Double): scala.Double
-
-> sumOfSquares(3, 2 + 2)
-25.0: scala.Double
-\end{lstlisting}
-
-Function parameters follow the function name and are always enclosed
-in parentheses.  Every parameter comes with a type, which is indicated
-following the parameter name and a colon.  At the present time, we
-only need basic numeric types such as the type \code{scala.Double} of
-double precision numbers. Scala defines {\em type aliases} for some
-standard types, so we can write numeric types as in Java. For instance
-\code{double} is a type alias of \code{scala.Double} and \code{int} is
-a type alias for \code{scala.Int}.
-
-Functions with parameters are evaluated analogously to operators in
-expressions. First, the arguments of the function are evaluated (in
-left-to-right order). Then, the function application is replaced by
-the function's right hand side, and at the same time all formal
-parameters of the function are replaced by their corresponding actual
-arguments.
-
-\example\ 
- 
-\begin{lstlisting}
-$\,\,\,$   sumOfSquares(3, 2+2)
-$\rightarrow$  sumOfSquares(3, 4)
-$\rightarrow$  square(3) + square(4)
-$\rightarrow$  3 * 3 + square(4)
-$\rightarrow$  9 + square(4)
-$\rightarrow$  9 + 4 * 4
-$\rightarrow$  9 + 16
-$\rightarrow$  25
-\end{lstlisting}
-
-The example shows that the interpreter reduces function arguments to
-values before rewriting the function application.  One could instead
-have chosen to apply the function to unreduced arguments. This would
-have yielded the following reduction sequence:
-\begin{lstlisting}
-$\,\,\,$   sumOfSquares(3, 2+2)
-$\rightarrow$  square(3) + square(2+2)
-$\rightarrow$  3 * 3 + square(2+2)
-$\rightarrow$  9 + square(2+2)
-$\rightarrow$  9 + (2+2) * (2+2)
-$\rightarrow$  9 + 4 * (2+2)
-$\rightarrow$  9 + 4 * 4
-$\rightarrow$  9 + 16
-$\rightarrow$  25
-\end{lstlisting}
-
-The second evaluation order is known as \emph{call-by-name},
-whereas the first one is known as \emph{call-by-value}.  For
-expressions that use only pure functions and that therefore can be
-reduced with the substitution model, both schemes yield the same final
-values.  
-
-Call-by-value has the advantage that it avoids repeated evaluation of
-arguments. Call-by-name has the advantage that it avoids evaluation of
-arguments when the parameter is not used at all by the function.
-Call-by-value is usually more efficient than call-by-name, but a
-call-by-value evaluation might loop where a call-by-name evaluation
-would terminate. Consider:
-\begin{lstlisting}
-> def loop: int = loop
-def loop: scala.Int
-
-> def first(x: int, y: int) = x
-def first(x: scala.Int, y: scala.Int): scala.Int
-\end{lstlisting}
-Then \code{first(1, loop)} reduces with call-by-name to \code{1},
-whereas the same term reduces with call-by-value repeatedly to itself,
-hence evaluation does not terminate.
-\begin{lstlisting}
-$\,\,\,$   first(1, loop)
-$\rightarrow$  first(1, loop)
-$\rightarrow$  first(1, loop)
-$\rightarrow$  ...
-\end{lstlisting}
-Scala uses call-by-value by default, but it switches to call-by-name evaluation
-if the parameter type is preceded by \code{=>}.
-
-\example\ 
- 
-\begin{lstlisting}
-> def constOne(x: int, y: => int) = 1
-constOne(x: scala.Int, y: => scala.Int): scala.Int
-
-> constOne(1, loop)
-1: scala.Int
-
-> constOne(loop, 2)                    // gives an infinite loop.
-^C
-\end{lstlisting}
-
-\section{Conditional Expressions}
-
-Scala's \code{if-else} lets one choose between two alternatives.  Its
-syntax is like Java's \code{if-else}. But where Java's \code{if-else}
-can be used only as an alternative of statements, Scala allows the
-same syntax to choose between two expressions. That's why Scala's
-\code{if-else} serves also as a substitute for Java's conditional
-expression \code{ ... ? ... : ...}.
-
-\example\ 
-
-\begin{lstlisting}
-> def abs(x: double) = if (x >= 0) x else -x
-abs(x: double): double
-\end{lstlisting}
-Scala's boolean expressions are similar to Java's; they are formed
-from the constants
-\code{true} and
-\code{false}, comparison operators, boolean negation \code{!} and the
-boolean operators $\,$\code{&&}$\,$ and $\,$\code{||}.
-
-\section{\label{sec:sqrt}Example: Square Roots by Newton's Method}
-
-We now illustrate the language elements introduced so far in the
-construction of a more interesting program. The task is to write a
-function
-\begin{lstlisting}
-def sqrt(x: double): double = ... 
-\end{lstlisting}
-which computes the square root of \code{x}.
-
-A common way to compute square roots is by Newton's method of
-successive approximations. One starts with an initial guess \code{y}
-(say: \code{y = 1}). One then repeatedly improves the current guess
-\code{y} by taking the average of \code{y} and \code{x/y}.  As an
-example, the next three columns indicate the guess \code{y}, the
-quotient \code{x/y}, and their average for the first approximations of
-$\sqrt 2$.
-\begin{lstlisting}
-1            2/1 = 2               1.5
-1.5          2/1.5 = 1.3333        1.4167
-1.4167       2/1.4167 = 1.4118     1.4142
-1.4142       ...                   ...
-
-$y$            $x/y$                   $(y + x/y)/2$
-\end{lstlisting}
-One can implement this algorithm in Scala by a set of small functions,
-which each represent one of the elements of the algorithm.  
-
-We first define a function for iterating from a guess to the result:
-\begin{lstlisting}
-def sqrtIter(guess: double, x: double): double = 
-  if (isGoodEnough(guess, x)) guess
-  else sqrtIter(improve(guess, x), x);
-\end{lstlisting}
-Note that \code{sqrtIter} calls itself recursively.  Loops in
-imperative programs can always be modeled by recursion in functional
-programs. 
-
-Note also that the definition of \code{sqrtIter} contains a return
-type, which follows the parameter section. Such return types are
-mandatory for recursive functions. For a non-recursive function, the
-return type is optional; if it is missing the type checker will
-compute it from the type of the function's right-hand side. However,
-even for non-recursive functions it is often a good idea to include a
-return type for better documentation.
-
-As a second step, we define the two functions called by
-\code{sqrtIter}: a function to \code{improve} the guess and a
-termination test \code{isGoodEnough}. Here is their definition.
-\begin{lstlisting}
-def improve(guess: double, x: double) = 
-  (guess + x / guess) / 2;
-
-def isGoodEnough(guess: double, x: double) = 
-  abs(square(guess) - x) < 0.001;
-\end{lstlisting}
-
-Finally, the \code{sqrt} function itself is defined by an application
-of \code{sqrtIter}.
-\begin{lstlisting}
-def sqrt(x: double) = sqrtIter(1.0, x);
-\end{lstlisting}
-
-\begin{exercise} The \code{isGoodEnough} test is not very precise for small
-numbers and might lead to non-termination for very large ones (why?).
-Design a different version of \code{isGoodEnough} which does not have
-these problems.
-\end{exercise}
-
-\begin{exercise} Trace the execution of the \code{sqrt(4)} expression.
-\end{exercise}
-
-\section{Nested Functions}
-
-The functional programming style encourages the construction of many
-small helper functions. In the last example, the implementation
-of \code{sqrt} made use of the helper functions \code{sqrtIter},
-\code{improve} and \code{isGoodEnough}. The names of these functions
-are relevant only for the implementation of \code{sqrt}. We normally
-do not want users of \code{sqrt} to access these functions directly.
-
-We can enforce this (and avoid name-space pollution) by including
-the helper functions within the calling function itself:
-\begin{lstlisting}
-def sqrt(x: double) = {
-  def sqrtIter(guess: double, x: double): double = 
-    if (isGoodEnough(guess, x)) guess
-    else sqrtIter(improve(guess, x), x);
-  def improve(guess: double, x: double) = 
-    (guess + x / guess) / 2;
-  def isGoodEnough(guess: double, x: double) = 
-    abs(square(guess) - x) < 0.001;
-  sqrtIter(1.0, x)
-}
-\end{lstlisting}
-In this program, the braces \code{\{ ... \}} enclose a {\em block}.
-Blocks in Scala are themselves expressions.  Every block ends in a
-result expression which defines its value.  The result expression may
-be preceded by auxiliary definitions, which are visible only in the
-block itself.
-
-Every definition in a block must be followed by a semicolon, which
-separates this definition from subsequent definitions or the result
-expression. However, a semicolon is inserted implicitly if the
-definition ends in a right brace and is followed by a new line.
-Therefore, the following are all legal:
-\begin{lstlisting}
-def f(x) = x + 1; /* `;' mandatory */
-f(1) + f(2)
-
-def g(x) = {x + 1}
-g(1) + g(2)
-
-def h(x) = {x + 1};  /* `;' mandatory */ h(1) + h(2)
-\end{lstlisting}
-Scala uses the usual block-structured scoping rules. A name defined in
-some outer block is visible also in some inner block, provided it is
-not redefined there. This rule permits us to simplify our
-\code{sqrt} example. We need not pass \code{x} around as an additional parameter of
-the nested functions, since it is always visible in them as a
-parameter of the outer function \code{sqrt}. Here is the simplified code:
-\begin{lstlisting}
-def sqrt(x: double) = {
-  def sqrtIter(guess: double): double = 
-    if (isGoodEnough(guess)) guess
-    else sqrtIter(improve(guess));
-  def improve(guess: double) = 
-    (guess + x / guess) / 2;
-  def isGoodEnough(guess: double) = 
-    abs(square(guess) - x) < 0.001;
-  sqrtIter(1.0)
-}
-\end{lstlisting}
-
-\section{Tail Recursion}
-
-Consider the following function to compute the greatest common divisor
-of two given numbers.
-
-\begin{lstlisting}
-def gcd(a: int, b: int): int = if (b == 0) a else gcd(b, a % b)
-\end{lstlisting}
-
-Using our substitution model of function evaluation, 
-\code{gcd(14, 21)} evaluates as follows:
-
-\begin{lstlisting}
-$\,\,$      gcd(14, 21)  
-$\rightarrow\!$     if (21 == 0) 14 else gcd(21, 14 % 21)
-$\rightarrow\!$     if (false) 14 else gcd(21, 14 % 21)
-$\rightarrow\!$     gcd(21, 14 % 21)
-$\rightarrow\!$     gcd(21, 14)
-$\rightarrow\!$     if (14 == 0) 21 else gcd(14, 21 % 14)
-$\rightarrow$ $\rightarrow$  gcd(14, 21 % 14)
-$\rightarrow\!$     gcd(14, 7)
-$\rightarrow\!$     if (7 == 0) 14 else gcd(7, 14 % 7)
-$\rightarrow$ $\rightarrow$  gcd(7, 14 % 7)
-$\rightarrow\!$     gcd(7, 0)
-$\rightarrow\!$     if (0 == 0) 7 else gcd(0, 7 % 0)
-$\rightarrow$ $\rightarrow$  7
-\end{lstlisting}
-
-Contrast this with the evaluation of another recursive function, 
-\code{factorial}:
-
-\begin{lstlisting}
-def factorial(n: int): int = if (n == 0) 1 else n * factorial(n - 1)
-\end{lstlisting}
-
-The application \code{factorial(5)} rewrites as follows:
-\begin{lstlisting}
-$\,\,\,$       factorial(5)
-$\rightarrow$      if (5 == 0) 1 else 5 * factorial(5 - 1)
-$\rightarrow$      5 * factorial(5 - 1)
-$\rightarrow$      5 * factorial(4)
-$\rightarrow\ldots\rightarrow$  5 * (4 * factorial(3))
-$\rightarrow\ldots\rightarrow$  5 * (4 * (3 * factorial(2)))
-$\rightarrow\ldots\rightarrow$  5 * (4 * (3 * (2 * factorial(1))))
-$\rightarrow\ldots\rightarrow$  5 * (4 * (3 * (2 * (1 * factorial(0))))
-$\rightarrow\ldots\rightarrow$  5 * (4 * (3 * (2 * (1 * 1))))
-$\rightarrow\ldots\rightarrow$  120
-\end{lstlisting}
-There is an important difference between the two rewrite sequences:
-The terms in the rewrite sequence of \code{gcd} have again and again
-the same form. As evaluation proceeds, their size is bounded by a
-constant. By contrast, in the evaluation of factorial we get longer
-and longer chains of operands which are then multiplied in the last
-part of the evaluation sequence.
-
-Even though actual implementations of Scala do not work by rewriting
-terms, they nevertheless should have the same space behavior as in the
-rewrite sequences. In the implementation of \code{gcd}, one notes that
-the recursive call to \code{gcd} is the last action performed in the
-evaluation of its body. One also says that \code{gcd} is
-``tail-recursive''. The final call in a tail-recursive function can be
-implemented by a jump back to the beginning of that function. The
-arguments of that call can overwrite the parameters of the current
-instantiation of \code{gcd}, so that no new stack space is needed.
-Hence, tail recursive functions are iterative processes, which can be
-executed in constant space.
-
-By contrast, the recursive call in \code{factorial} is followed by a
-multiplication.  Hence, a new stack frame is allocated for the
-recursive instance of factorial, and is deallocated after that
-instance has finished. The given formulation of the factorial function
-is not tail-recursive; it needs space proportional to its input
-parameter for its execution.
-
-More generally, if the last action of a function is a call to another
-(possibly the same) function, only a single stack frame is needed for
-both functions. Such calls are called ``tail calls''. In principle,
-tail calls can always re-use the stack frame of the calling function.
-However, some run-time environments (such as the Java VM) lack the
-primitives to make stack frame re-use for tail calls efficient.  A
-production quality Scala implementation is therefore only required to
-re-use the stack frame of a directly tail-recursive function whose
-last action is a call to itself.  Other tail calls might be optimized
-also, but one should not rely on this across implementations.
-
-\begin{exercise} Design a tail-recursive version of
-\code{factorial}.
-\end{exercise}
-
-\chapter{\label{chap:first-class-funs}First-Class Functions}
-
-A function in Scala is a ``first-class value''. Like any other value,
-it may be passed as a parameter or returned as a result.  Functions
-which take other functions as parameters or return them as results are
-called {\em higher-order} functions. This chapter introduces
-higher-order functions and shows how they provide a flexible mechanism
-for program composition.
-
-As a motivating example, consider the following three related tasks:
-\begin{enumerate}
-\item
-Write a function to sum all integers between two given numbers \code{a} and \code{b}:
-\begin{lstlisting}
-def sumInts(a: int, b: int): int =
-  if (a > b) 0 else a + sumInts(a + 1, b);
-\end{lstlisting}
-\item 
-Write a function to sum the squares of all integers between two given numbers 
-\code{a} and \code{b}:
-\begin{lstlisting}
-def square(x: int): int = x * x;
-def sumSquares(a: int, b: int): int =
-  if (a > b) 0 else square(a) + sumSquares(a + 1, b);
-\end{lstlisting}
-\item
-Write a function to sum the powers $2^n$ of all integers $n$ between
-two given numbers \code{a} and \code{b}:
-\begin{lstlisting}
-def powerOfTwo(x: int): int = if (x == 0) 1 else x * powerOfTwo(x - 1);
-def sumPowersOfTwo(a: int, b: int): int =
-  if (a > b) 0 else powerOfTwo(a) + sumPowersOfTwo(a + 1, b);
-\end{lstlisting}
-\end{enumerate}
-These functions are all instances of
-\(\sum^b_a f(n)\) for different values of $f$. 
-We can factor out the common pattern by defining a function \code{sum}:
-\begin{lstlisting}
-def sum(f: int => int, a: int, b: int): double =
-  if (a > b) 0 else f(a) + sum(f, a + 1, b);
-\end{lstlisting}
-The type \code{int => int} is the type of functions that
-take arguments of type \code{int} and return results of type
-\code{int}. So \code{sum} is a function which takes another function as 
-a parameter. In other words, \code{sum} is a {\em higher-order}
-function.
-
-Using \code{sum}, we can formulate the three summing functions as
-follows.
-\begin{lstlisting}
-def sumInts(a: int, b: int): int = sum(id, a, b);
-def sumSquares(a: int, b: int): int = sum(square, a, b);
-def sumPowersOfTwo(a: int, b: int): int = sum(powerOfTwo, a, b);
-\end{lstlisting}
-where
-\begin{lstlisting}
-def id(x: int): int = x;
-def square(x: int): int = x * x;
-def powerOfTwo(x: int): int = if (x == 0) 1 else x * powerOfTwo(x - 1);
-\end{lstlisting}
-
-\section{Anonymous Functions}
-
-Parameterization by functions tends to create many small functions. In
-the previous example, we defined \code{id}, \code{square} and
-\code{power} as separate functions, so that they could be 
-passed as arguments to \code{sum}.
-
-Instead of using named function definitions for these small argument
-functions, we can formulate them in a shorter way as {\em anonymous
-functions}. An anonymous function is an expression that evaluates to a
-function; the function is defined without giving it a name. As an
-example consider the anonymous square function:
-\begin{lstlisting}
-  x: int => x * x
-\end{lstlisting}
-The part before the arrow `\code{=>}' is the parameter of the function,
-whereas the part following the `\code{=>}' is its body. If there are
-several parameters, we need to enclose them in parentheses. For
-instance, here is an anonymous function which multiples its two arguments.
-\begin{lstlisting}
-  (x: int, y: int) => x * y
-\end{lstlisting}
-Using anonymous functions, we can reformulate the first two summation
-functions without named auxiliary functions:
-\begin{lstlisting}
-def sumInts(a: int, b: int): int = sum(x: int => x, a, b);
-def sumSquares(a: int, b: int): int = sum(x: int => x * x, a, b);
-\end{lstlisting}
-Often, the Scala compiler can deduce the parameter type(s) from the
-context of the anonymous function in which case they can be omitted.
-For instance, in the case of \code{sumInts} or \code{sumSquares}, one
-knows from the type of \code{sum} that the first parameter must be a
-function of type \code{int => int}.  Hence, the parameter type
-\code{int} is redundant and may be omitted:
-\begin{lstlisting}
-def sumInts(a: int, b: int): int = sum(x => x, a, b);
-def sumSquares(a: int, b: int): int = sum(x => x * x, a, b);
-\end{lstlisting}
-
-Generally, the Scala term
-\code{(x}$_1$\code{: T}$_1$\code{, ..., x}$_n$\code{: T}$_n$\code{) => E} 
-defines a function which maps its parameters
-\code{x}$_1$\code{, ..., x}$_n$ to the result of the expression \code{E}
-(where \code{E} may refer to \code{x}$_1$\code{, ..., x}$_n$).  Anonymous
-functions are not essential language elements of Scala, as they can
-always be expressed in terms of named functions. Indeed, the 
-anonymous function
-\begin{lstlisting}
-(x$_1$: T$_1$, ..., x$_n$: T$_n$) => E
-\end{lstlisting}
-is equivalent to the block
-\begin{lstlisting}
-{ def f (x$_1$: T$_1$, ..., x$_n$: T$_n$) = E ; f }
-\end{lstlisting}
-where \code{f} is fresh name which is used nowhere else in the program.
-We also say, anonymous functions are ``syntactic sugar''.
-
-\section{Currying}
-
-The latest formulation of the summing functions is already quite
-compact. But we can do even better. Note that
-\code{a} and \code{b} appear as parameters and arguments of every function
-but they do not seem to take part in interesting combinations. Is
-there a way to get rid of them?
-
-Let's try to rewrite \code{sum} so that it does not take the bounds
-\code{a} and \code{b} as parameters:
-\begin{lstlisting}
-def sum(f: int => int) = {
-  def sumF(a: int, b: int): int = 
-    if (a > b) 0 else f(a) + sumF(a + 1, b);
-  sumF
-}
-\end{lstlisting}
-In this formulation, \code{sum} is a function which returns another
-function, namely the specialized summing function \code{sumF}. This
-latter function does all the work; it takes the bounds \code{a} and
-\code{b} as parameters, applies \code{sum}'s function parameter \code{f} to all
-integers between them, and sums up the results. 
-
-Using this new formulation of \code{sum}, we can now define:
-\begin{lstlisting}
-def sumInts = sum(x => x);
-def sumSquares = sum(x => x * x);
-def sumPowersOfTwo = sum(powerOfTwo);
-\end{lstlisting}
-Or, equivalently, with value definitions:
-\begin{lstlisting}
-val sumInts = sum(x => x);
-val sumSquares = sum(x => x * x);
-val sumPowersOfTwo = sum(powerOfTwo);
-\end{lstlisting}
-These functions can be applied like other functions. For instance,
-\begin{lstlisting}
-> sumSquares(1, 10) + sumPowersOfTwo(10, 20)
-267632001: scala.Int
-\end{lstlisting}
-How are function-returning functions applied? As an example, in the expression
-\begin{lstlisting}
-sum(x => x * x)(1, 10) ,
-\end{lstlisting}
-the function \code{sum} is applied to the squaring function 
-\code{(x => x * x)}. The resulting function is then 
-applied to the second argument list, \code{(1, 10)}.
-
-This notation is possible because function application associates to the left.
-That is, if $\mbox{args}_1$ and $\mbox{args}_2$ are argument lists, then 
-\bda{lcl}
-f(\mbox{args}_1)(\mbox{args}_2) & \ \ \mbox{is equivalent to}\ \ & (f(\mbox{args}_1))(\mbox{args}_2)
-\eda
-In our example, \code{sum(x => x * x)(1, 10)} is equivalent to the
-following expression:
-\code{(sum(x => x * x))(1, 10)}.
-
-The style of function-returning functions is so useful that Scala has
-special syntax for it. For instance, the next definition of \code{sum}
-is equivalent to the previous one, but is shorter:
-\begin{lstlisting}
-def sum(f: int => int)(a: int, b: int): int =
-  if (a > b) 0 else f(a) + sum(f)(a + 1, b);
-\end{lstlisting}
-Generally, a curried function definition 
-\begin{lstlisting}
-def f (args$_1$) ... (args$_n$) = E
-\end{lstlisting}
-where $n > 1$ expands to
-\begin{lstlisting}
-def f (args$_1$) ... (args$_{n-1}$) = { def g (args$_n$) = E ; g }
-\end{lstlisting}
-where \code{g} is a fresh identifier. Or, shorter, using an anonymous function:
-\begin{lstlisting}
-def f (args$_1$) ... (args$_{n-1}$) = ( args$_n$ ) => E .
-\end{lstlisting}
-Performing this step $n$ times yields that
-\begin{lstlisting}
-def f (args$_1$) ... (args$_n$) = E
-\end{lstlisting}
-is equivalent to
-\begin{lstlisting}
-def f = (args$_1$) => ... => (args$_n$) => E .
-\end{lstlisting}
-Or, equivalently, using a value definition:
-\begin{lstlisting}
-val f = (args$_1$) => ... => (args$_n$) => E .
-\end{lstlisting}
-This style of function definition and application is called {\em
-currying} after its promoter, Haskell B.\ Curry, a logician of the
-20th century, even though the idea goes back further to Moses
-Sch\"onfinkel and Gottlob Frege.
-
-The type of a function-returning function is expressed analogously to
-its parameter list. Taking the last formulation of \code{sum} as an example,
-the type of \code{sum} is \code{(int => int) => (int, int) => int}.
-This is possible because function types associate to the right. I.e.
-\begin{lstlisting}
-T$_1$ => T$_2$ => T$_3$       $\mbox{is equivalent to}$     T$_1$ => (T$_2$ => T$_3$)
-\end{lstlisting}
-
-
-\begin{exercise}
-1. The \code{sum} function uses a linear recursion. Can you write a
-tail-recursive one by filling in the ??'s?
-
-\begin{lstlisting}
-def sum(f: int => double)(a: int, b: int): double = {
-  def iter(a, result) = {
-    if (??) ??
-    else iter(??, ??)
-  }
-  iter(??, ??)
-}
-\end{lstlisting}
-\end{exercise}
-
-\begin{exercise}
-Write a function \code{product} that computes the product of the
-values of functions at points over a given range.
-\end{exercise}
-
-\begin{exercise}
-Write \code{factorial} in terms of \code{product}.
-\end{exercise}
-
-\begin{exercise}
-Can you write an even more general function which generalizes both
-\code{sum} and \code{product}?
-\end{exercise}
-
-\section{Example: Finding Fixed Points of Functions}
-
-A number \code{x} is called a {\em fixed point} of a function \code{f} if
-\begin{lstlisting}
-f(x) = x .
-\end{lstlisting}
-For some functions \code{f} we can locate the fixed point by beginning
-with an initial guess and then applying \code{f} repeatedly, until the
-value does not change anymore (or the change is within a small
-tolerance). This is possible if the sequence
-\begin{lstlisting}
-x, f(x), f(f(x)), f(f(f(x))), ...
-\end{lstlisting}
-converges to fixed point of $f$. This idea is captured in
-the following ``fixed-point finding function'':
-\begin{lstlisting}
-val tolerance = 0.0001;
-def isCloseEnough(x: double, y: double) = abs((x - y) / x) < tolerance;
-def fixedPoint(f: double => double)(firstGuess: double) = {
-  def iterate(guess: double): double = {
-    val next = f(guess);
-    if (isCloseEnough(guess, next)) next
-    else iterate(next)
-  }
-  iterate(firstGuess)
-}
-\end{lstlisting}
-We now apply this idea in a reformulation of the square root function.
-Let's start with a specification of \code{sqrt}:
-\begin{lstlisting}
-sqrt(x)  =  $\mbox{the {\sl y} such that}$  y * y = x
-         =  $\mbox{the {\sl y} such that}$  y = x / y
-\end{lstlisting}
-Hence, \code{sqrt(x)} is a fixed point of the function \code{y => x / y}.
-This suggests that \code{sqrt(x)} can be computed by fixed point iteration:
-\begin{lstlisting}
-def sqrt(x: double) = fixedPoint(y => x / y)(1.0)
-\end{lstlisting}
-But if we try this, we find that the computation does not
-converge. Let's instrument the fixed point function with a print
-statement which keeps track of the current \code{guess} value:
-\begin{lstlisting}
-def fixedPoint(f: double => double)(firstGuess: double) = {
-  def iterate(guess: double): double = {
-    val next = f(guess);
-    System.out.println(next);
-    if (isCloseEnough(guess, next)) next
-    else iterate(next)
-  }
-  iterate(firstGuess)
-}
-\end{lstlisting}
-Then, \code{sqrt(2)} yields:
-\begin{lstlisting}
-  2.0
-  1.0
-  2.0
-  1.0
-  2.0
-  ...
-\end{lstlisting}
-One way to control such oscillations is to prevent the guess from changing too much. 
-This can be achieved by {\em averaging} successive values of the original sequence:
-\begin{lstlisting}
-> def sqrt(x: double) = fixedPoint(y => (y + x/y) / 2)(1.0)
-def sqrt(x: scala.Double): scala.Double
-> sqrt(2.0)
-  1.5
-  1.4166666666666665
-  1.4142156862745097
-  1.4142135623746899
-  1.4142135623746899
-\end{lstlisting}
-In fact, expanding the \code{fixedPoint} function yields exactly our 
-previous definition of fixed point from Section~\ref{sec:sqrt}.
-
-The previous examples showed that the expressive power of a language
-is considerably enhanced if functions can be passed as arguments.  The
-next example shows that functions which return functions can also be
-very useful.
-
-Consider again fixed point iterations. We started with the observation
-that $\sqrt(x)$ is a fixed point of the function \code{y => x / y}.
-Then we made the iteration converge by averaging successive values.
-This technique of {\em average damping} is so general that it
-can be wrapped in another function.
-\begin{lstlisting}
-def averageDamp(f: double => double)(x: double) = (x + f(x)) / 2;
-\end{lstlisting}
-Using \code{averageDamp}, we can reformulate the square root function
-as follows.
-\begin{lstlisting}
-def sqrt(x: double) = fixedPoint(averageDamp(y => x/y))(1.0);
-\end{lstlisting}
-This expresses the elements of the algorithm as clearly as possible.
-
-\begin{exercise} Write a function for cube roots using \code{fixedPoint} and 
-\code{averageDamp}.
-\end{exercise}
-
-\section{Summary}
-
-We have seen in the previous chapter that functions are essential
-abstractions, because they permit us to introduce general methods of
-computing as explicit, named elements in our programming language.
-The present chapter has shown that these abstractions can be combined
-by higher-order functions to create further abstractions.  As
-programmers, we should look out for opportunities to abstract and to
-reuse. The highest possible level of abstraction is not always the
-best, but it is important to know abstraction techniques, so that one
-can use abstractions where appropriate.
-
-\section{Language Elements Seen So Far}
-
-Chapters~\ref{chap:simple-funs} and \ref{chap:first-class-funs} have
-covered Scala's language elements to express expressions and types
-comprising of primitive data and functions.  The context-free syntax
-of these language elements is given below in extended Backus-Naur
-form, where `\code{|}' denotes alternatives, \code{[...]} denotes
-option (0 or 1 occurrence), and \lstinline@{...}@ denotes repetition
-(0 or more occurrences).
-
-\subsection*{Characters}
-
-Scala programs are sequences of (Unicode) characters. We distinguish the
-following character sets:
-\begin{itemize}
-\item
-whitespace, such as `\code{ }', tabulator, or newline characters,
-\item
-letters `\code{a}' to `\code{z}', `\code{A}' to `\code{Z}',
-\item
-digits \code{`0'} to `\code{9}',
-\item
-the delimiter characters
-
-\begin{lstlisting}
-.    ,    ;    (    )    {    }    [    ]    \    $\mbox{\tt "}$    '
-\end{lstlisting}
-
-\item
-operator characters, such as `\code{#}' `\code{+}',
-`\code{:}'. Essentially, these are printable characters which are
-in none of the character sets above.
-\end{itemize}
-
-\subsection*{Lexemes:}
-
-\begin{lstlisting}
-ident    =  letter {letter | digit}
-         |   operator { operator }
-         |   ident '_' ident
-literal  =  $\mbox{``as in Java''}$
-\end{lstlisting}
-
-Literals are as in Java. They define numbers, characters, strings, or
-boolean values.  Examples of literals as \code{0}, \code{1.0d10}, \code{'x'},
-\code{"he said \"hi!\""}, or \code{true}.
-
-Identifiers can be of two forms. They either start with a letter,
-which is followed by a (possibly empty) sequence of letters or
-symbols, or they start with an operator character, which is followed
-by a (possibly empty) sequence of operator characters.  Both forms of
-identifiers may contain underscore characters `\code{_}'. Furthermore,
-an underscore character may be followed by either sort of
-identifier. Hence, the following are all legal identifiers:
-\begin{lstlisting}
-x     Room10a     +     --     foldl_:     +_vector
-\end{lstlisting}
-It follows from this rule that subsequent operator-identifiers need to
-be separated by whitespace. For instance, the input
-\code{x+-y} is parsed as the three token sequence \code{x}, \code{+-},
-\code{y}. If we want to express the sum of \code{x} with the
-negated value of \code{y}, we need to add at least one space,
-e.g. \code{x+ -y}.
-
-The \verb@$@ character is reserved for compiler-generated
-identifiers; it should not be used in source programs. %$
-
-The following are reserved words, they may not be used as identifiers:
-\begin{lstlisting}[keywordstyle=]
-abstract    case        catch       class       def    
-do          else        extends     false       final    
-finally     for         if          import      new    
-null        object      override    package     private    
-protected   return      sealed      super       this    
-trait       try         true        type        val    
-var         while       with        yield
-_    :    =    =>    <-    <:    >:    #    @
-\end{lstlisting}
-
-\subsection*{Types:}
-
-\begin{lstlisting}
-Type          =  SimpleType | FunctionType
-FunctionType  =  SimpleType '=>' Type | '(' [Types] ')' '=>' Type
-SimpleType    =  byte | short | char | int | long | double | float |
-                 boolean | unit | String
-Types         =  Type {`,' Type}
-\end{lstlisting}
-
-Types can be:
-\begin{itemize}
-\item number types \code{byte}, \code{short}, \code{char}, \code{int}, \code{long}, \code{float} and \code{double} (these are as in Java),
-\item the type \code{boolean} with values \code{true} and \code{false},
-\item the type \code{unit} with the only value \code{()},
-\item the type \code{String},
-\item function types such as \code{(int, int) => int} or \code{String => Int => String}. 
-\end{itemize}
-
-\subsection*{Expressions:}
-
-\begin{lstlisting}
-Expr         = InfixExpr | FunctionExpr | if '(' Expr ')' Expr else Expr
-InfixExpr    = PrefixExpr | InfixExpr Operator InfixExpr
-Operator     = ident
-PrefixExpr   = ['+' | '-' | '!' | '~' ] SimpleExpr
-SimpleExpr   = ident | literal | SimpleExpr '.' ident | Block
-FunctionExpr = Bindings '=>' Expr
-Bindings     = ident [':' SimpleType] | '(' [Binding {',' Binding}] ')'
-Binding      = ident [':' Type]
-Block        = '{' {Def ';'} Expr '}'
-\end{lstlisting}
-
-Expressions can be:
-\begin{itemize}
-\item
-identifiers such as \code{x}, \code{isGoodEnough}, \code{*}, or \code{+-},
-\item
-literals, such as \code{0}, \code{1.0}, or \code{"abc"},
-\item
-field and method selections, such as \code{System.out.println},
-\item
-function applications, such as \code{sqrt(x)}, 
-\item
-operator applications, such as \code{-x} or \code{y + x},
-\item
-conditionals, such as \code{if (x < 0) -x else x},
-\item
-blocks, such as \lstinline@{ val x = abs(y) ; x * 2 }@,
-\item
-anonymous functions, such as \code{x => x + 1} or \code{(x: int, y: int) => x + y}.
-\end{itemize}
-
-\subsection*{Definitions:}
-
-\begin{lstlisting}
-Def          =  FunDef  |  ValDef
-FunDef       =  'def' ident {'(' [Parameters] ')'} [':' Type] '=' Expr
-ValDef       =  'val' ident [':' Type] '=' Expr
-Parameters   =  Parameter {',' Parameter}
-Parameter    =  ['def'] ident ':' Type
-\end{lstlisting}
-Definitions can be:
-\begin{itemize}
-\item
-function definitions such as \code{def square(x: int): int = x * x}, 
-\item
-value definitions such as \code{val y = square(2)}.
-\end{itemize}
-
-\chapter{Classes and Objects}
-\label{chap:classes}
-
-Scala does not have a built-in type of rational numbers, but it is
-easy to define one, using a class. Here's a possible implementation.
-
-\begin{lstlisting}
-class Rational(n: int, d: int) {
-  private def gcd(x: int, y: int): int = {
-    if (x == 0) y
-    else if (x < 0) gcd(-x, y)
-    else if (y < 0) -gcd(x, -y)
-    else gcd(y % x, x);
-  }
-  private val g = gcd(n, d);
-
-  val numer: int = n/g;
-  val denom: int = d/g;
-  def +(that: Rational) =
-    new Rational(numer * that.denom + that.numer * denom,
-                 denom * that.denom);
-  def -(that: Rational) =
-    new Rational(numer * that.denom - that.numer * denom, 
-                 denom * that.denom);
-  def *(that: Rational) =
-    new Rational(numer * that.numer, denom * that.denom);
-  def /(that: Rational) =
-    new Rational(numer * that.denom, denom * that.numer);
-}
-\end{lstlisting}
-This defines \code{Rational} as a class which takes two constructor
-arguments \code{n} and \code{d}, containing the number's numerator and
-denominator parts.  The class provides fields which return these parts
-as well as methods for arithmetic over rational numbers.  Each
-arithmetic method takes as parameter the right operand of the
-operation. The left operand of the operation is always the rational
-number of which the method is a member.
-
-\paragraph{Private members}
-The implementation of rational numbers defines a private method
-\code{gcd} which computes the greatest common denominator of two
-integers, as well as a private field \code{g} which contains the
-\code{gcd} of the constructor arguments. These members are inaccessible
-outside class \code{Rational}. They are used in the implementation of
-the class to eliminate common factors in the constructor arguments in
-order to ensure that numerator and denominator are always in
-normalized form.
-
-\paragraph{Creating and Accessing Objects}
-As an example of how rational numbers can be used, here's a program
-that prints the sum of all numbers $1/i$ where $i$ ranges from 1 to 10.
-\begin{lstlisting}
-var i = 1;
-var x = new Rational(0, 1);
-while (i <= 10) {
-  x = x + new Rational(1,i);
-  i = i + 1;
-}
-System.out.println("" + x.numer + "/" + x.denom);
-\end{lstlisting}
-The \code{+} takes as left operand a string and as right operand a
-value of arbitrary type. It returns the result of converting its right
-operand to a string and appending it to its left operand. 
-  
-\paragraph{Inheritance and Overriding}
-Every class in Scala has a superclass which it extends.  
-\comment{Excepted is
-only the root class \code{Object}, which does not have a superclass,
-and which is indirectly extended by every other class.  }
-If a class
-does not mention a superclass in its definition, the root type
-\code{scala.AnyRef} is implicitly assumed (for Java implementations,
-this type is an alias for \code{java.lang.Object}. For instance, class
-\code{Rational} could equivalently be defined as
-\begin{lstlisting}
-class Rational(n: int, d: int) extends AnyRef {
-  ... // as before
-}
-\end{lstlisting}
-A class inherits all members from its superclass. It may also redefine
-(or: {\em override}) some inherited members. For instance, class
-\code{java.lang.Object} defines
-a method
-\code{toString} which returns a representation of the object as a string:
-\begin{lstlisting}
-class Object {
-  ...
-  def toString(): String = ...
-}
-\end{lstlisting}
-The implementation of \code{toString} in \code{Object}
-forms a string consisting of the object's class name and a number. It
-makes sense to redefine this method for objects that are rational
-numbers:
-\begin{lstlisting}
-class Rational(n: int, d: int) extends AnyRef {
-  ... // as before
-  override def toString() = "" + numer + "/" + denom;
-}
-\end{lstlisting}
-Note that, unlike in Java, redefining definitions need to be preceded
-by an \code{override} modifier.
-
-If class $A$ extends class $B$, then objects of type $A$ may be used
-wherever objects of type $B$ are expected. We say in this case that
-type $A$ {\em conforms} to type $B$.  For instance, \code{Rational}
-conforms to \code{AnyRef}, so it is legal to assign a \code{Rational}
-value to a variable of type \code{AnyRef}:
-\begin{lstlisting}
-var x: AnyRef = new Rational(1,2);
-\end{lstlisting}
-
-\paragraph{Parameterless Methods}
-%Also unlike in Java, methods in Scala do not necessarily take a
-%parameter list. An example is \code{toString}; the method is invoked
-%by simply mentioning its name. For instance:
-%\begin{lstlisting}
-%val r = new Rational(1,2);
-%System.out.println(r.toString());      // prints``1/2''
-%\end{lstlisting}
-Unlike in Java, methods in Scala do not necessarily take a
-parameter list. An example is the \code{square} method below. This
-method is invoked by simply mentioning its name. 
-\begin{lstlisting}
-class Rational(n: int, d: int) extends AnyRef {
-  ... // as before
-  def square = new Rational(numer*numer, denom*denom);
-}
-val r = new Rational(3,4);
-System.out.println(r.square);           // prints``9/16''*
-\end{lstlisting}
-That is, parameterless methods are accessed just as value fields such
-as \code{numer} are. The difference between values and parameterless
-methods lies in their definition. The right-hand side of a value is
-evaluated when the object is created, and the value does not change
-afterwards. A right-hand side of a parameterless method, on the other
-hand, is evaluated each time the method is called.  The uniform access
-of fields and parameterless methods gives increased flexibility for
-the implementer of a class. Often, a field in one version of a class
-becomes a computed value in the next version. Uniform access ensures
-that clients do not have to be rewritten because of that change.
-
-\paragraph{Abstract Classes}
-
-Consider the task of writing a class for sets of integer numbers with
-two operations, \code{incl} and \code{contains}. \code{(s incl x)}
-should return a new set which contains the element \code{x} together
-with all the elements of set \code{s}. \code{(s contains x)} should
-return true if the set \code{s} contains the element \code{x}, and
-should return \code{false} otherwise. The interface of such sets is
-given by:  
-\begin{lstlisting}
-abstract class IntSet {
-  def incl(x: int): IntSet;
-  def contains(x: int): boolean;
-}
-\end{lstlisting}
-\code{IntSet} is labeled as an \emph{abstract class}. This has two
-consequences.  First, abstract classes may have {\em deferred} members
-which are declared but which do not have an implementation. In our
-case, both \code{incl} and \code{contains} are such members. Second,
-because an abstract class might have unimplemented members, no objects
-of that class may be created using \code{new}. By contrast, an
-abstract class may be used as a base class of some other class, which
-implements the deferred members.
-
-\paragraph{Traits}
-
-Instead of \code{abstract class} one also often uses the keyword
-\code{trait} in Scala. A trait is an abstract class with no state, no
-constructor arguments, and no side effects during object
-initialization.  Since \code{IntSet}'s fall in this category, one can
-alternatively define them as traits:
-\begin{lstlisting}
-trait IntSet {
-  def incl(x: int): IntSet;
-  def contains(x: int): boolean;
-}
-\end{lstlisting}
-A trait corresponds to an interface in Java, except
-that a trait can also define implemented methods.  
-
-\paragraph{Implementing Abstract Classes}
-
-Let's say, we plan to implement sets as binary trees.  There are two
-possible forms of trees. A tree for the empty set, and a tree
-consisting of an integer and two subtrees. Here are their
-implementations.
-
-\begin{lstlisting}
-class EmptySet extends IntSet {
-  def contains(x: int): boolean = false;
-  def incl(x: int): IntSet = new NonEmptySet(x, new EmptySet, new EmptySet);
-}
-\end{lstlisting}
-
-\begin{lstlisting}
-class NonEmptySet(elem:int, left:IntSet, right:IntSet) extends IntSet {
-  def contains(x: int): boolean = 
-    if (x < elem) left contains x
-    else if (x > elem) right contains x
-    else true;
-  def incl(x: int): IntSet = 
-    if (x < elem) new NonEmptySet(elem, left incl x, right)
-    else if (x > elem) new NonEmptySet(elem, left, right incl x)
-    else this;
-}
-\end{lstlisting}
-Both \code{EmptySet} and \code{NonEmptySet} extend class
-\code{IntSet}.  This implies that types \code{EmptySet} and
-\code{NonEmptySet} conform to type \code{IntSet} -- a value of type \code{EmptySet} or \code{NonEmptySet} may be used wherever a value of type \code{IntSet} is required.
-
-\begin{exercise} Write methods \code{union} and \code{intersection} to form
-the union and intersection between two sets.
-\end{exercise}
-
-\begin{exercise} Add a method 
-\begin{lstlisting}
-def excl(x: int)
-\end{lstlisting}
-to return the given set without the element \code{x}. To accomplish this,
-it is useful to also implement a test method
-\begin{lstlisting}
-def isEmpty: boolean
-\end{lstlisting}
-for sets.
-\end{exercise}
-
-\paragraph{Dynamic Binding}
-
-Object-oriented languages (Scala included) use \emph{dynamic dispatch}
-for method invocations.  That is, the code invoked for a method call
-depends on the run-time type of the object which contains the method.
-For example, consider the expression \code{s contains 7} where
-\code{s} is a value of declared type \code{s: IntSet}. Which code for
-\code{contains} is executed depends on the type of value of \code{s} at run-time.
-If it is an \code{EmptySet} value, it is the implementation of \code{contains} in class \code{EmptySet} that is executed, and analogously for \code{NonEmptySet} values. 
-This behavior is a direct consequence of our substitution model of evaluation.
-For instance,
-\begin{lstlisting}
-    (new EmptySet).contains(7) 
-
-->  $\rewriteby{by replacing {\sl contains} by its body in class {\sl EmptySet}}$
-
-    false
-\end{lstlisting}
-Or,
-\begin{lstlisting}
-    new NonEmptySet(7, new EmptySet, new EmptySet).contains(1)
-
-->  $\rewriteby{by replacing {\sl contains} by its body in class {\sl NonEmptySet}}$
-
-    if (1 < 7) new EmptySet contains 1
-    else if (1 > 7) new EmptySet contains 1
-    else true
-
-->  $\rewriteby{by rewriting the conditional}$
-
-    new EmptySet contains 1
-
-->  $\rewriteby{by replacing {\sl contains} by its body in class {\sl EmptySet}}$
-
-    false .
-\end{lstlisting}
-
-Dynamic method dispatch is analogous to higher-order function
-calls. In both cases, the identity of code to be executed is known
-only at run-time. This similarity is not just superficial. Indeed,
-Scala represents every function value as an object (see
-Section~\ref{sec:functions}).
-
-
-\paragraph{Objects}
-
-In the previous implementation of integer sets, empty sets were
-expressed with \code{new EmptySet}; so a new object was created every time
-an empty set value was required. We could have avoided unnecessary
-object creations by defining a value \code{empty} once and then using
-this value instead of every occurrence of \code{new EmptySet}. E.g.
-\begin{lstlisting}
-val EmptySetVal = new EmptySet;
-\end{lstlisting}
-One problem with this approach is that a value definition such as the
-one above is not a legal top-level definition in Scala; it has to be
-part of another class or object. Also, the definition of class
-\code{EmptySet} now seems a bit of an overkill -- why define a class of objects, 
-if we are only interested in a single object of this class? A more
-direct approach is to use an {\em object definition}. Here is
-a more streamlined alternative definition of the empty set:
-\begin{lstlisting}
-object EmptySet extends IntSet {
-  def contains(x: int): boolean = false;
-  def incl(x: int): IntSet = new NonEmptySet(x, EmptySet, EmptySet);
-}
-\end{lstlisting}
-The syntax of an object definition follows the syntax of a class
-definition; it has an optional extends clause as well as an optional
-body. As is the case for classes, the extends clause defines inherited
-members of the object whereas the body defines overriding or new
-members.  However, an object definition defines a single object only;
-it is not possible to create other objects with the same structure
-using \code{new}.  Therefore, object definitions also lack constructor
-parameters, which might be present in class definitions.
-
-Object definitions can appear anywhere in a Scala program; including
-at top-level.  Since there is no fixed execution order of top-level
-entities in Scala, one might ask exactly when the object defined by an
-object definition is created and initialized. The answer is that the
-object is created the first time one of its members is accessed. This
-strategy is called {\em lazy evaluation}.
-
-\paragraph{Standard Classes}
-
-\todo{include picture}
-
-Scala is a pure object-oriented language. This means that every value
-in Scala can be regarded as an object.  In fact, even primitive types
-such as \code{int} or \code{boolean} are not treated specially. They
-are defined as type aliases of Scala classes in module \code{Predef}:
-\begin{lstlisting}
-type boolean = scala.Boolean;
-type int = scala.Int;
-type long = scala.Long;
-...
-\end{lstlisting}
-For efficiency, the compiler usually represents values of type
-\code{scala.Int} by 32 bit integers, values of type
-\code{scala.Boolean} by Java's booleans, etc.  But it converts these
-specialized representations to objects when required, for instance
-when a primitive \code{int} value is passed to a function with a
-parameter of type \code{AnyRef}.  Hence, the special representation of
-primitive values is just an optimization, it does not change the
-meaning of a program.
-
-Here is a specification of class \code{Boolean}.
-\begin{lstlisting}
-package scala;
-trait Boolean {
-  def && (x: => Boolean): Boolean;
-  def || (x: => Boolean): Boolean;
-  def !                 : Boolean;
-
-  def == (x: Boolean)   : Boolean;
-  def != (x: Boolean)   : Boolean;
-  def <  (x: Boolean)   : Boolean;
-  def >  (x: Boolean)   : Boolean;
-  def <= (x: Boolean)   : Boolean;
-  def >= (x: Boolean)   : Boolean;
-}
-\end{lstlisting}
-Booleans can be defined using only classes and objects, without
-reference to a built-in type of booleans or numbers. A possible
-implementation of class \code{Boolean} is given below.  This is not
-the actual implementation in the standard Scala library. For
-efficiency reasons the standard implementation uses built-in
-booleans.
-\begin{lstlisting}
-package scala;
-trait Boolean {
-  def ifThenElse(thenpart: => Boolean, elsepart: => Boolean);
-
-  def && (x: => Boolean): Boolean  =  ifThenElse(x, false);
-  def || (x: => Boolean): Boolean  =  ifThenElse(true, x);
-  def !                 : Boolean  =  ifThenElse(false, true);
-
-  def == (x: Boolean)   : Boolean  =  ifThenElse(x, x.!);
-  def != (x: Boolean)   : Boolean  =  ifThenElse(x.!, x);
-  def <  (x: Boolean)   : Boolean  =  ifThenElse(false, x);
-  def >  (x: Boolean)   : Boolean  =  ifThenElse(x.!, false);
-  def <= (x: Boolean)   : Boolean  =  ifThenElse(x, true);
-  def >= (x: Boolean)   : Boolean  =  ifThenElse(true, x.!);
-}
-case object True extends Boolean {
-  def ifThenElse(t: => Boolean, e: => Boolean) = t;
-}
-case object False extends Boolean {
-  def ifThenElse(t: => Boolean, e: => Boolean) = e;
-}
-\end{lstlisting}
-Here is a partial specification of class \code{Int}.
-
-\begin{lstlisting}
-package scala;
-trait Int extends AnyVal { 
-  def coerce: Long;
-  def coerce: Float;
-  def coerce: Double;
-
-  def + (that: Double): Double;
-  def + (that: Float): Float;
-  def + (that: Long): Long;
-  def + (that: Int): Int;        // analogous for -, *, /, %
-
-  def << (cnt: Int): Int;        // analogous for >>, >>>
-
-  def & (that: Long): Long;
-  def & (that: Int): Int;        // analogous for |, ^
-
-  def == (that: Double): Boolean;
-  def == (that: Float): Boolean;
-  def == (that: Long): Boolean;  // analogous for !=, <, >, <=, >=
-}
-\end{lstlisting}
-
-Class \code{Int} can in principle also be implemented using just
-objects and classes, without reference to a built in type of
-integers. To see how, we consider a slightly simpler problem, namely
-how to implement a type \code{Nat} of natural (i.e. non-negative)
-numbers. Here is the definition of a trait \code{Nat}:
-\begin{lstlisting}
-trait Nat {
-  def isZero: Boolean;
-  def predecessor: Nat;
-  def successor: Nat;
-  def + (that: Nat): Nat;
-  def - (that: Nat): Nat;
-}
-\end{lstlisting}
-To implement the operations of class \code{Nat}, we define a sub-object
-\code{Zero} and a subclass \code{Succ} (for successor). Each number
-\code{N} is represented as \code{N} applications of the \code{Succ}
-constructor to \code{Zero}:
-\[
-\underbrace{\mbox{\sl new Succ( ... new Succ}}_{\mbox{$N$ times}}\mbox{\sl (Zero) ... )}
-\]
-The implementation of the \code{Zero} object is straightforward:
-\begin{lstlisting}
-object Zero extends Nat {
-  def isZero: Boolean = true;
-  def predecessor: Nat = throw new Error("negative number");
-  def successor: Nat = new Succ(Zero);
-  def + (that: Nat): Nat = that;
-  def - (that: Nat): Nat = if (that.isZero) Zero 
-                           else throw new Error("negative number")
-}
-\end{lstlisting}
-
-The implementation of the predecessor and subtraction functions on
-\code{Zero} throws an \code{Error} exception, which aborts the program
-with the given error message.
-
-Here is the implementation of the successor class:
-\begin{lstlisting}
-class Succ(x: Nat) extends Nat  {
-  def isZero: Boolean = false;
-  def predecessor: Nat = x;
-  def successor: Nat = new Succ(this);
-  def + (that: Nat): Nat = x + that.successor;
-  def - (that: Nat): Nat = x - that.predecessor;
-}
-\end{lstlisting}
-Note the implementation of method \code{successor}. To create the
-successor of a number, we need to pass the object itself as an
-argument to the \code{Succ} constructor.  The object itself is
-referenced by the reserved name \code{this}.   
-
-The implementations of \code{+} and \code{-} each contain a recursive
-call with the constructor argument as receiver. The recursion will
-terminate once the receiver is the \code{Zero} object (which is
-guaranteed to happen eventually because of the way numbers are formed).
-
-\begin{exercise} Write an implementation \code{Integer} of integer numbers
-The implementation should support all operations of class \code{Nat}
-while adding two methods
-\begin{lstlisting}
-def isPositive: Boolean;
-def negate: Integer;
-\end{lstlisting}
-The first method should return \code{true} if the number is positive. The second method should negate the number.
-Do not use any of Scala's standard numeric classes in your
-implementation. (Hint: There are two possible ways to implement
-\code{Integer}. One can either make use the existing implementation of
-\code{Nat}, representing an integer as a natural number and a sign.
-Or one can generalize the given implementation of \code{Nat} to
-\code{Integer}, using the three subclasses \code{Zero} for 0, 
-\code{Succ} for positive numbers and \code{Pred} for negative numbers.)
-\end{exercise}
-
-
-
-\subsection*{Language Elements Introduced In This Chapter}
-
-\textbf{Types:}
-\begin{lstlisting}
-Type         = ...  |  ident
-\end{lstlisting}
-
-Types can now be arbitrary identifiers which represent classes.
-
-\textbf{Expressions:}
-\begin{lstlisting}
-Expr         = ...  |  Expr '.' ident  |  'new' Expr  |  'this'
-\end{lstlisting}
-
-An expression can now be an object creation, or
-a selection \code{E.m} of a member \code{m}
-from an object-valued expression \code{E}, or it can be the reserved name \code{this}.
-
-\textbf{Definitions and Declarations:}
-\begin{lstlisting}
-Def          = FunDef  |  ValDef  |  ClassDef  |  TraitDef  |  ObjectDef
-ClassDef     = ['abstract'] 'class' ident ['(' [Parameters] ')'] 
-               ['extends' Expr] [`{' {TemplateDef} `}']
-TraitDef     = 'trait' ident ['extends' Expr] ['{' {TemplateDef} '}']
-ObjectDef    = 'object' ident ['extends' Expr] ['{' {ObjectDef} '}']
-TemplateDef  = [Modifier] (Def | Dcl)
-ObjectDef    = [Modifier] Def
-Modifier     = 'private'  |  'override'
-Dcl          = FunDcl  |  ValDcl
-FunDcl       = 'def' ident {'(' [Parameters] ')'} ':' Type
-ValDcl       = 'val' ident ':' Type
-\end{lstlisting}
-
-A definition can now be a class, trait or object definition such as
-\begin{lstlisting}
-class C(params) extends B { defs }
-trait T extends B { defs }
-object O extends B { defs }
-\end{lstlisting}
-The definitions \code{defs} in a class, trait or object may be
-preceded by modifiers \code{private} or \code{override}.
-
-Abstract classes and traits may also contain declarations. These
-introduce {\em deferred} functions or values with their types, but do
-not give an implementation. Deferred members have to be implemented in
-subclasses before objects of an abstract class or trait can be created.
-
-\chapter{Case Classes and Pattern Matching}
-
-Say, we want to write an interpreter for arithmetic expressions.  To
-keep things simple initially, we restrict ourselves to just numbers
-and \code{+} operations. Such expressions can be represented as a class hierarchy, with an abstract base class \code{Expr} as the root, and two subclasses \code{Number} and
-\code{Sum}. Then, an expression \code{1 + (3 + 7)} would be represented as
-\begin{lstlisting}
-new Sum(new Number(1), new Sum(new Number(3), new Number(7)))
-\end{lstlisting}
-Now, an evaluator of an expression like this needs to know of what
-form it is (either \code{Sum} or \code{Number}) and also needs to
-access the components of the expression.  The following
-implementation provides all necessary methods.
-\begin{lstlisting}
-trait Expr {
-  def isNumber: boolean;
-  def isSum: boolean;
-  def numValue: int;
-  def leftOp: Expr;
-  def rightOp: Expr;
-}
-class Number(n: int) extends Expr {
-  def isNumber: boolean = true;
-  def isSum: boolean = false;
-  def numValue: int = n;
-  def leftOp: Expr = throw new Error("Number.leftOp");
-  def rightOp: Expr = throw new Error("Number.rightOp");
-}
-class Sum(e1: Expr, e2: Expr) extends Expr {
-  def isNumber: boolean = false;
-  def isSum: boolean = true;
-  def numValue: int = throw new Error("Sum.numValue");
-  def leftOp: Expr = e1;
-  def rightOp: Expr = e2;
-}
-\end{lstlisting}
-With these classification and access methods, writing an evaluator function is simple:
-\begin{lstlisting}
-def eval(e: Expr): int = {
-  if (e.isNumber) e.numValue
-  else if (e.isSum) eval(e.leftOp) + eval(e.rightOp)
-  else throw new Error("unrecognized expression kind")
-}
-\end{lstlisting}
-However, defining all these methods in classes \code{Sum} and
-\code{Number} is rather tedious. Furthermore, the problem becomes worse 
-when we want to add new forms of expressions. For instance, consider
-adding a new expression form
-\code{Prod} for products. Not only do we have to implement a new class \code{Prod}, with all previous classification and access methods; we also have to introduce a
-new abstract method \code{isProduct} in class \code{Expr} and
-implement that method in subclasses \code{Number}, \code{Sum}, and
-\code{Prod}. Having to modify existing code when a system grows is always problematic, since it introduces versioning and maintenance problems. 
-
-The promise of object-oriented programming is that such modifications
-should be unnecessary, because they can be avoided by re-using
-existing, unmodified code through inheritance. Indeed, a more
-object-oriented decomposition of our problem solves the problem.  The
-idea is to make the ``high-level'' operation \code{eval} a method of
-each expression class, instead of implementing it as a function
-outside the expression class hierarchy, as we have done
-before. Because \code{eval} is now a member of all expression nodes,
-all classification and access methods become superfluous, and the implementation is simplified considerably:
-\begin{lstlisting}
-trait Expr {
-  def eval: int;
-}
-class Number(n: int) extends Expr {
-  def eval: int = n;
-}
-class Sum(e1: Expr, e2: Expr) extends Expr {
-  def eval: int = e1.eval + e2.eval;
-}
-\end{lstlisting}
-Furthermore, adding a new \code{Prod} class does not entail any changes to existing code:
-\begin{lstlisting}
-class Prod(e1: Expr, e2: Expr) extends Expr {
-  def eval: int = e1.eval * e2.eval;
-}
-\end{lstlisting}
-
-The conclusion we can draw from this example is that object-oriented
-decomposition is the technique of choice for constructing systems that
-should be extensible with new types of data. But there is also another
-possible way we might want to extend the expression example. We might
-want to add new {\em operations} on expressions.  For instance, we might
-want to add an operation that pretty-prints an expression tree to standard output.
-
-If we have defined all classification and access methods, such an
-operation can easily be written as an external function. Here is an
-implementation:
-\begin{lstlisting}
-def print(e: Expr): unit = 
-  if (e.isNumber) System.out.print(e.numValue)
-  else if (e.isSum) {
-    System.out.print("("); 
-    print(e.leftOp); 
-    System.out.print("+");
-    print(e.rightOp);
-    System.out.print(")");
-  } else throw new Error("unrecognized expression kind");
-\end{lstlisting}
-However, if we had opted for an object-oriented decomposition of
-expressions, we would need to add a new \code{print} method
-to each class:
-\begin{lstlisting}
-trait Expr {
-  def eval: int;
-  def print: unit;
-}
-class Number(n: int) extends Expr {
-  def eval: int = n;
-  def print: unit = System.out.print(n);
-}
-class Sum(e1: Expr, e2: Expr) extends Expr {
-  def eval: int = e1.eval + e2.eval;
-  def print: unit = {
-    System.out.print("("); 
-    print(e1); 
-    System.out.print("+");
-    print(e2);
-    System.out.print(")");
-}
-\end{lstlisting}
-Hence, classical object-oriented decomposition requires modification
-of all existing classes when a system is extended with new operations.
-
-As yet another way we might want to extend the interpreter, consider
-expression simplification. For instance, we might want to write a
-function which rewrites expressions of the form
-\code{a * b + a * c} to \code{a * (b + c)}. This operation requires inspection of 
-more than a single node of the expression tree at the same
-time. Hence, it cannot be implemented by a method in each expression
-kind, unless that method can also inspect other nodes. So we are
-forced to have classification and access methods in this case. This
-seems to bring us back to square one, with all the problems of
-verbosity and extensibility.
-
-Taking a closer look, one observers that the only purpose of the
-classification and access functions is to {\em reverse} the data
-construction process.  They let us determine, first, which sub-class
-of an abstract base class was used and, second, what were the
-constructor arguments. Since this situation is quite common, Scala has
-a way to automate it with case classes. 
-
-\section{Case Classes and Case Objects}
-
-{\em Case classes} and {\em case objects} are defined like a normal
-classes or objects, except that the definition is prefixed with the modifier
-\code{case}.  For instance, the definitions
-\begin{lstlisting}
-trait Expr;
-case class Number(n: int) extends Expr;
-case class Sum(e1: Expr, e2: Expr) extends Expr;
-\end{lstlisting}
-introduce \code{Number} and \code{Sum} as case classes.
-The \code{case} modifier in front of a class or object 
-definition has the following effects.
-\begin{enumerate}
-\item Case classes implicitly come with a constructor function, with the same name as the class. In our example, the two functions
-\begin{lstlisting}
-def Number(n: int) = new Number(n);
-def Sum(e1: Expr, e2: Expr) = new Sum(e1, e2);
-\end{lstlisting}
-would be added. Hence, one can now construct expression trees a bit more concisely, as in
-\begin{lstlisting}
-Sum(Sum(Number(1), Number(2)), Number(3))
-\end{lstlisting} 
-\item Case classes and case objects 
-implicitly come with implementations of methods
-\code{toString}, \code{equals} and \code{hashCode}, which override the
-methods with the same name in class \code{AnyRef}. The implementation
-of these methods takes in each case the structure of a member of a
-case class into account. The \code{toString} method represents an
-expression tree the way it was constructed. So,
-\begin{lstlisting}
-Sum(Sum(Number(1), Number(2)), Number(3))
-\end{lstlisting} 
-would be converted to exactly that string, whereas the default
-implementation in class \code{AnyRef} would return a string consisting
-of the outermost constructor name \code{Sum} and a number.  The
-\code{equals} methods treats two case members of a case class as equal
-if they have been constructed with the same constructor and with
-arguments which are themselves pairwise equal. This also affects the
-implementation of \code{==} and \code{!=}, which are implemented in
-terms of \code{equals} in Scala. So,
-\begin{lstlisting}
-Sum(Number(1), Number(2)) == Sum(Number(1), Number(2))
-\end{lstlisting}
-will yield \code{true}. If \code{Sum} or \code{Number} were not case
-classes, the same expression would be \code{false}, since the standard
-implementation of \code{equals} in class \code{AnyRef} always treats
-objects created by different constructor calls as being different.
-The \code{hashCode} method follows the same principle as other two
-methods. It computes a hash code from the case class constructor name
-and the hash codes of the constructor arguments, instead of from the object's
-address, which is what the as the default implementation of \code{hashCode} does.
-\item 
-Case classes implicitly come with nullary accessor methods which
-retrieve the constructor arguments.
-In our example, \code{Number} would obtain an accessor method
-\begin{lstlisting}
-def n: int;
-\end{lstlisting}
-which returns the constructor parameter \code{n}, whereas \code{Sum} would obtain two accessor methods
-\begin{lstlisting}
-def e1: Expr, e2: Expr;
-\end{lstlisting}
-Hence, if for a value \code{s} of type \code{Sum}, say, one can now
-write \code{s.e1}, to access the left operand. However, for a value
-\code{e} of type \code{Expr}, the term \code{e.e1} would be illegal
-since \code{e1} is defined in \code{Sum}; it is not a member of the
-base class \code{Expr}. 
-So, how do we determine the constructor and access constructor
-arguments for values whose static type is the base class \code{Expr}?
-This is solved by the fourth and final particularity of case classes.
-\item 
-Case classes allow the constructions of {\em patterns} which refer to
-the case class constructor.
-\end{enumerate}
-
-\section{Pattern Matching}
-
-Pattern matching is a generalization of C or Java's \code{switch}
-statement to class hierarchies. Instead of a \code{switch} statement,
-there is a standard method \code{match}, which is defined in Scala's
-root class \code{Any}, and therefore is available for all objects.
-The \code{match} method takes as argument a number of cases. 
-For instance, here is an implementation of \code{eval} using 
-pattern matching.
-\begin{lstlisting}
-def eval(e: Expr): int = e match { 
-  case Number(x) => x 
-  case Sum(l, r) => eval(l) + eval(r) 
-}
-\end{lstlisting}
-In this example, there are two cases. Each case associates a pattern
-with an expression. Patterns are matched against the selector
-values \code{e}.  The first pattern in our example,
-\code{Number(n)}, matches all values of the form \code{Number(v)}, 
-where \code{v} is an arbitrary value.  In that case, the {\em pattern
-variable} \code{n} is bound to the value \code{v}. Similarly, the
-pattern \code{Sum(l, r)} matches all selector values of form
-\code{Sum(v}$_1$\code{, v}$_2$\code{)} and binds the pattern variables
-\code{l} and \code{r} 
-to \code{v}$_1$ and \code{v}$_2$, respectively. 
-
-In general, patterns are built from
-\begin{itemize}
-\item Case class constructors, e.g. \code{Number}, \code{Sum}, whose arguments
-      are again patterns,
-\item pattern variables, e.g. \code{n}, \code{e1}, \code{e2},
-\item the ``wildcard'' pattern \code{_},
-\item literals, e.g. \code{1}, \code{true}, "abc", 
-\item constant identifiers, e.g. \code{MAXINT}, \code{EmptySet}.
-\end{itemize}
-Pattern variables always start with a lower-case letter, so that they
-can be distinguished from constant identifiers, which start with an
-upper case letter.  Each variable name may occur only once in a
-pattern. For instance, \code{Sum(x, x)} would be illegal as a pattern,
-since the pattern variable \code{x} occurs twice in it.
-
-\paragraph{Meaning of Pattern Matching}
-A pattern matching expression 
-\begin{lstlisting}
-e match { case p$_1$ => e$_1$ ... case p$_n$ => e$_n$ }
-\end{lstlisting}
-matches the patterns $p_1 \commadots p_n$ in the order they
-are written against the selector value \code{e}.
-\begin{itemize}
-\item
-A constructor pattern $C(p_1 \commadots p_n)$ matches all values that
-are of type \code{C} (or a subtype thereof) and that have been constructed with 
-\code{C}-arguments matching patterns $p_1 \commadots p_n$.
-\item 
-A variable pattern \code{x} matches any value and binds the variable
-name to that value.  
-\item 
-The wildcard pattern `\code{_}' matches any value but does not bind a name to that value. 
-\item A constant pattern \code{C} matches a value which is
-equal (in terms of \code{==}) to \code{C}.
-\end{itemize}
-The pattern matching expression rewrites to the right-hand-side of the
-first case whose pattern matches the selector value. References to
-pattern variables are replaced by corresponding constructor arguments.
-If none of the patterns matches, the pattern matching expression is
-aborted with a \code{MatchError} exception.
-
-\example Our substitution model of program evaluation extends quite naturally to pattern matching, For instance, here is how \code{eval} applied to a simple expression is re-written:
-\begin{lstlisting}
-     eval(Sum(Number(1), Number(2)))
-
-->   $\mbox{\tab\tab\rm(by rewriting the application)}$
-
-     Sum(Number(1), Number(2)) match {
-         case Number(n) => n
-         case Sum(e1, e2) => eval(e1) + eval(e2)
-     }
-
-->   $\mbox{\tab\tab\rm(by rewriting the pattern match)}$
-
-     eval(Number(1)) + eval(Number(2))
-
-->   $\mbox{\tab\tab\rm(by rewriting the first application)}$
-
-     Number(1) match {
-         case Number(n) => n
-         case Sum(e1, e2) => eval(e1) + eval(e2)
-     } + eval(Number(2))
-
-->   $\mbox{\tab\tab\rm(by rewriting the pattern match)}$
-
-     1 + eval(Number(2))
-
-->$^*$ 1 + 2 -> 3
-\end{lstlisting}
-
-\paragraph{Pattern Matching and Methods}
-In the previous example, we have used pattern
-matching in a function which was defined outside the class hierarchy
-over which it matches.  Of course, it is also possible to define a
-pattern matching function in that class hierarchy itself. For
-instance, we could have defined
-\code{eval} is a method of the base class \code{Expr}, and still have used pattern matching in its implementation:
-\begin{lstlisting}
-trait Expr { 
-  def eval: int = this match { 
-    case Number(n) => n
-    case Sum(e1, e2) => e1.eval + e2.eval 
-  } 
-}
-\end{lstlisting}
-
-\begin{exercise} Consider the following definitions representing trees
-of integers.  These definitions can be seen as an alternative
-representation of \code{IntSet}:
-\begin{lstlisting}
-trait IntTree;
-case object EmptyTree extends IntTree;
-case class  Node(elem: int, left: IntTree, right: IntTree) extends IntTree;
-\end{lstlisting}
-Complete the following implementations of function \code{contains} and \code{insert} for 
-\code{IntTree}'s.
-\begin{lstlisting} 
-def contains(t: IntTree, v: int): boolean = t match { ... 
-  ...
-}
-def insert(t: IntTree, v: int): IntTree = t match { ... 
-  ...
-}
-\end{lstlisting}
-\end{exercise}
-
-\paragraph{Pattern Matching Anonymous Functions}
-
-So far, case-expressions always appeared in conjunction with a
-\verb@match@ operation. But it is also possible to use
-case-expressions by themselves. A block of case-expressions such as
-\begin{lstlisting}
-{ case $P_1$ => $E_1$ ... case $P_n$ => $E_n$ }
-\end{lstlisting}
-is seen by itself as a function which matches its arguments
-against the patterns $P_1 \commadots P_n$, and produces the result of
-one of $E_1 \commadots E_n$. (If no pattern matches, the function
-would throw a \code{MatchError} exception instead).
-In other words, the expression above is seen as a shorthand for the anonymous function
-\begin{lstlisting}
-(x => x match { case $P_1$ => $E_1$ ... case $P_n$ => $E_n$ })
-\end{lstlisting}
-where \code{x} is a fresh variable which is not used 
-otherwise in the expression.
-
-\chapter{Generic Types and Methods}
-
-Classes in Scala can have type parameters. We demonstrate the use of
-type parameters with functional stacks as an example. Say, we want to
-write a data type of stacks of integers, with methods \code{push},
-\code{top}, \code{pop}, and \code{isEmpty}. This is achieved by the
-following class hierarchy:
-\begin{lstlisting}
-trait IntStack {
-  def push(x: int): IntStack = new IntNonEmptyStack(x, this);
-  def isEmpty: boolean;
-  def top: int;
-  def pop: IntStack;
-}
-class IntEmptyStack extends IntStack {
-  def isEmpty = true;
-  def top = throw new Error("EmptyStack.top");
-  def pop = throw new Error("EmptyStack.pop");
-}
-class IntNonEmptyStack(elem: int, rest: IntStack) {
-  def isEmpty = false;
-  def top = elem;
-  def pop = rest;
-}
-\end{lstlisting}
-Of course, it would also make sense to define an abstraction for a
-stack of Strings. To do that, one could take the existing abstraction
-for \code{IntStack}, rename it to \code{StringStack} and at the same
-time rename all occurrences of type \code{int} to \code{String}.
-
-A better way, which does not entail code duplication, is to
-parameterize the stack definitions with the element type.
-Parameterization lets us generalize from a specific instance of a
-problem to a more general one. So far, we have used parameterization
-only for values, but it is available also for types. To arrive at a
-{\em generic} version of \code{Stack}, we equip it with a type
-parameter.
-\begin{lstlisting}
-trait Stack[a] {
-  def push(x: a): Stack[a] = new NonEmptyStack[a](x, this);
-  def isEmpty: boolean
-  def top: a;
-  def pop: Stack[a];
-}
-class EmptyStack[a] extends Stack[a] {
-  def isEmpty = true;
-  def top = throw new Error("EmptyStack.top");
-  def pop = throw new Error("EmptyStack.pop");
-}
-class NonEmptyStack[a](elem: a, rest: Stack[a]) extends Stack[a] {
-  def isEmpty = false;
-  def top = elem;
-  def pop = rest;
-}
-\end{lstlisting}
-In the definitions above, `\code{a}' is a {\em type parameter} of
-class \code{Stack} and its subclasses.  Type parameters are arbitrary
-names; they are enclosed in brackets instead of parentheses, so that
-they can be easily distinguished from value parameters.  Here is an
-example how the generic classes are used:
-\begin{lstlisting}
-val x = new EmptyStack[int];
-val y = x.push(1).push(2);
-System.out.println(y.pop.top);
-\end{lstlisting}
-The first line creates a new empty stack of \code{int}'s. Note the
-actual type argument \code{[int]} which replaces the formal type
-parameter \code{a}.
-
-It is also possible to parameterize methods with types. As an example,
-here is a generic method which determines whether one stack is a
-prefix of another.
-\begin{lstlisting}
-def isPrefix[a](p: Stack[a], s: Stack[a]): boolean = {
-  p.isEmpty ||
-  p.top == s.top && isPrefix[a](p.pop, s.pop);
-}
-\end{lstlisting}  
-parameters are called {\em polymorphic}.  Generic methods are also
-called {\em polymorphic}.  The term comes from the Greek, where it
-means ``having many forms''.  To apply a polymorphic method such as
-\code{isPrefix}, we pass type parameters as well as value parameters
-to it. For instance,
-\begin{lstlisting}
-val s1 = new EmptyStack[String].push("abc");
-val s2 = new EmptyStack[String].push("abx").push(s.pop)
-System.out.println(isPrefix[String](s1, s2));
-\end{lstlisting}
-
-\paragraph{Local Type Inference}
-Passing type parameters such as \code{[int]} or \code{[String]} all
-the time can become tedious in applications where generic functions
-are used a lot. Quite often, the information in a type parameter is
-redundant, because the correct parameter type can also be determined
-by inspecting the function's value parameters or expected result type.
-Taking the expression \code{isPrefix[String](s1, s2)} as an
-example, we know that its value parameters are both of type
-\code{Stack[String]}, so we can deduce that the type parameter must
-be \code{String}. Scala has a fairly powerful type inferencer which
-allows one to omit type parameters to polymorphic functions and
-constructors in situations like these.  In the example above, one
-could have written \code{isPrefix(s1, s2)} and the missing type argument
-\code{[String]} would have been inserted by the type inferencer. 
-
-\section{Type Parameter Bounds}
-
-Now that we know how to make classes generic it is natural to
-generalize some of the earlier classes we have written. For instance
-class \code{IntSet} could be generalized to sets with arbitrary
-element types. Let's try. The trait for generic sets is easily
-written.
-\begin{lstlisting}
-trait Set[a] { 
-  def incl(x: a): Set[a]; 
-  def contains(x: a): boolean; 
-}
-\end{lstlisting}
-However, if we still want to implement sets as binary search trees, we
-encounter a problem. The \code{contains} and \code{incl} methods both
-compare elements using methods \code{<} and \code{>}. For
-\code{IntSet} this was OK, since type \code{int} has these two
-methods. But for an arbitrary type parameter \code{a}, we cannot
-guarantee this. Therefore, the previous implementation of, say,
-\code{contains} would generate a compiler error.
-\begin{lstlisting}
-  def contains(x: int): boolean = 
-    if (x < elem) left contains x
-          ^ < $\mbox{\sl not a member of type}$ a.
-\end{lstlisting}
-One way to solve the problem is to restrict the legal types that can
-be substituted for type \code{a} to only those types that contain methods
-\code{<} and \code{>} of the correct types. There is a trait
-\code{Ord[a]} in the standard class library Scala which represents
-values which are comparable (via \code{<} and \code{>}) to values of
-type \code{a}. We can enforce the comparability of a type by demanding
-that the type is a subtype of \code{Ord}. This is done by giving an
-upper bound to the type parameter of \code{Set}:
-\begin{lstlisting}
-trait Set[a <: Ord[a]] { 
-  def incl(x: a): Set[a]; 
-  def contains(x: a): boolean; 
-}
-\end{lstlisting}
-The parameter declaration \code{a <: Ord[a]} introduces \code{a} as a
-type parameter which must be a subtype of \code{Ord[a]}, i.e.\ its values
-must be comparable to values of the same type.
-
-With this restriction, we can now implement the rest of the generic
-set abstraction as we did in the case of \code{IntSet}s before.
-
-\begin{lstlisting}
-class EmptySet[a <: Ord[a]] extends Set[a] {
-  def contains(x: a): boolean = false;
-  def incl(x: a): Set[a] = new NonEmptySet(x, new EmptySet[a], new EmptySet[a]);
-}
-\end{lstlisting}
-
-\begin{lstlisting}
-class NonEmptySet[a <: Ord[a]]
-        (elem:a, left: Set[a], right: Set[a]) extends Set[a] {
-  def contains(x: a): boolean = 
-    if (x < elem) left contains x
-    else if (x > elem) right contains x
-    else true;
-  def incl(x: a): Set[a] = 
-    if (x < elem) new NonEmptySet(elem, left incl x, right)
-    else if (x > elem) new NonEmptySet(elem, left, right incl x)
-    else this;
-}
-\end{lstlisting}
-Note that we have left out the type argument in the object creations
-\code{new NonEmptySet(...)}. In the same way as for polymorphic methods,
-missing type arguments in constructor calls are inferred from value
-arguments and/or the expected result type.
-
-Here is an example that uses the generic set abstraction.
-\begin{lstlisting}
-val s = new EmptySet[double].incl(1.0).incl(2.0);
-s.contains(1.5)
-\end{lstlisting}
-This is OK, as type \code{double} implements trait \code{Ord[double]}.
-However, the following example is in error.
-\begin{lstlisting}
-val s = new EmptySet[java.io.File]
-                    ^ java.io.File $\mbox{\sl does not conform to type}$
-                      $\mbox{\sl parameter bound}$ Ord[java.io.File].
-\end{lstlisting}
-To conclude the discussion of type parameter
-bounds, here is the definition of trait \code{Ord} in scala.
-\begin{lstlisting}
-package scala;
-trait Ord[t <: Ord[t]]: t {
-  def < (that: t): Boolean;
-  def <=(that: t): Boolean = this < that || this == that;
-  def > (that: t): Boolean = that < this;
-  def >=(that: t): Boolean = that <= this;
-}
-\end{lstlisting}
-
-\section{Variance Annotations}\label{sec:first-arrays}
-
-The combination of type parameters and subtyping poses some
-interesting questions. For instance, should \code{Stack[String]} be a
-subtype of \code{Stack[AnyRef]}? Intuitively, this seems OK, since a
-stack of \code{String}s is a special case of a stack of
-\code{AnyRef}s.  More generally, if \code{T} is a subtype of type \code{S}
-then \code{Stack[T]} should be a subtype of \code{Stack[S]}. 
-This property is called {\em co-variant} subtyping.
-
-In Scala, generic types have by default non-variant subtyping. That
-is, with \code{Stack} defined as above, stacks with different element
-types would never be in a subtype relation. However, we can enforce
-co-variant subtyping of stacks by changing the first line of the
-definition of class \code{Stack} as follows.
-\begin{lstlisting}
-class Stack[+a] {
-\end{lstlisting}
-Prefixing a formal type parameter with a \code{+} indicates that
-subtyping is covariant in that parameter. 
-Besides \code{+}, there is also a prefix \code{-} which indicates
-contra-variant subtyping. If \code{Stack} was defined \code{class
-Stack[-a] ...}, then \code{T} a subtype of type \code{S} would imply
-that \code{Stack[S]} is a subtype of \code{Stack[T]} (which in the
-case of stacks would be rather surprising!).
-
-In a purely functional world, all types could be co-variant. However,
-the situation changes once we introduce mutable data. Consider the
-case of arrays in Java or .NET. Such arrays are represented in Scala
-by a generic class \code{Array}. Here is a partial definition of this
-class.
-\begin{lstlisting}
-class Array[a] {
-  def apply(index: int): a;
-  def update(index: int, elem: a): unit;
-}
-\end{lstlisting}
-The class above defines the way Scala arrays are seen from Scala user
-programs. The Scala compiler will map this abstraction to the
-underlying arrays of the host system in most cases where this
-possible.
-
-In Java, arrays are indeed covariant; that is, for reference types
-\code{T} and \code{S}, if \code{T} is a subtype of \code{S}, then also
-\code{Array[T]} is a subtype of \code{Array[S]}. This might seem
-natural but leads to safety problems that require special runtime
-checks. Here is an example:
-\begin{lstlisting}
-val x = new Array[String](1);
-val y: Array[Any] = x;
-y(0) = new Rational(1, 2); // this is syntactic sugar for 
-                           // y.update(0, new Rational(1, 2));
-\end{lstlisting}
-In the first line, a new array of strings is created. In the second
-line, this array is bound to a variable \code{y}, of type
-\code{Array[Any]}.  Assuming arrays are covariant, this is OK, since
-\code{Array[String]} is a subtype of \code{Array[Any]}. Finally, in
-the last line a rational number is stored in the array. This is also
-OK, since type \code{Rational} is a subtype of the element type
-\code{Any} of the array \code{y}. We thus end up storing a rational
-number in an array of strings, which clearly violates type soundness. 
-
-Java solves this problem by introducing a run-time check in the third
-line which tests whether the stored element is compatible with the
-element type with which the array was created. We have seen in the
-example that this element type is not necessarily the static element
-type of the array being updated. If the test fails, an
-\code{ArrayStoreException} is raised.
-
-Scala solves this problem instead statically, by disallowing the
-second line at compile-time, because arrays in Scala have non-variant
-subtyping. This raises the question how a Scala compiler verifies that
-variance annotations are correct. If we had simply declared arrays
-co-variant, how would the potential problem have been detected?
-
-Scala uses a conservative approximation to verify soundness of
-variance annotations.  A covariant type parameter of a class may only
-appear in co-variant positions inside the class.  Among the co-variant
-positions are the types of values in the class, the result types of
-methods in the class, and type arguments to other covariant types. Not
-co-variant are types of formal method parameters. Hence, the following
-class definition would have been rejected
-\begin{lstlisting}
-class Array[+a] {
-  def apply(index: int): a;
-  def update(index: int, elem: a): unit;
-                               ^ $\mbox{\sl covariant type parameter}$ a
-                                 $\mbox{\sl appears in contravariant position.}$
-}
-\end{lstlisting}
-So far, so good. Intuitively, the compiler was correct in rejecting
-the \code{update} method in a co-variant class because \code{update}
-potentially changes state, and therefore undermines the soundness of
-co-variant subtyping. 
-
-However, there are also methods which do not mutate state, but where a
-type parameter still appears contra-variantly. An example is
-\code{push} in type \code{Stack}. Again the Scala compiler will reject
-the definition of this method for co-variant stacks.
-\begin{lstlisting}
-class Stack[+a] {
-  def push(x: a): Stack[a] = 
-              ^ $\mbox{\sl covariant type parameter}$ a
-                $\mbox{\sl appears in contravariant position.}$
-\end{lstlisting}
-This is a pity, because, unlike arrays, stacks are purely functional data
-structures and therefore should enable co-variant subtyping. However,
-there is a a way to solve the problem by using a polymorphic method
-with a lower type parameter bound.
-
-\section{Lower Bounds}
-
-We have seen upper bounds for type parameters. In a type parameter
-declaration such as \code{t <: U}, the type parameter \code{t} is
-restricted to range only over subtypes of type \code{U}. Symmetrical
-to this are lower bounds in Scala. In a type parameter declaration
-\code{t >: L}, the type parameter \code{t} is restricted to range only
-over {\em supertypes} of type \code{L}. (One can also combine lower and
-upper bounds, as in \code{t >: L <: U}.)
-
-Using lower bounds, we can generalize the \code{push} method in
-\code{Stack} as follows.
-\begin{lstlisting}
-class Stack[+a] {
-  def push[b >: a](x: b): Stack[b] = new NonEmptyStack(x, this);
-\end{lstlisting}
-Technically, this solves our variance problem since now the type
-parameter \code{a} appears no longer as a parameter type of method
-\code{push}. Instead, it appears as lower bound for another type
-parameter of a method, which is classified as a co-variant position.
-Hence, the Scala compiler accepts the new definition of \code{push}.
-
-In fact, we have not only solved the technical variance problem but
-also have generalized the definition of \code{push}.  Before, we were
-required to push only elements with types that conform to the declared
-element type of the stack. Now, we can push also elements of a
-supertype of this type, but the type of the returned stack will change
-accordingly. For instance, we can now push an \code{AnyRef} onto a
-stack of \code{String}s, but the resulting stack will be a stack of
-\code{AnyRef}s instead of a stack of \code{String}s!
-
-In summary, one should not hesitate to add variance annotations to
-your data structures, as this yields rich natural subtyping
-relationships. The compiler will detect potential soundness
-problems. Even if the compiler's approximation is too conservative, as
-in the case of method \code{push} of class \code{Stack}, this will
-often suggest a useful generalization of the contested method.
-
-\section{Least Types}
-
-Scala does not allow one to parameterize objects with types. That's
-why we originally defined a generic class \code{EmptyStack[a]}, even
-though a single value denoting empty stacks of arbitrary type would
-do. For co-variant stacks, however, one can use the following idiom:
-\begin{lstlisting}
-object EmptyStack extends Stack[All] { ... }
-\end{lstlisting}
-The identifier \code{All} refers to the bottom type \code{scala.All},
-which is a subtype of all other types. Hence, for co-variant stacks,
-\code{Stack[All]} is a subtype of \code{Stack[T]}, for any other type
-\code{T}. This makes it possible to use a single empty stack object
-in user code. For instance:
-\begin{lstlisting}
-val s = EmptyStack.push("abc").push(new AnyRef());
-\end{lstlisting}
-Let's analyze the type assignment for this expression in detail.  The
-\code{EmptyStack} object is of type \code{Stack[All]}, which has a
-method
-\begin{lstlisting}
-push[b >: All](elem: b): Stack[b] .
-\end{lstlisting}
-Local type inference will determine that the type parameter \code{b}
-should be instantiated to \code{String} in the application 
-\code{EmptyStack.push("abc")}. The result type of that application is hence
-\code{Stack[String]}, which in turn has a method
-\begin{lstlisting}
-push[b >: String](elem: b): Stack[b] .
-\end{lstlisting}
-The final part of the value definition above is the application of
-this method to \code{new AnyRef()}. Local type inference will
-determine that the type parameter \code{b} should this time be
-instantiated to \code{AnyRef}, with result type \code{Stack[AnyRef]}.
-Hence, the type assigned to value \code{s} is \code{Stack[AnyRef]}.
-
-Besides \code{scala.All}, which is a subtype of every other type,
-there is also the type \code{scala.AllRef}, which is a subtype of
-\code{scala.AnyRef}, and every type derived from it. The \code{null}
-literal in Scala is of that type. This makes \code{null} compatible
-with every reference type, but not with a value type such as
-\code{int}.
-
-We conclude this section with the complete improved definition of
-stacks. Stacks have now co-variant subtyping, the \code{push} method
-has been generalized, and the empty stack is represented by a single
-object.
-\begin{lstlisting}
-trait Stack[+a] {
-  def push[b >: a](x: b): Stack[b] = new NonEmptyStack(x, this);
-  def isEmpty: boolean;
-  def top: a;
-  def pop: Stack[a];
-}
-object EmptyStack extends Stack[All] {
-  def isEmpty = true;
-  def top = throw new Error("EmptyStack.top");
-  def pop = throw new Error("EmptyStack.pop");
-}
-class NonEmptyStack[+a](elem: a, rest: Stack[a]) extends Stack[a] {
-  def isEmpty = false;
-  def top = elem;
-  def pop = rest;
-}
-\end{lstlisting}
-Many classes in the Scala library are generic. We now present two
-commonly used families of generic classes, tuples and functions. The
-discussion of another common class, lists, is deferred to the next
-chapter.
-
-\section{Tuples}
-
-Sometimes, a function needs to return more than one result. For
-instance, take the function \code{divmod} which returns the integer quotient
-and rest of two given integer arguments.  Of course, one can define a
-class to hold the two results of \code{divmod}, as in:
-\begin{lstlisting}
-case class TwoInts(first: int, second: int);
-def divmod(x: int, y: int): TwoInts = new TwoInts(x / y, x % y);
-\end{lstlisting}
-However, having to define a new class for every possible pair of
-result types is very tedious. In Scala one can use instead a
-the generic classes \lstinline@Tuple$n$@, for each $n$ between
-2 and 9.  As an example, here is the definition of Tuple2.
-\begin{lstlisting}
-package scala;
-case class Tuple2[a, b](_1: a, _2: b);
-\end{lstlisting}
-With \code{Tuple2}, the \code{divmod} method can be written as follows.
-\begin{lstlisting}
-def divmod(x: int, y: int) = new Tuple2[int, int](x / y, x % y);
-\end{lstlisting}
-As usual, type parameters to constructors can be omitted if they are
-deducible from value arguments. Also, Scala defines an alias
-\code{Pair} for \code{Tuple2} (as well as \code{Triple} for \code{Tuple3}).
-With these conventions, \code{divmod} can equivalently be written as
-follows.
-\begin{lstlisting}
-def divmod(x: int, y: int) = Pair(x / y, x % y);
-\end{lstlisting}
-How are elements of tuples accessed? Since tuples are case classes,
-there are two possibilities. One can either access a tuple's fields
-using the names of the constructor parameters \lstinline@_$i$@, as in the following example:
-\begin{lstlisting}
-val xy = divmod(x, y);
-System.out.println("quotient: " + x._1 + ", rest: " + x._2);
-\end{lstlisting}
-Or one uses pattern matching on tuples, as in the following example:
-\begin{lstlisting}
-divmod(x, y) match {
-  case Pair(n, d) => 
-    System.out.println("quotient: " + n + ", rest: " + d);
-}
-\end{lstlisting}
-Note that type parameters are never used in patterns; it would have
-been illegal to write case \code{Pair[int, int](n, d)}.
-
-\section{Functions}\label{sec:functions}
-
-Scala is a functional language in that functions are first-class
-values.  Scala is also an object-oriented language in that every value
-is an object.  It follows that functions are objects in Scala.  For
-instance, a function from type \code{String} to type \code{int} is
-represented as an instance of the trait \code{Function1[String, int]}.
-The \code{Function1} trait is defined as follows.
-\begin{lstlisting}
-package scala;
-trait Function1[-a, +b] {
-  def apply(x: a): b;
-}
-\end{lstlisting}
-Besides \code{Function1}, there are also definitions of
-\code{Function0} and \code{Function2} up to \code{Function9} in the
-standard Scala library. That is, there is one definition for each
-possible number of function parameters between 0 and 9.  Scala's
-function type syntax ~\lstinline@$T_1 \commadots T_n$ => $S$@~ is
-simply an abbreviation for the parameterized type
-~\lstinline@Function$n$[$T_1 \commadots T_n, S$]@~.
-
-Scala uses the same syntax $f(x)$ for function application, no matter
-whether $f$ is a method or a function object. This is made possible by
-the following convention: A function application $f(x)$ where $f$ is
-an object (as opposed to a method) is taken to be a shorthand for
-\lstinline@$f$.apply($x$)@. Hence, the \code{apply} method of a
-function type is inserted automatically where this is necessary.
-
-That's also why we defined array subscripting in
-Section~\ref{sec:first-arrays} by an \code{apply} method.  For any
-array \code{a}, the subscript operation \code{a(i)} is taken to be a
-shorthand for \code{a.apply(i)}.
-
-Functions are an example where a contra-variant type parameter
-declaration is useful. For example, consider the following code:
-\begin{lstlisting} 
-val f: (AnyRef => int)  =  x => x.hashCode();
-val g: (String => int)  =  f;
-g("abc")
-\end{lstlisting}
-It's sound to bind the value \code{g} of type \code{String => int} to
-\code{f}, which is of type \code{AnyRef => int}. Indeed, all one can
-do with function of type \code{String => int} is pass it a string in
-order to obtain an integer. Clearly, the same works for function
-\code{f}: If we pass it a string (or any other object), we obtain an
-integer.  This demonstrates that function subtyping is contra-variant
-in its argument type whereas it is covariant in its result type.
-In short, $S \Rightarrow T$ is a subtype of $S' \Rightarrow T'$, provided
-$S'$ is a subtype of $S$ and $T$ is a subtype of $T'$.
-
-\example Consider the Scala code
-\begin{lstlisting}
-val plus1: (int => int)  =  (x: int) => x + 1;
-plus1(2)
-\end{lstlisting}
-This is expanded into the following object code.
-\begin{lstlisting}
-val plus1: Function1[int, int] = new Function1[int, int] {
-  def apply(x: int): int = x + 1;
-}
-plus1.apply(2)
-\end{lstlisting}
-Here, the object creation \lstinline@new Function1[int, int]{ ... }@
-represents an instance of an {\em anonymous class}. It combines the
-creation of a new \code{Function1} object with an implementation of 
-the \code{apply} method (which is abstract in \code{Function1}).
-Equivalently, but more verbosely, one could have used a local class:
-\begin{lstlisting}
-val plus1: Function1[int, int] = {
-  class Local extends Function1[int, int] {
-    def apply(x: int): int = x + 1;
-  }
-  new Local: Function1[int, int]
-}
-plus1.apply(2)
-\end{lstlisting}
- 
-\chapter{Lists}
-
-Lists are an important data structure in many Scala programs.  
-A list containing the elements \code{x}$_1$, \ldots, \code{x}$_n$ is written
-\code{List(x}$_1$\code{, ..., x}$_n$\code{)}. Examples are:
-\begin{lstlisting}
-val fruit = List("apples", "oranges", "pears");
-val nums  = List(1, 2, 3, 4);
-val diag3 = List(List(1, 0, 0), List(0, 1, 0), List(0, 0, 1));
-val empty = List();
-\end{lstlisting}
-Lists are similar to arrays in languages such as C or Java, but there
-are also three important differences. First, lists are immutable. That
-is, elements of a list cannot be changed by assignment. Second, 
-lists have a recursive structure, whereas arrays are flat. Third,
-lists support a much richer set of operations than arrays usually do.
-
-\section{Using Lists}
-
-\paragraph{The List type}
-Like arrays, lists are {\em homogeneous}. That is, the elements of a
-list all have the same type.  The type of a list with elements of type
-\code{T} is written \code{List[T]} (compare to \code{T[]} in Java).
-\begin{lstlisting}
-val fruit: List[String]    = List("apples", "oranges", "pears");
-val nums : List[int]       = List(1, 2, 3, 4);
-val diag3: List[List[int]] = List(List(1, 0, 0), List(0, 1, 0), List(0, 0, 1));
-val empty: List[int]       = List();
-\end{lstlisting}
-
-\paragraph{List constructors}
-All lists are built from two more fundamental constructors, \code{Nil}
-and \code{::} (pronounced ``cons''). \code{Nil} represents an empty
-list. The infix operator \code{::} expresses list extension. That is,
-\code{x :: xs} represents a list whose first element is \code{x},
-which is followed by (the elements of) list \code{xs}.  Hence, the
-list values above could also have been defined as follows (in fact
-their previous definition is simply syntactic sugar for the definitions below).
-\begin{lstlisting}
-val fruit  = "apples" :: ("oranges" :: ("pears" :: Nil));
-val nums   = 1 :: (2 :: (3 :: (4 :: Nil)));
-val diag3  = (1 :: (0 :: (0 :: Nil))) ::
-             (0 :: (1 :: (0 :: Nil))) ::
-             (0 :: (0 :: (1 :: Nil))) :: Nil;
-val empty  = Nil;
-\end{lstlisting}
-The `\code{::}' operation associates to the right: \code{A :: B :: C} is
-interpreted as \code{A :: (B :: C)}.  Therefore, we can drop the
-parentheses in the definitions above. For instance, we can write
-shorter
-\begin{lstlisting}
-val nums  =  1 :: 2 :: 3 :: 4 :: Nil;
-\end{lstlisting}
-
-\paragraph{Basic operations on lists}
-All operations on lists can be expressed in terms of the following three:
-
-\begin{tabular}{ll}
-\code{head}  &  returns the first element of a list,\\
-\code{tail}  &  returns the list consisting of all elements except the\\
-& first element,\\
-\code{isEmpty} & returns \code{true} iff the list is empty
-\end{tabular}
-
-These operations are defined as methods of list objects. So we invoke
-them by selecting from the list that's operated on. Examples:
-\begin{lstlisting}
-empty.isEmpty   = true
-fruit.isEmpty   = false
-fruit.head      = "apples"
-fruit.tail.head = "oranges"
-diag3.head      = List(1, 0, 0)
-\end{lstlisting}
-The \code{head} and \code{tail} methods are defined only for non-empty
-lists.  When selected from an empty list, they throw an exception.
-
-As an example of how lists can be processed, consider sorting the
-elements of a list of numbers into ascending order. One simple way to
-do so is {\em insertion sort}, which works as follows: To sort a
-non-empty list with first element \code{x} and rest \code{xs}, sort
-the remainder \code{xs} and insert the element \code{x} at the right
-position in the result. Sorting an empty list will yield the
-empty list. Expressed as Scala code:
-\begin{lstlisting}
-def isort(xs: List[int]): List[int] =
-  if (xs.isEmpty) Nil
-  else insert(xs.head, isort(xs.tail));
-\end{lstlisting}
-
-\begin{exercise} Provide an implementation of the missing function
-\code{insert}.
-\end{exercise}
-
-\paragraph{List patterns} In fact, \code{::} is defined as a case
-class in Scala's standard library. Hence, it is possible to decompose
-lists by pattern matching, using patterns composed from the \code{Nil}
-and \code{::} constructors. For instance, \code{isort} can be written
-alternatively as follows.
-\begin{lstlisting}
-def isort(xs: List[int]): List[int] = xs match {
-  case List() => List()
-  case x :: xs1 => insert(x, isort(xs1))
-}
-\end{lstlisting}
-where
-\begin{lstlisting}
-def insert(x: int, xs: List[int]): List[int] = xs match {
-  case List() => List(x)
-  case y :: ys => if (x <= y) x :: xs else y :: insert(x, ys)
-}
-\end{lstlisting}
-
-\section{Definition of class List I: First Order Methods}
-\label{sec:list-first-order}
-
-Lists are not built in in Scala; they are defined by an abstract class
-\code{List}, which comes with two subclasses for \code{::} and \code{Nil}.
-In the following we present a tour through class \code{List}.
-\begin{lstlisting}
-package scala;
-abstract class List[+a] {
-\end{lstlisting}
-\code{List} is an abstract class, so one cannot define elements by
-calling the empty \code{List} constructor (e.g. by
-\code{new List}).  The class has a type parameter \code{a}. It is
-co-variant in this parameter, which means that
-\code{List[S] <: List[T]} for all types \code{S} and \code{T} such that
-\code{S <: T}.  The class is situated in the package
-\code{scala}. This is a package containing the most important standard
-classes of Scala.
- \code{List} defines a number of methods, which are
-explained in the following.
-
-\paragraph{Decomposing lists}
-First, there are the three basic methods \code{isEmpty},
-\code{head}, \code{tail}. Their implementation in terms of pattern
-matching is straightforward:
-\begin{lstlisting}
-def isEmpty: boolean = match {
-  case Nil => true
-  case x :: xs => false 
-}   
-def head: a = match { 
-  case Nil => throw new Error("Nil.head") 
-  case x :: xs => x 
-}
-def tail: List[a] = match { 
-  case Nil => throw new Error("Nil.tail") 
-  case x :: xs => x 
-}
-\end{lstlisting}
-
-The next function computes the length of a list.
-\begin{lstlisting}
-def length = match {
-  case Nil => 0
-  case x :: xs => 1 + xs.length
-}
-\end{lstlisting}
-\begin{exercise} Design a tail-recursive version of \code{length}.
-\end{exercise}
-
-The next two functions are the complements of \code{head} and
-\code{tail}.
-\begin{lstlisting}
-def last: a;
-def init: List[a];
-\end{lstlisting}
-\code{xs.last} returns the last element of list \code{xs}, whereas
-\code{xs.init} returns all elements of \code{xs} except the last.
-Both functions have to traverse the entire list, and are thus less
-efficient than their \code{head} and \code{tail} analogues.
-Here is the implementation of \code{last}.
-\begin{lstlisting}
-def last: a = match {
-  case Nil      => throw new Error("Nil.last")
-  case x :: Nil => x
-  case x :: xs  => xs.last
-}
-\end{lstlisting}
-The implementation of \code{init} is analogous.
-
-The next three functions return a prefix of the list, or a suffix, or
-both.
-\begin{lstlisting}
-def take(n: int): List[a] = 
-  if (n == 0 || isEmpty) Nil else head :: tail.take(n-1);
-
-def drop(n: int): List[a] = 
-  if (n == 0 || isEmpty) this else tail.drop(n-1);
-
-def split(n: int): Pair[List[a], List[a]] = Pair(take(n), drop(n));
-\end{lstlisting}
-\code{(xs take n)} returns the first \code{n} elements of list
-\code{xs}, or the whole list, if its length is smaller than \code{n}.
-\code{(xs drop n)} returns all elements of \code{xs} except the
-\code{n} first ones. Finally, \code{(xs split n)} returns a pair
-consisting of the lists resulting from \code{xs take n} and
-\code{xs drop n}.
-
-The next function returns an element at a given index in a list.
-It is thus analogous to array subscripting. Indices start at 0.
-\begin{lstlisting}   
-def apply(n: int): a = drop(n).head;
-\end{lstlisting}
-The \code{apply} method has a special meaning in Scala. An object with
-an \code{apply} method can be applied to arguments as if it was a
-function. For instance, to pick the 3'rd element of a list \code{xs},
-one can write either \code{xs.apply(3)} or \code{xs(3)} -- the latter
-expression expands into the first.
-
-With \code{take} and \code{drop}, we can extract sublists consisting
-of consecutive elements of the original list.  To extract the sublist
-$xs_m \commadots xs_{n-1}$ of a list \code{xs}, use:
-
-\begin{lstlisting}
-xs.drop(m).take(n - m)
-\end{lstlisting}
-
-\paragraph{Zipping lists} The next function combines two lists into a list of pairs.
-Given two lists
-\begin{lstlisting}
-xs = List(x$_1$, ..., x$_n$)   $\mbox{\rm, and}$
-ys = List(y$_1$, ..., y$_n$)   ,
-\end{lstlisting}
-\code{xs zip ys} constructs the list
-\code{List(Pair(x}$_1$\code{, y}$_1$\code{), ..., Pair(x}$_n$\code{, y}$_n$\code{))}.
-If the two lists have different lengths, the longer one of the two is
-truncated. Here is the definition of \code{zip} -- note that it is a
-polymorphic method.
-\begin{lstlisting}
-def zip[b](that: List[b]): List[Pair[a,b]] = 
-  if (this.isEmpty || that.isEmpty) Nil
-  else Pair(this.head, that.head) :: (this.tail zip that.tail);
-\end{lstlisting}
-
-\paragraph{Consing lists.}
-Like any infix operator, \code{::}
-is also implemented as a method of an object. In this case, the object
-is the list that is extended. This is possible, because operators
-ending with a `\code{:}' character are treated specially in Scala.  
-All such operators are treated as methods of their right operand. E.g.,
-\begin{lstlisting}
-    x :: y = y.::(x)       $\mbox{\rm whereas}$       x + y = x.+(y)                  
-\end{lstlisting}
-Note, however, that operands of a binary operation are in each case
-evaluated from left to right.  So, if \code{D} and \code{E} are
-expressions with possible side-effects, \code{D :: E} is translated to
-\lstinline@{val x = D; E.::(x)}@ in order to maintain the left-to-right
-order of operand evaluation.
-
-Another difference between operators ending in a `\code{:}' and other
-operators concerns their associativity.  Operators ending in
-`\code{:}' are right-associative, whereas other operators are
-left-associative.  E.g.,
-\begin{lstlisting}
-    x :: y :: z = x :: (y :: z)   $\mbox{\rm whereas}$    x + y + z = (x + y) + z
-\end{lstlisting}
-The definition of \code{::} as a method in
-class \code{List} is as follows:
-\begin{lstlisting}
-def ::[b >: a](x: b): List[b] = new scala.::(x, this);
-\end{lstlisting}
-Note that \code{::} is defined for all elements \code{x} of type
-\code{B} and lists of type \code{List[A]} such that the type \code{B}
-of \code{x} is a supertype of the list's element type \code{A}. The result
-is in this case a list of \code{B}'s. This
-is expressed by the type parameter \code{b} with lower bound \code{a}
-in the signature of \code{::}. 
-
-\paragraph{Concatenating lists}
-An operation similar to \code{::} is list concatenation, written
-`\code{:::}'. The result of \code{(xs ::: ys)} is a list consisting of
-all elements of \code{xs}, followed by all elements of \code{ys}.
-Because it ends in a colon, \code{:::} is right-associative and is
-considered as a method of its right-hand operand. Therefore,
-\begin{lstlisting}
-xs ::: ys ::: zs  =   xs ::: (ys ::: zs)
-                  =   zs.:::(ys).:::(xs)
-\end{lstlisting}
-Here is the implementation of the \code{:::} method:
-\begin{lstlisting}
-  def :::[b >: a](prefix: List[b]): List[b] = prefix match {
-    case Nil => this
-    case p :: ps => this.:::(ps).::(p)
-  }
-\end{lstlisting}
-
-\paragraph{Reversing lists} Another useful operation
-is list reversal. There is a method \code{reverse} in \code{List} to
-that effect. Let's try to give its implementation:
-\begin{lstlisting}
-def reverse[a](xs: List[a]): List[a] = xs match {
-  case Nil => Nil
-  case x :: xs => reverse(xs) ::: List(x)
-}
-\end{lstlisting}
-This implementation has the advantage of being simple, but it is not
-very efficient.  Indeed, one concatenation is executed for every
-element in the list. List concatenation takes time proportional to the
-length of its first operand. Therefore, the complexity of
-\code{reverse(xs)} is
-\[
-n + (n - 1) + ... + 1 = n(n+1)/2
-\]
-where $n$ is the length of \code{xs}. Can \code{reverse} be
-implemented more efficiently? We will see later that there exists
-another implementation which has only linear complexity.
-
-\section{Example: Merge sort}
-
-The insertion sort presented earlier in this chapter is simple to
-formulate, but also not very efficient. It's average complexity is
-proportional to the square of the length of the input list. We now
-design a program to sort the elements of a list which is more
-efficient than insertion sort. A good algorithm for this is {\em merge
-sort}, which works as follows.
-
-First, if the list has zero or one elements, it is already sorted, so
-one returns the list unchanged. Longer lists are split into two
-sub-lists, each containing about half the elements of the original
-list. Each sub-list is sorted by a recursive call to the sort
-function, and the resulting two sorted lists are then combined in a
-merge operation.
-
-For a general implementation of merge sort, we still have to specify
-the type of list elements to be sorted, as well as the function to be
-used for the comparison of elements. We obtain a function of maximal
-generality by passing these two items as parameters. This leads to the
-following implementation.
-\begin{lstlisting}
-def msort[a](less: (a, a) => boolean)(xs: List[a]): List[a] = {
-  def merge(xs1: List[a], xs2: List[a]): List[a] = 
-    if (xs1.isEmpty) xs2
-    else if (xs2.isEmpty) xs1
-    else if (less(xs1.head, xs2.head)) xs1.head :: merge(xs1.tail, xs2)
-    else xs2.head :: merge(xs1, xs2.tail);
-  val n = xs.length/2;
-  if (n == 0) xs
-  else merge(msort(less)(xs take n), msort(less)(xs drop n))
-}
-\end{lstlisting}
-The complexity of \code{msort} is $O(N;log(N))$, where $N$ is the
-length of the input list. To see why, note that splitting a list in
-two and merging two sorted lists each take time proportional to the
-length of the argument list(s). Each recursive call of \code{msort}
-halves the number of elements in its input, so there are $O(log(N))$
-consecutive recursive calls until the base case of lists of length 1
-is reached.  However, for longer lists each call spawns off two
-further calls. Adding everything up we obtain that at each of the
-$O(log(N))$ call levels, every element of the original lists takes
-part in one split operation and in one merge operation. Hence, every
-call level has a total cost proportional to $O(N)$. Since there are
-$O(log(N))$ call levels, we obtain an overall cost of
-$O(N;log(N))$. That cost does not depend on the initial distribution
-of elements in the list, so the worst case cost is the same as the
-average case cost. This makes merge sort an attractive algorithm for
-sorting lists.
-
-Here is an example how \code{msort} is used.
-\begin{lstlisting}
-msort(x: int, y: int => x < y)(List(5, 7, 1, 3))
-\end{lstlisting}
-The definition of \code{msort} is curried, to make it easy to specialize it with particular
-comparison functions. For instance,
-\begin{lstlisting}
-
-val intSort = msort(x: int, y: int => x < y)
-val reverseSort = msort(x: int, y: int => x > y)
-\end{lstlisting}
-
-\section{Definition of class List II: Higher-Order Methods}
-
-The examples encountered so far show that functions over lists often
-have similar structures. We can identify several patterns of
-computation over lists, like:
-\begin{itemize}
-      \item transforming every element of a list in some way.
-      \item extracting from a list all elements satisfying a criterion.
-      \item combine the elements of a list using some operator.
-\end{itemize}
-Functional programming languages enable programmers to write general
-functions which implement patterns like this by means of higher order
-functions. We now discuss a set of commonly used higher-order
-functions, which are implemented as methods in class \code{List}.
-
-\paragraph{Mapping over lists}
-A common operation is to transform each element of a list and then
-return the lists of results.  For instance, to scale each element of a
-list by a given factor.
-\begin{lstlisting}
-def scaleList(xs: List[double], factor: double): List[double] = xs match {
-  case Nil => xs
-  case x :: xs1 => x * factor :: scaleList(xs1, factor)
-}
-\end{lstlisting}
-This pattern can be generalized to the \code{map} method of class \code{List}:
-\begin{lstlisting}
-abstract class List[a] { ...
-  def map[b](f: a => b): List[b] = this match {
-    case Nil => this
-    case x :: xs => f(x) :: xs.map(f)
-  }
-\end{lstlisting}
-Using \code{map}, \code{scaleList} can be more concisely written as follows.
-\begin{lstlisting}
-def scaleList(xs: List[double], factor: double) = 
-  xs map (x => x * factor);
-\end{lstlisting}
-
-As another example, consider the problem of returning a given column
-of a matrix which is represented as a list of rows, where each row is
-again a list. This is done by the following function \code{column}.
-
-\begin{lstlisting}
-def column[a](xs: List[List[a[]], index: int): List[a] = 
-  xs map (row => row at index);
-\end{lstlisting}
-
-Closely related to \code{map} is the \code{foreach} method, which
-applies a given function to all elements of a list, but does not
-construct a list of results. The function is thus applied only for its
-side effect. \code{foreach} is defined as follows.
-\begin{lstlisting}
-  def foreach(f: a => unit): unit = this match {
-    case Nil => ()
-    case x :: xs => f(x) ; xs.foreach(f)
-  }
-\end{lstlisting}
-This function can be used for printing all elements of a list, for instance:
-\begin{lstlisting}
-  xs foreach (x => System.out.println(x))
-\end{lstlisting} 
-
-\begin{exercise} Consider a function which squares all elements of a list and
-returns a list with the results. Complete the following two equivalent
-definitions of \code{squareList}.
-
-\begin{lstlisting}
-def squareList(xs: List[int]): List[int] = xs match {
-  case List() => ??
-  case y :: ys => ??
-}
-def squareList(xs: List[int]): List[int] = 
-  xs map ??
-\end{lstlisting}
-\end{exercise}
-
-\paragraph{Filtering Lists}
-Another common operation selects from a list all elements fulfilling a
-given criterion. For instance, to return a list of all positive
-elements in some given lists of integers:
-\begin{lstlisting}
-def posElems(xs: List[int]): List[int] = xs match {
-  case Nil => xs
-  case x :: xs1 => if (x > 0) x :: posElems(xs1) else posElems(xs1)
-}
-\end{lstlisting}
-This pattern is generalized to the \code{filter} method of class \code{List}:
-\begin{lstlisting}
-  def filter(p: a => boolean): List[a] = this match {
-    case Nil => this
-    case x :: xs => if (p(x)) x :: xs.filter(p) else xs.filter(p)
-  }
-\end{lstlisting}
-Using \code{filter}, \code{posElems} can be more concisely written as
-follows.
-\begin{lstlisting}
-def posElems(xs: List[int]): List[int] = 
-  xs filter (x => x > 0);
-\end{lstlisting}
-
-An operation related to filtering is testing whether all elements of a
-list satisfy a certain condition. Dually, one might also be interested
-in the question whether there exists an element in a list that
-satisfies a certain condition. These operations are embodied in the
-higher-order functions \code{forall} and \code{exists} of class
-\code{List}.
-\begin{lstlisting}
-def forall(p: a => Boolean): Boolean =
-  isEmpty || (p(head) && (tail forall p));
-def exists(p: a => Boolean): Boolean =
-  !isEmpty && (p(head) || (tail exists p));
-\end{lstlisting}
-To illustrate the use of \code{forall}, consider the question whether
-a number if prime. Remember that a number $n$ is prime of it can be
-divided without remainder only by one and itself. The most direct
-translation of this definition would test that $n$ divided by all
-numbers from 2 up to and excluding itself gives a non-zero
-remainder. This list of numbers can be generated using a function
-\code{List.range} which is defined in object \code{List} as follows.
-\begin{lstlisting}
-package scala;
-object List { ... 
-  def range(from: int, end: int): List[int] = 
-    if (from >= end) Nil else from :: range(from + 1, end);
-\end{lstlisting}
-For example, \code{List.range(2, n)}
-generates the list of all integers from 2 up to and excluding $n$.
-The function \code{isPrime} can now simply be defined as follows.
-\begin{lstlisting}
-def isPrime(n: int) = 
-  List.range(2, n) forall (x => n % x != 0);
-\end{lstlisting}
-We see that the mathematical definition of prime-ness has been
-translated directly into Scala code. 
-
-Exercise: Define \code{forall} and \code{exists} in terms of \code{filter}.
-
-
-\paragraph{Folding and Reducing Lists}
-Another common operation is to combine the elements of a list with
-some operator.  For instance:
-\begin{lstlisting}
-sum(List(x$_1$, ..., x$_n$))       =  0 + x$_1$ + ... + x$_n$
-product(List(x$_1$, ..., x$_n$))   =  1 * x$_1$ * ... * x$_n$
-\end{lstlisting}
-Of course, we can implement both functions with a
-recursive scheme:
-\begin{lstlisting}
-def sum(xs: List[int]): int = xs match {
-  case Nil => 0
-  case y :: ys => y + sum(ys)
-}
-def product(xs: List[int]): int = xs match {
-  case Nil => 1
-  case y :: ys => y * product(ys)
-}
-\end{lstlisting}
-But we can also use the generalization of this program scheme embodied
-in the \code{reduceLeft} method of class \code{List}.  This method
-inserts a given binary operator between adjacent elements of a given list.
-E.g.\ 
-\begin{lstlisting}
-List(x$_1$, ..., x$_n$).reduceLeft(op) = (...(x$_1$ op x$_2$) op ... ) op x$_n$
-\end{lstlisting}
-Using \code{reduceLeft}, we can make the common pattern
-in \code{sum} and \code{product} apparent:
-\begin{lstlisting}
-def sum(xs: List[int])      =  (0 :: xs) reduceLeft {(x, y) => x + y};
-def product(xs: List[int])  =  (1 :: xs) reduceLeft {(x, y) => x * y};
-\end{lstlisting}
-Here is the implementation of \code{reduceLeft}.
-\begin{lstlisting}
-  def reduceLeft(op: (a, a) => a): a = this match {
-    case Nil     => throw new Error("Nil.reduceLeft")
-    case x :: xs => (xs foldLeft x)(op)
-  }
-  def foldLeft[b](z: b)(op: (b, a) => b): b = this match {
-    case Nil => z
-    case x :: xs => (xs foldLeft op(z, x))(op)
-  }
-}
-\end{lstlisting}
-We see that the \code{reduceLeft} method is defined in terms of
-another generally useful method, \code{foldLeft}.  The latter takes as
-additional parameter an {\em accumulator} \code{z}, which is returned
-when \code{foldLeft} is applied on an empty list. That is,
-\begin{lstlisting}
-(List(x$_1$, ..., x$_n$) foldLeft z)(op)   =  (...(z op x$_1$) op ... ) op x$_n$
-\end{lstlisting}
-The \code{sum} and \code{product} methods can be defined alternatively
-using \code{foldLeft}:
-\begin{lstlisting}
-def sum(xs: List[int])      =  (xs foldLeft 0) {(x, y) => x + y};
-def product(xs: List[int])  =  (xs foldLeft 1) {(x, y) => x * y};
-\end{lstlisting}
-
-\paragraph{FoldRight and ReduceRight}
-Applications of \code{foldLeft} and \code{reduceLeft} expand to
-left-leaning trees. \todo{insert pictures}.  They have duals
-\code{foldRight} and \code{reduceRight}, which produce right-leaning
-trees.
-\begin{lstlisting}
-List(x$_1$, ..., x$_n$).reduceRight(op)     =  x$_1$ op ( ... (x$_{n-1}$ op x$_n$)...)
-(List(x$_1$, ..., x$_n$) foldRight acc)(op) =  x$_1$ op ( ... (x$_n$ op acc)...)
-\end{lstlisting}
-These are defined as follows.
-\begin{lstlisting}
-  def reduceRight(op: (a, a) => a): a = match 
-    case Nil => throw new Error("Nil.reduceRight")
-    case x :: Nil => x
-    case x :: xs => op(x, xs.reduceRight(op))
-  }
-  def foldRight[b](z: b)(op: (a, b) => b): b = match {
-    case Nil => z
-    case x :: xs => op(x, (xs foldRight z)(op))
-  }
-\end{lstlisting}
-
-Class \code{List} defines also two symbolic abbreviations for
-\code{foldLeft} and \code{foldRight}:
-\begin{lstlisting}
-  def /:[b](z: b)(f: (b, a) => b): b = foldLeft(z)(f);
-  def :\[b](z: b)(f: (a, b) => b): b = foldRight(z)(f);
-\end{lstlisting}
-The method names picture the left/right leaning trees of the fold
-operations by forward or backward slashes. The \code{:} points in each
-case to the list argument whereas the end of the slash points to the
-accumulator (or: zero) argument \code{z}. 
-That is, 
-\begin{lstlisting}
-(z /: List(x$_1$, ..., x$_n$))(op) = (...(z op x$_1$) op ... ) op x$_n$ 
-(List(x$_1$, ..., x$_n$) :\ z)(op) = x$_1$ op ( ... (x$_n$ op acc)...)
-\end{lstlisting}
-For associative and commutative operators, \code{/:} and
-\code{:\\} are equivalent (even though there may be a difference
-in efficiency).  
-%But sometimes, only one of the two operators is
-%appropriate or has the right type:
-
-\begin{exercise} Consider the problem of writing a function \code{flatten},
-which takes a list of element lists as arguments. The result of
-\code{flatten} should be the concatenation of all element lists into a
-single list. Here is the an implementation of this method in terms of 
-\code{:\\}.
-\begin{lstlisting}
-def flatten[a](xs: List[List[a]]): List[a] = 
-  (xs :\ (Nil: List[a])) {(x, xs) => x ::: xs};
-\end{lstlisting} 
-Consider replacing the first part of the body of \lstinline@flatten@
-by \lstinline@(Nil /: xs)@. What would be the difference in asymptotoc
-complexity between the two versions of \lstinline@flatten@?
-
-In fact \code{flatten} is predefined together with a set of other
-userful function in an object called \code{List} in the standatd Scala
-library. It can be accessed from user program by calling
-\code{List.flatten}. Note that \code{flatten} is not a method of class
-\code{List} -- it would not make sense there, since it applies only
-to lists of lists, not to all lists in general.
-\end{exercise}
-
-\paragraph{List Reversal Again} We have seen in 
-Section~\ref{sec:list-first-order} an implementation of method
-\code{reverse} whose run-time was quadratic in the length of the list
-to be reversed. We now develop a new implementation of \code{reverse},
-which has linear cost.  The idea is to use a \code{foldLeft}
-operation based on the following program scheme.
-\begin{lstlisting}
-class List[+a] { ...
-  def reverse: List[a] = (z? /: this)(op?);
-\end{lstlisting}
-It only remains to fill in the \code{z?} and \code{op?} parts.  Let's
-try to deduce them from examples.
-\begin{lstlisting}
-  Nil
-= Nil.reverse                 // by specification
-= (z /: Nil)(op)              // by the template for reverse
-= (Nil foldLeft z)(op)        // by the definition of /:
-= z                           // by definition of foldLeft
-\end{lstlisting}
-Hence, \code{z?} must be \code{Nil}. To deduce the second operand,
-let's study reversal of a list of length one.
-\begin{lstlisting}
-  List(x)
-= List(x).reverse             // by specification
-= (Nil /: List(x))(op)        // by the template for reverse, with z = Nil
-= (List(x) foldLeft Nil)(op)  // by the definition of /:
-= op(Nil, x)                  // by definition of foldLeft
-\end{lstlisting}
-Hence, \code{op(Nil, x)} equals \code{List(x)}, which is the same
-as \code{x :: Nil}. This suggests to take as \code{op} the
-\code{::} operator with its operands exchanged.  Hence, we arrive at
-the following implementation for \code{reverse}, which has linear complexity.
-\begin{lstlisting}
-def reverse: List[a] =
-  ((Nil: List[a]) /: this) {(xs, x) => x :: xs};
-\end{lstlisting}
-(Remark: The type annotation of \code{Nil} is necessary 
-to make the type inferencer work.)
-
-\begin{exercise} Fill in the missing expressions to complete the following
-definitions of some basic list-manipulation operations as fold
-operations.
-\begin{lstlisting}
-def mapFun[a, b](xs: List[a], f: a => b): List[b] = 
-  (xs :\ List[b]()){ ?? };
-
-def lengthFun[a](xs: List[a]): int =
-  (0 /: xs){ ?? };
-\end{lstlisting}
-\end{exercise}
-
-\paragraph{Nested Mappings}
-
-We can employ higher-order list processing functions to express many
-computations that are normally expressed as nested loops in imperative
-languages. 
-
-As an example, consider the following problem: Given a positive
-integer $n$, find all pairs of positive integers $i$ and $j$, where 
-$1 \leq j < i < n$ such that $i + j$ is prime. For instance, if $n = 7$,
-the pairs are
-\bda{c|lllllll}
-i     & 2 & 3 & 4 & 4 & 5 & 6 & 6\\
-j     & 1 & 2 & 1 & 3 & 2 & 1 & 5\\ \hline
-i + j & 3 & 5 & 5 & 7 & 7 & 7 & 11
-\eda
-
-A natural way to solve this problem consists of two steps. In a first step,
-one generates the sequence of all pairs $(i, j)$ of integers such that
-$1 \leq j < i < n$. In a second step one then filters from this sequence
-all pairs $(i, j)$ such that $i + j$ is prime.
-
-Looking at the first step in more detail, a natural way to generate
-the sequence of pairs consists of three sub-steps.  First, generate
-all integers between $1$ and $n$ for $i$.  
-\item
-Second, for each integer $i$ between $1$ and $n$, generate the list of
-pairs $(i, 1)$ up to $(i, i-1)$. This can be achieved by a
-combination of \code{range} and \code{map}:
-\begin{lstlisting}
-  List.range(1, i) map (x => Pair(i, x))
-\end{lstlisting}
-Finally, combine all sublists using \code{foldRight} with \code{:::}.
-Putting everything together gives the following expression:
-\begin{lstlisting}
-List.range(1, n)
-  .map(i => List.range(1, i).map(x => Pair(i, x)))
-  .foldRight(List[Pair[int, int]]()) {(xs, ys) => xs ::: ys}
-  .filter(pair => isPrime(pair._1 + pair._2))
-\end{lstlisting}
-
-\paragraph{Flattening Maps}
-The combination of mapping and then concatenating sublists 
-resulting from the map
-is so common that we there is a special method 
-for it in class \code{List}:
-\begin{lstlisting}
-abstract class List[+a] { ...
-  def flatMap[b](f: a => List[b]): List[b] = match {
-    case Nil => Nil
-    case x :: xs => f(x) ::: (xs flatMap f)
-  }
-}
-\end{lstlisting}
-With \code{flatMap}, the pairs-whose-sum-is-prime expression 
-could have been written more concisely as follows.
-\begin{lstlisting}
-List.range(1, n)
-  .flatMap(i => List.range(1, i).map(x => Pair(i, x)))
-  .filter(pair => isPrime(pair._1 + pair._2))
-\end{lstlisting}
-
-
-
-\section{Summary}
-
-This chapter has ingtroduced lists as a fundamental data structure in
-programming. Since lists are immutable, they are a common data type in
-functional programming languages. They play there a role comparable to
-arrays in imperative languages. However, the access patterns between
-arrays and lists are quite different. Where array accessing is always
-done by indexing, this is much less common for lists.  We have seen
-that \code{scala.List} defines a method called \code{apply} for indexing;
-however this operation is much more costly than in the case of arrays
-(linear as opposed to constant time). Instead of indexing, lists are
-usually traversed recursively, where recursion steps are usually based
-on a pattern match over the traversed list. There is also a rich set of
-higher-order combinators which allow one to instantiate a set of
-predefined patterns of computations over lists.
-
-\comment{
-\bsh{Reasoning About Lists}
-
-Recall the concatenation operation for lists:
-
-\begin{lstlisting}
-class List[+a] {
-  ...
-  def ::: (that: List[a]): List[a] = 
-    if (isEmpty) that
-    else head :: (tail ::: that)
-}
-\end{lstlisting}
-
-We would like to verify that concatenation is associative, with the
-empty list \code{List()} as left and right identity:
-\bda{lcl}
-   (xs ::: ys) ::: zs &=& xs ::: (ys ::: zs) \\
-   xs ::: List()          &=& xs \gap =\ List() ::: xs
-\eda
-\emph{Q}: How can we prove statements like the one above?
-
-\emph{A}: By \emph{structural induction} over lists.
-\es
-\bsh{Reminder: Natural Induction}
-
-Recall the proof principle of \emph{natural induction}:
-
-To show a property \mathtext{P(n)} for all numbers \mathtext{n \geq b}:
-\be
-\item Show that \mathtext{P(b)} holds (\emph{base case}).
-\item For arbitrary \mathtext{n \geq b} show:
-\begin{quote}
-     if \mathtext{P(n)} holds, then \mathtext{P(n+1)} holds as well
-\end{quote}
-(\emph{induction step}).
-\ee
-%\es\bs
-\emph{Example}: Given
-\begin{lstlisting}
-def factorial(n: int): int = 
-  if (n == 0) 1
-  else n * factorial(n-1)
-\end{lstlisting}
-show that, for all \code{n >= 4},
-\begin{lstlisting}
-   factorial(n) >= 2$^n$
-\end{lstlisting}
-\es\bs
-\Case{\code{4}}
-is established by simple calculation of \code{factorial(4) = 24} and \code{2$^4$ = 16}.
-
-\Case{\code{n+1}} 
-We have for \code{n >= 4}:
-\begin{lstlisting}
-    \= factorial(n + 1)
- =     \> $\expl{by the second clause of factorial(*)}$
-       \> (n + 1) * factorial(n)
- >=    \> $\expl{by calculation}$
-       \> 2 * factorial(n)
- >=    \> $\expl{by the induction hypothesis}$
-       \> 2 * 2$^n$.
-\end{lstlisting}
-Note that in our proof we can freely apply reduction steps such as in (*)
-anywhere in a term.
-
-
-This works because purely functional programs do not have side
-effects; so a term is equivalent to the term it reduces to.
-
-The principle is called {\em\emph{referential transparency}}.
-\es
-\bsh{Structural Induction}
-
-The principle of structural induction is analogous to natural induction:
-
-In the case of lists, it is as follows:
-
-To prove a property \mathtext{P(xs)} for all lists \mathtext{xs},
-\be
-\item Show that \code{P(List())} holds (\emph{base case}).
-\item For arbitrary lists \mathtext{xs} and elements \mathtext{x} 
-      show:
-\begin{quote}
-     if \mathtext{P(xs)} holds, then \mathtext{P(x :: xs)} holds as well
-\end{quote}
-(\emph{induction step}).
-\ee
-
-\es
-\bsh{Example}
-
-We show \code{(xs ::: ys) ::: zs  =  xs ::: (ys ::: zs)} by structural induction
-on \code{xs}.
-
-\Case{\code{List()}}
-For the left-hand side, we have:
-\begin{lstlisting}
-    \= (List() ::: ys) ::: zs
- =     \> $\expl{by first clause of \prog{:::}}$
-       \> ys ::: zs
-\end{lstlisting}
-For the right-hand side, we have:
-\begin{lstlisting}
-    \= List() ::: (ys ::: zs)
- =     \> $\expl{by first clause of \prog{:::}}$
-       \> ys ::: zs
-\end{lstlisting}
-So the case is established.
-
-\es
-\bs
-\Case{\code{x :: xs}} 
-
-For the left-hand side, we have:
-\begin{lstlisting}
-    \= ((x :: xs) ::: ys) ::: zs
- =     \> $\expl{by second clause of \prog{:::}}$
-       \> (x :: (xs ::: ys)) ::: zs
- =     \> $\expl{by second clause of \prog{:::}}$
-       \> x :: ((xs ::: ys) ::: zs)
- =     \> $\expl{by the induction hypothesis}$
-       \> x :: (xs ::: (ys ::: zs))
-\end{lstlisting}
-
-For the right-hand side, we have:
-\begin{lstlisting}
-    \= (x :: xs) ::: (ys ::: zs)
- =     \> $\expl{by second clause of \prog{:::}}$
-       \> x :: (xs ::: (ys ::: zs))
-\end{lstlisting}
-So the case (and with it the property) is established.
-
-\begin{exercise}
-Show by induction on \code{xs} that \code{xs ::: List()  =  xs}.
-\es
-\bsh{Example (2)}
-\end{exercise}
-
-As a more difficult example, consider function
-\begin{lstlisting}
-abstract class List[a] { ...
-  def reverse: List[a] = match {
-    case List() => List()
-    case x :: xs => xs.reverse ::: List(x)
-  }
-}
-\end{lstlisting}
-We would like to prove the proposition that
-\begin{lstlisting}
-   xs.reverse.reverse  =  xs  .
-\end{lstlisting}
-We proceed by induction over \code{xs}. The base case is easy to establish:
-\begin{lstlisting}
-    \= List().reverse.reverse
- =     \> $\expl{by first clause of \prog{reverse}}$
-       \> List().reverse
- =     \> $\expl{by first clause of \prog{reverse}}$
-       \> List()
-\end{lstlisting}
-\es\bs
-For the induction step, we try:
-\begin{lstlisting}
-    \= (x :: xs).reverse.reverse
- =     \> $\expl{by second clause of \prog{reverse}}$
-       \> (xs.reverse ::: List(x)).reverse
-\end{lstlisting}
-There's nothing more we can do to this expression, so we turn to the right side:
-\begin{lstlisting}
-    \= x :: xs
- =     \> $\expl{by induction hypothesis}$
-       \> x :: xs.reverse.reverse
-\end{lstlisting}
-The two sides have simplified to different expressions.
-
-So we still have to show that
-\begin{lstlisting}
-  (xs.reverse ::: List(x)).reverse  =  x :: xs.reverse.reverse
-\end{lstlisting}
-Trying to prove this directly by induction does not work.
-
-Instead we have to {\em generalize} the equation to:
-\begin{lstlisting}
-  (ys ::: List(x)).reverse  =  x :: ys.reverse
-\end{lstlisting}
-\es\bs
-This equation can be proved by a second induction argument over \code{ys}.
-(See blackboard).
-
-\begin{exercise}
-Is it the case that \code{(xs drop m) at n  =  xs at (m + n)} for all 
-natural numbers \code{m}, \code{n} and all lists \code{xs}?
-\end{exercise}
-
-\es
-\bsh{Structural Induction on Trees}
-
-Structural induction is not restricted to lists; it works for arbitrary
-trees.
-
-The general induction principle is as follows.
-
-To show that property \code{P(t)} holds for all trees of a certain type,
-\begin{itemize}
-\item Show \code{P(l)} for all leaf trees \code{$l$}.
-\item For every interior node \code{t} with subtrees \code{s$_1$, ..., s$_n$}, 
-      show that \code{P(s$_1$) $\wedge$ ... $\wedge$ P(s$_n$) => P(t)}.
-\end{itemize} 
-
-\example Recall our definition of \code{IntSet} with 
-operations \code{contains} and \code{incl}:
-
-\begin{lstlisting}
-abstract class IntSet {
-  abstract def incl(x: int): IntSet
-  abstract def contains(x: int): boolean
-}
-\end{lstlisting}
-\es\bs
-\begin{lstlisting}
-case class Empty extends IntSet {
-  def contains(x: int): boolean = false
-  def incl(x: int): IntSet = NonEmpty(x, Empty, Empty)
-}
-case class NonEmpty(elem: int, left: Set, right: Set) extends IntSet {
-  def contains(x: int): boolean = 
-    if (x < elem) left contains x
-    else if (x > elem) right contains x
-    else true
-  def incl(x: int): IntSet = 
-    if (x < elem) NonEmpty(elem, left incl x, right)
-    else if (x > elem) NonEmpty(elem, left, right incl x)
-    else this
-}
-\end{lstlisting}
-(With \code{case} added, so that we can use factory methods instead of \code{new}).
-
-What does it mean to prove the correctness of this implementation?
-\es
-\bsh{Laws of IntSet}
-
-One way to state and prove the correctness of an implementation is
-to prove laws that hold for it.
-
-In the case of \code{IntSet}, three such laws would be:
-
-For all sets \code{s}, elements \code{x}, \code{y}:
-
-\begin{lstlisting}
-Empty contains x          \= =  false
-(s incl x) contains x     \> =  true
-(s incl x) contains y     \> =  s contains y         if x $\neq$ y
-\end{lstlisting}
-
-(In fact, one can show that these laws characterize the desired data
-type completely).
-
-How can we establish that these laws hold?
-
-\emph{Proposition 1}: \code{Empty contains x =  false}.
-
-\emph{Proof}: By the definition of \code{contains} in \code{Empty}.
-\es\bs
-\emph{Proposition 2}: \code{(xs incl x) contains x = true}
-
-\emph{Proof:}
-
-\Case{\code{Empty}}
-\begin{lstlisting}
-    \= (Empty incl x) contains x
- =     \> $\expl{by definition of \prog{incl} in \prog{Empty}}$
-       \> NonEmpty(x, Empty, Empty) contains x
- =     \> $\expl{by definition of \prog{contains} in \prog{NonEmpty}}$
-       \> true
-\end{lstlisting}
-
-\Case{\code{NonEmpty(x, l, r)}}
-\begin{lstlisting}
-    \= (NonEmpty(x, l, r) incl x) contains x
- =     \> $\expl{by definition of \prog{incl} in \prog{NonEmpty}}$
-       \> NonEmpty(x, l, r) contains x
- =     \> $\expl{by definition of \prog{contains} in \prog{Empty}}$
-       \> true
-\end{lstlisting}
-\es\bs
-\Case{\code{NonEmpty(y, l, r)} where \code{y < x}}
-\begin{lstlisting}
-    \= (NonEmpty(y, l, r) incl x) contains x
- =     \> $\expl{by definition of \prog{incl} in \prog{NonEmpty}}$
-       \> NonEmpty(y, l, r incl x) contains x
- =     \> $\expl{by definition of \prog{contains} in \prog{NonEmpty}}$
-       \> (r incl x) contains x
- =     \> $\expl{by the induction hypothesis}$
-       \> true
-\end{lstlisting}
-
-\Case{\code{NonEmpty(y, l, r)} where \code{y > x}} is analogous.
-
-\bigskip
-
-\emph{Proposition 3}: If \code{x $\neq$ y} then
-\code{xs incl y contains x  =  xs contains x}.
-
-\emph{Proof:} See blackboard.
-\es
-\bsh{Exercise}
-
-Say we add a \code{union} function to \code{IntSet}:
-
-\begin{lstlisting}
-class IntSet { ...
-  def union(other: IntSet): IntSet
-}
-class Expty extends IntSet { ...
-  def union(other: IntSet) = other
-}
-class NonEmpty(x: int, l: IntSet, r: IntSet) extends IntSet { ...
-  def union(other: IntSet): IntSet = l union r union other incl x
-}
-\end{lstlisting}
-
-The correctness of \code{union} can be subsumed with the following
-law:
-
-\emph{Proposition 4}: 
-\code{(xs union ys) contains x  =  xs contains x || ys contains x}.
-Is that true ? What hypothesis is missing ? Show a counterexample.
-
-Show Proposition 4 using structural induction on \code{xs}.
-\es
-\comment{
-
-\emph{Proof:} By induction on \code{xs}.
-
-\Case{\code{Empty}}
-
-\Case{\code{NonEmpty(x, l, r)}}
-
-\Case{\code{NonEmpty(y, l, r)} where \code{y < x}}
-
-\begin{lstlisting}
-    \= (Empty union ys) contains x 
- =      \> $\expl{by definition of \prog{union} in \prog{Empty}}$
-        \> ys contains x
- =      \> $\expl{Boolean algebra}$
-        \> false || ys contains x
- =      \> $\expl{by definition of \prog{contains} in \prog{Empty} (reverse)}$
-        \> (Empty contains x) || (ys contains x)
-\end{lstlisting}
-
-\begin{lstlisting}
-    \= (NonEmpty(x, l, r) union ys) contains x
- =      \> $\expl{by definition of \prog{union} in \prog{NonEmpty}}$
-        \> (l union r union ys incl x) contains x
- =      \> $\expl{by Proposition 2}$
-        \> true
- =      \> $\expl{Boolean algebra}$
-        \> true || (ys contains x)
- =      \> $\expl{by definition of \prog{contains} in \prog{NonEmpty} (reverse)}$
-        \> (NonEmpty(x, l, r) contains x) || (ys contains x)
-\end{lstlisting}
-
-\begin{lstlisting}
-    \= (NonEmpty(y, l, r) union ys) contains x
- =      \> $\expl{by definition of \prog{union} in \prog{NonEmpty}}$
-        \> (l union r union ys incl y) contains x
- =      \> $\expl{by Proposition 3}$
-        \> (l union r union ys) contains x
- =      \> $\expl{by the induction hypothesis}$
-        \> ((l union r) contains x) || (ys contains x)
- =      \> $\expl{by Proposition 3}$
-        \> ((l union r incl y) contains x) || (ys contains x)
-\end{lstlisting}
-
-\Case{\code{NonEmpty(y, l, r)} where \code{y < x}}
- ... is analogous.
-
-\es
-}}
-\chapter{\label{sec:for-notation}For-Comprehensions}
-
-The last chapter demonstrated that higher-order functions such as
-\verb@map@, \verb@flatMap@, \verb@filter@ provide powerful
-constructions for dealing with lists.  But sometimes the level of
-abstraction required by these functions makes a program hard to
-understand.
-
-To help understandability, Scala has a special notation which
-simplifies common patterns of applications of higher-order functions.
-This notation builds a bridge between set-comprehensions in
-mathematics and for-loops in imperative languages such as C or
-Java. It also closely resembles the query notation of relational
-databases.
-
-As a first example, say we are given a list \code{persons} of persons
-with \code{name} and \code{age} fields.  To print the names of all
-persons in the sequence which are aged over 20, one can write:
-\begin{lstlisting}
-for (val p <- persons; p.age > 20) yield p.name
-\end{lstlisting}
-This is equivalent to the following expression , which uses
-higher-order functions \code{filter} and \code{map}:
-\begin{lstlisting}
-persons filter (p => p.age > 20) map (p => p.name)
-\end{lstlisting}
-The for-comprehension looks a bit like a for-loop in imperative languages,
-except that it constructs a list of the results of all iterations.
-
-Generally, a for-comprehension is of the form
-\begin{lstlisting}
-for ( $s$ ) yield $e$
-\end{lstlisting}
-Here, $s$ is a sequence of {\em generators} and {\em filters}.  A {\em
-generator} is of the form \code{val x <- e}, where \code{e} is a
-list-valued expression. It binds \code{x} to successive values in the
-list.  A {\em filter} is an expression \code{f} of type
-\code{boolean}.  It omits from consideration all bindings for which
-\code{f} is \code{false}.  The sequence $s$ starts in each case with a
-generator.  If there are several generators in a sequence, later
-generators vary more rapidly than earlier ones.
-
-Here are two examples that show how for-comprehensions are used.
-First, let's redo an example of the previous chapter: Given a positive
-integer $n$, find all pairs of positive integers $i$ and $j$, where $1
-\leq j < i < n$ such that $i + j$ is prime. With a for-comprehension
-this problem is solved as follows:
-\begin{lstlisting}
-for (val i <- List.range(1, n);
-     val j <- List.range(1, i);
-     isPrime(i+j)) yield Pair(i, j)
-\end{lstlisting}
-This is arguably much clearer than the solution using \code{map},
-\code{flatMap} and \code{filter} that we have developed previously.
-
-As a second example, consider computing the scalar product of two
-vectors \code{xs} and \code{ys}. Using a for-comprehension, this can
-be written as follows.
-\begin{lstlisting}
-  sum (for(val (x, y) <- xs zip ys) yield x * y)
-\end{lstlisting}
-
-\section{The N-Queens Problem}
-
-For-comprehensions are especially useful for solving combinatorial
-puzzles. An example of such a puzzle is the 8-queens problem: Given a
-standard chess-board, place 8 queens such that no queen is in check from any
-other (a queen can check another piece if they are on the same
-column, row, or diagonal). We will now develop a solution to this
-problem, generalizing it to chess-boards of arbitrary size. Hence, the
-problem is to place $n$ queens on a chess-board of size $n \times n$.
-
-To solve this problem, note that we need to place a queen in each row.
-So we could place queens in successive rows, each time checking that a
-newly placed queen is not in check from any other queens that have
-already been placed. In the course of this search, it might arrive
-that a queen to be placed in row $k$ would be in check in all fields
-of that row from queens in row $1$ to $k-1$. In that case, we need to
-abort that part of the search in order to continue with a different
-configuration of queens in columns $1$ to $k-1$.
-
-This suggests a recursive algorithm.  Assume that we have already
-generated all solutions of placing $k-1$ queens on a board of size $n
-\times n$. We can represent each such solution by a list of length
-$k-1$ of column numbers (which can range from $1$ to $n$).  We treat
-these partial solution lists as stacks, where the column number of the
-queen in row $k-1$ comes first in the list, followed by the column
-number of the queen in row $k-2$, etc. The bottom of the stack is the
-column number of the queen placed in the first row of the board.  All
-solutions together are then represented as a list of lists, with one
-element for each solution.
-
-Now, to place the $k$'the queen, we generate all possible extensions
-of each previous solution by one more queen. This yields another list
-of solution lists, this time of length $k$. We continue the process
-until we have reached solutions of the size of the chess-board $n$.
-This algorithmic idea is embodied in function \code{placeQueens} below:
-\begin{lstlisting}
-def queens(n: int): List[List[int]] = {
-  def placeQueens(k: int): List[List[int]] =
-    if (k == 0) List(List())
-    else for (val queens <- placeQueens(k - 1);
-              val column <- List.range(1, n + 1);
-              isSafe(column, queens, 1)) yield col :: queens;
-  placeQueens(n);
-}
-\end{lstlisting}
-
-\begin{exercise} Write the function
-\begin{lstlisting}
-  def isSafe(col: int, queens: List[int], delta: int): boolean
-\end{lstlisting}
-which tests whether a queen in the given column \verb@col@ is safe with 
-respect to the \verb@queens@ already placed. Here, \verb@delta@ is the difference between the row of the queen to be
-placed and the row of the first queen in the list.
-\end{exercise}
-
-\section{Querying with For-Comprehensions}
-
-The for-notation is essentially equivalent to common operations of
-database query languages.  For instance, say we are given a 
-database \code{books}, represented as a list of books, where
-\code{Book} is defined as follows.
-\begin{lstlisting}
-case class Book(title: String, authors: List[String]);
-\end{lstlisting}
-Here is a small example database:
-\begin{lstlisting}
-val books: List[Book] = List(
-  Book("Structure and Interpretation of Computer Programs",
-       List("Abelson, Harold", "Sussman, Gerald J.")),
-  Book("Principles of Compiler Design",
-       List("Aho, Alfred", "Ullman, Jeffrey")),
-  Book("Programming in Modula-2",
-       List("Wirth, Niklaus")),
-  Book("Introduction to Functional Programming"),
-       List("Bird, Richard")),
-  Book("The Java Language Specification",
-       List("Gosling, James", "Joy, Bill", "Steele, Guy", "Bracha, Gilad")));
-\end{lstlisting}
-Then, to find the titles of all books whose author's last name is ``Ullman'':
-\begin{lstlisting}
-for (val b <- books; val a <- b.authors; a startsWith "Ullman")
-yield b.title
-\end{lstlisting}
-(Here, \code{startsWith} is a method in \code{java.lang.String}).  Or,
-to find the titles of all books that have the string ``Program'' in
-their title:
-\begin{lstlisting}
-for (val b <- books; (b.title indexOf "Program") >= 0)
-yield b.title
-\end{lstlisting}
-Or, to find the names of all authors that have written at least two
-books in the database.
-\begin{lstlisting}
-for (val b1 <- books; val b2 <- books; b1 != b2;
-     val a1 <- b1.authors; val a2 <- b2.authors; a1 == a2)
-yield a1
-\end{lstlisting}
-The last solution is not yet perfect, because authors will appear
-several times in the list of results.  We still need to remove
-duplicate authors from result lists.  This can be achieved with the
-following function.
-\begin{lstlisting}
-def removeDuplicates[a](xs: List[a]): List[a] =
-  if (xs.isEmpty) xs
-  else xs.head :: removeDuplicates(xs.tail filter (x => x != xs.head));
-\end{lstlisting}
-Note that the last expression in method \code{removeDuplicates}
-can be equivalently expressed using a for-comprehension.
-\begin{lstlisting}
-xs.head :: removeDuplicates(for (val x <- xs.tail; x != xs.head) yield x)
-\end{lstlisting}
-
-\section{Translation of For-Comprehensions}
-
-Every for-comprehension can be expressed in terms of the three
-higher-order functions \code{map}, \code{flatMap} and \code{filter}.
-Here is the translation scheme, which is also used by the Scala compiler.
-\begin{itemize}
-\item
-A simple for-comprehension
-\begin{lstlisting}
-for (val x <- e) yield e'
-\end{lstlisting}
-is translated to
-\begin{lstlisting}
-e.map(x => e')
-\end{lstlisting}
-\item
-A for-comprehension
-\begin{lstlisting}
-for (val x <- e; f; s) yield e'
-\end{lstlisting}
-where \code{f} is a filter and \code{s} is a (possibly empty)
-sequence of generators or filters
-is translated to
-\begin{lstlisting}
-for (val x <- e.filter(x => f); s) yield e'
-\end{lstlisting}
-and then translation continues with the latter expression.
-\item
-A for-comprehension
-\begin{lstlisting}
-for (val x <- e; y <- e'; s) yield e''
-\end{lstlisting}
-where \code{s} is a (possibly empty)
-sequence of generators or filters
-is translated to
-\begin{lstlisting}
-e.flatMap(x => for (y <- e'; s) yield e'')
-\end{lstlisting}
-and then translation continues with the latter expression.
-\end{itemize}
-For instance, taking our "pairs of integers whose sum is prime" example:
-\begin{lstlisting}
-for ( val i <- range(1, n);
-      val j <- range(1, i);
-      isPrime(i+j)
-) yield (i, j)
-\end{lstlisting}
-Here is what we get when we translate this expression:
-\begin{lstlisting}
-range(1, n)
-  .flatMap(i =>
-    range(1, i)
-      .filter(j => isPrime(i+j))
-      .map(j => (i, j)))
-\end{lstlisting}
-
-Conversely, it would also be possible to express functions \code{map},
-\code{flatMap}{ and \code{filter} using for-comprehensions. Here are the
-three functions again, this time implemented using for-comprehensions.
-\begin{lstlisting}
-object Demo {
-  def map[a, b](xs: List[a], f: a => b): List[b] = 
-    for (val x <- xs) yield f(x);
-
-  def flatMap[a, b](xs: List[a], f: a => List[b]): List[b] = 
-    for (val x <- xs; val y <- f(x)) yield y;
-
-  def filter[a](xs: List[a], p: a => boolean): List[a] = 
-    for (val x <- xs; p(x)) yield x;
-}
-\end{lstlisting}
-Not surprisingly, the translation of the for-comprehension in the body of
-\code{Demo.map} will produce a call to \code{map} in class \code{List}.
-Similarly, \code{Demo.flatMap} and \code{Demo.filter} translate to
-\code{flatMap} and \code{filter} in class \code{List}.
-
-\begin{exercise}
-Define the following function in terms of \code{for}.
-\begin{lstlisting}
-def flatten(xss: List[List[a]]): List[a] =
-  (xss :\ List()) ((xs, ys) => xs ::: ys)
-\end{lstlisting}
-\end{exercise}
-
-\begin{exercise}
-Translate
-\begin{lstlisting}
-for ( val b <- books; val a <- b.authors; a startsWith "Bird" ) yield b.title
-for ( val b <- books; (b.title indexOf "Program") >= 0 ) yield b.title
-\end{lstlisting}
-to higher-order functions.
-\end{exercise}
-
-\section{For-Loops}\label{sec:for-loops}
-
-For-comprehensions resemble for-loops in imperative languages, except
-that they produce a list of results. Sometimes, a list of results is
-not needed but we would still like the flexibility of generators and
-filters in iterations over lists. This is made possible by a variant
-of the for-comprehension syntax, which expresses for-loops:
-\begin{lstlisting}
-for ( $s$ ) $e$
-\end{lstlisting}
-This construct is the same as the standard for-comprehension syntax
-except that the keyword \code{yield} is missing. The for-loop is
-executed by executing the expression $e$ for each element generated
-from the sequence of generators and filters $s$.
-
-As an example, the following expression prints out all elements of a
-matrix represented as a list of lists:
- \begin{lstlisting}
-for (xs <- xss) {
-  for (x <- xs) System.out.print(x + "\t")
-  System.out.println()
-}
-\end{lstlisting}
-The translation of for-loops to higher-order methods of class
-\code{List} is similar to the translation of for-comprehensions, but
-is simpler. Where for-comprehensions translate to \code{map} and
-\code{flatMap}, for-loops translate in each case to \code{foreach}.
-
-\section{Generalizing For}
-
-We have seen that the translation of for-comprehensions only relies on
-the presence of methods \code{map}, \code{flatMap}, and
-\code{filter}. Therefore it is possible to apply the same notation to
-generators that produce objects other than lists; these objects only
-have to support the three key functions \code{map}, \code{flatMap},
-and \code{filter}.
-
-The standard Scala library has several other abstractions that support
-these three methods and with them support for-comprehensions. We will
-encounter some of them in the following chapters. As a programmer you
-can also use this principle to enable for-comprehensions for types you
-define -- these types just need to support methods \code{map},
-\code{flatMap}, and \code{filter}.
-
-There are many examples where this is useful: Examples are database
-interfaces, XML trees, or optional values. We will see in
-Chapter~\ref{sec:parsers-results} how for-comprehensions can be used
-in the definition of parsers for context-free grammars that construct
-abstract syntax trees.
-
-One caveat: It is not assured automatically that the result
-translating a for-comprehension is well-typed. To ensure this, the
-types of \code{map}, \code{flatMap} and \code{filter} have to be
-essentially similar to the types of these methods in class \code{List}.
-
-To make this precise, assume you have a parameterized class
- \code{C[a]} for which you want to enable for-comprehensions. Then
- \code{C} should define \code{map}, \code{flatMap} and \code{filter}
- with the following types:
-\begin{lstlisting}
-def map[b](f: a => b): C[b]
-def flatMap[b](f: a => C[b]): C[b]
-def filter(p: a => boolean): C[a]
-\end{lstlisting}
-It would be attractive to enforce these types statically in the Scala
-compiler, for instance by requiring that any type supporting
-for-comprehensions implements a standard trait with these methods
-\footnote{In the programming language Haskell, which has similar
-constructs, this abstraction is called a ``monad with zero''}.  The
-problem is that such a standard trait would have to abstract over the
-identity of the class \code{C}, for instance by taking \code{C} as a
-type parameter.  Note that this parameter would be a type constructor,
-which gets applied to {\em several different} types in the signatures of
-methods \code{map} and \code{flatMap}. Unfortunately, the Scala type
-system is too weak to express this construct, since it can handle only
-type parameters which are fully applied types.
-
-\chapter{Mutable State}
-
-Most programs we have presented so for did not have side-effects
-\footnote{We ignore here the fact that some of our program printed to
-standard output, which technically is a side effect.}.  Therefore, the
-notion of {\em time} did not matter.  For a program that terminates,
-any sequence of actions would have led to the same result!  This is
-also reflected by the substitution model of computation, where a
-rewrite step can be applied anywhere in a term, and all rewritings
-that terminate lead to the same solution.  In fact, this {\em
-confluence} property is a deep result in $\lambda$-calculus, the
-theory underlying functional programming. 
-
-In this chapter, we introduce functions with side effects and study
-their behavior. We will see that as a consequence we have to
-fundamentally modify up the substitution model of computation which we
-employed so far.
-
-\section{Stateful Objects}
-
-We normally view the world as a set of objects, some of which have
-state that {\em changes} over time.  Normally, state is associated
-with a set of variables that can be changed in the course of a
-computation.  There is also a more abstract notion of state, which
-does not refer to particular constructs of a programming language: An
-object {\em has state} (or: {\em is stateful}) if its behavior is
-influenced by its history.
-
-For instance, a bank account object has state, because the question
-``can I withdraw 100 CHF?''
-might have different answers during the lifetime of the account.
-
-In Scala, all mutable state is ultimately built from variables.  A
-variable definition is written like a value definition, but starts
-with \verb@var@ instead of \verb@val@. For instance, the following two
-definitions introduce and initialize two variables \code{x} and
-\code{count}.
-\begin{lstlisting}
-var x: String = "abc";
-var count = 111;
-\end{lstlisting}
-Like a value definition, a variable definition associates a name with
-a value. But in the case of a variable definition, this association
-may be changed later by an assignment.  Such assignments are written
-as in C or Java. Examples:
-\begin{lstlisting}
-x = "hello";
-count = count + 1;
-\end{lstlisting}
-In Scala, every defined variable has to be initialized at the point of
-its definition. For instance, the statement ~\code{var x: int;}~ is
-{\em not} regarded as a variable definition, because the initializer
-is missing\footnote{If a statement like this appears in a class, it is
-instead regarded as a variable declaration, which introduces
-abstract access methods for the variable, but does not associate these
-methods with a piece of state.}. If one does not know, or does not
-care about, the appropriate initializer, one can use a wildcard
-instead. I.e.
-\begin{lstlisting}
-val x: T = _;
-\end{lstlisting}
-will initialize \code{x} to some default value (\code{null} for
-reference types, \code{false} for booleans, and the appropriate
-version of \code{0} for numeric value types).
-
-Real-world objects with state are represented in Scala by objects that
-have variables as members. For instance, here is a class that
-represents bank accounts.
-\begin{lstlisting}
-class BankAccount {
-  private var balance = 0;
-  def deposit(amount: int): unit =
-    if (amount > 0) balance = balance + amount;
-
-  def withdraw(amount: int): int =
-    if (0 < amount && amount <= balance) {
-      balance = balance - amount;
-      balance
-    } else throw new Error("insufficient funds");
-}
-\end{lstlisting}
-The class defines a variable \code{balance} which contains the current
-balance of an account. Methods \code{deposit} and \code{withdraw}
-change the value of this variable through assignments.  Note that
-\code{balance} is \code{private} in class \code{BankAccount} -- hence
-it can not be accessed directly outside the class.
-
-To create bank-accounts, we use the usual object creation notation:
-\begin{lstlisting}
-val myAccount = new BankAccount
-\end{lstlisting}
-
-\example Here is a \code{scalaint} session that deals with bank
-accounts.
-
-\begin{lstlisting}
-> :l bankaccount.scala
-loading file 'bankaccount.scala'
-> val account = new BankAccount
-val account : BankAccount = BankAccount$\Dollar$class@1797795
-> account deposit 50
-(): scala.Unit
-> account withdraw 20
-30: scala.Int
-> account withdraw 20
-10: scala.Int
-> account withdraw 15
-java.lang.RuntimeException: insufficient funds
-        at BankAccount$\Dollar$class.withdraw(bankaccount.scala:13)
-        at <top-level>(console:1)
-> 
-\end{lstlisting}
-The example shows that applying the same operation (\code{withdraw
-20}) twice to an account yields different results. So, clearly,
-accounts are stateful objects.  
-
-\paragraph{Sameness and Change}
-Assignments pose new problems in deciding when two expressions are
-``the same''.
-If assignments are excluded, and one writes
-\begin{lstlisting}
-val x = E; val y = E;
-\end{lstlisting}
-where \code{E} is some arbitrary expression,
-then \code{x} and \code{y} can reasonably be assumed to be the same.
-I.e. one could have equivalently written
-\begin{lstlisting}
-val x = E; val y = x;
-\end{lstlisting}
-(This property is usually called {\em referential transparency}). But
-once we admit assignments, the two definition sequences are different.
-Consider:
-\begin{lstlisting}
-val x = new BankAccount; val y = new BankAccount;
-\end{lstlisting}
-To answer the question whether \code{x} and \code{y} are the same, we
-need to be more precise what ``sameness'' means. This meaning is
-captured in the notion of {\em operational equivalence}, which,
-somewhat informally, is stated as follows.
-
-Suppose we have two definitions of \code{x} and \code{y}.
-To test whether \code{x} and \code{y} define the same value, proceed
-as follows.
-\begin{itemize}
-\item
-Execute the definitions followed by an
-arbitrary sequence \code{S} of operations that involve \code{x} and
-\code{y}. Observe the results (if any).
-\item
-Then, execute the definitions with another sequence \code{S'} which
-results from \code{S} by renaming all occurrences of \code{y} in
-\code{S} to \code{x}.
-\item
-If the results of running \code{S'} are different, then surely
-\code{x} and \code{y} are different.
-\item
-On the other hand, if all possible pairs of sequences \code{(S, S')}
-yield the same results, then \code{x} and \code{y} are the same.
-\end{itemize}
-In other words, operational equivalence regards two definitions
-\code{x} and \code{y} as defining the same value, if no possible
-experiment can distinguish between \code{x} and \code{y}. An
-experiment in this context are two version of an arbitrary program which use either
-\code{x} or \code{y}.
- 
-Given this definition, let's test whether
-\begin{lstlisting}
-val x = new BankAccount; val y = new BankAccount;
-\end{lstlisting}
-defines values \code{x} and \code{y} which are the same.
-Here are the definitions again, followed by a test sequence:
-
-\begin{lstlisting}
-> val x = new BankAccount
-> val y = new BankAccount
-> x deposit 30
-30
-> y withdraw 20
-java.lang.RuntimeException: insufficient funds
-\end{lstlisting}
-
-Now, rename all occurrences of \code{y} in that sequence to
-\code{x}. We get:
-\begin{lstlisting}
-> val x = new BankAccount
-> val y = new BankAccount
-> x deposit 30
-30
-> x withdraw 20
-10
-\end{lstlisting}
-Since the final results are different, we have established that
-\code{x} and \code{y} are not the same.
-On the other hand, if we define
-\begin{lstlisting}
-val x = new BankAccount; val y = x
-\end{lstlisting}
-then no sequence of operations can distinguish between \code{x} and
-\code{y}, so \code{x} and \code{y} are the same in this case.
-
-\paragraph{Assignment and the Substitution Model}
-These examples show that our previous substitution model of
-computation cannot be used anymore.  After all, under this
-model we could always replace a value name by its
-defining expression.
-For instance in
-\begin{lstlisting}
-val x = new BankAccount; val y = x
-\end{lstlisting}
-the \code{x} in the definition of \code{y} could
-be replaced by \code{new BankAccount}.
-But we have seen that this change leads to a different program.
-So the substitution model must be invalid, once we add assignments. 
-
-\section{Imperative Control Structures}
-
-Scala has the \code{while} and \code{do-while} loop constructs known
-from the C and Java languages. There is also a single branch \code{if}
-which leaves out the else-part as well as a \code{return} statement which
-aborts a function prematurely. This makes it possible to program in a
-conventional imperative style. For instance, the following function,
-which computes the \code{n}'th power of a given parameter \code{x}, is
-implemented using \code{while} and single-branch \code{if}.
-\begin{lstlisting}
-def power (x: double, n: int): double = {
-  var r = 1.0;
-  var i = n;
-  while (i > 0) { 
-    if ((i & 1) == 1) { r = r * x }
-    if (i > 1) r = r * r;
-    i = i >> 1;
-  }
-  r
-}
-\end{lstlisting}
-These imperative control constructs are in the language for
-convenience. They could have been left out, as the same constructs can
-be implemented using just functions. As an example, let's develop a
-functional implementation of the while loop. \code{whileLoop} should
-be a function that takes two parameters: a condition, of type
-\code{boolean}, and a command, of type \code{unit}. Both condition and
-command need to be passed by-name, so that they are evaluated
-repeatedly for each loop iteration.  This leads to the following
-definition of \code{whileLoop}.
-\begin{lstlisting}
-def whileLoop(condition: => boolean)(command: => unit): unit = 
-  if (condition) {
-    command; whileLoop(condition)(command)
-  } else {}
-\end{lstlisting}
-Note that \code{whileLoop} is tail recursive, so it operates in
-constant stack space.
-
-\begin{exercise} Write a function \code{repeatLoop}, which should be 
-applied as follows:
-\begin{lstlisting}
-repeatLoop { command } ( condition )
-\end{lstlisting}
-Is there also a way to obtain a loop syntax like the following?
-\begin{lstlisting}
-repeatLoop { command } until ( condition )
-\end{lstlisting}
-\end{exercise}
-
-Some other control constructs known from C and Java are missing in
-Scala: There are no \code{break} and \code{continue} jumps for loops.
-There are also no for-loops in the Java sense -- these have been
-replaced by the more general for-loop construct discussed in
-Section~\ref{sec:for-loops}.
-
-\section{Extended Example: Discrete Event Simulation}
-
-We now discuss an example that demonstrates how assignments and
-higher-order functions can be combined in interesting ways.  
-We will build a simulator for digital circuits.
-
-The example is taken from Abelson and Sussman's book
-\cite{abelson-sussman:structure}. We augment their basic (Scheme-)
-code by an object-oriented structure which allows code-reuse through
-inheritance. The example also shows how discrete event simulation programs
-in general are structured and built.
-
-We start with a little language to describe digital circuits.
-A digital circuit is built from {\em wires} and {\em function boxes}.
-Wires carry signals which are transformed by function boxes.
-We will represent signals by the booleans \code{true} and
-\code{false}.
-
-Basic function boxes (or: {\em gates}) are:
-\begin{itemize}
-\item An \emph{inverter}, which negates its signal
-\item An \emph{and-gate}, which sets its output to the conjunction of its input.
-\item An \emph{or-gate}, which sets its output to the disjunction of its
-input.
-\end{itemize}
-Other function boxes can be built by combining basic ones.
-
-Gates have {\em delays}, so an output of a gate will change only some
-time after its inputs change.
-
-\paragraph{A Language for Digital Circuits}
-
-We describe the elements of a digital circuit by the following set of
-Scala classes and functions.
-
-First, there is a class \code{Wire} for wires.
-We can construct wires as follows.
-\begin{lstlisting}
-val a = new Wire;
-val b = new Wire;
-val c = new Wire;
-\end{lstlisting}
-Second, there are functions
-\begin{lstlisting}
-def inverter(input: Wire, output: Wire): unit
-def andGate(a1: Wire, a2: Wire, output: Wire): unit
-def orGate(o1: Wire, o2: Wire, output: Wire): unit
-\end{lstlisting}
-which ``make'' the basic gates we need (as side-effects).
-More complicated function boxes can now be built from these.
-For instance, to construct a half-adder, we can define:
-
-\begin{lstlisting}
-  def halfAdder(a: Wire, b: Wire, s: Wire, c: Wire): unit = {
-    val d = new Wire;
-    val e = new Wire;
-    orGate(a, b, d);
-    andGate(a, b, c);
-    inverter(c, e);
-    andGate(d, e, s);
-  }
-\end{lstlisting}
-This abstraction can itself be used, for instance in defining a full
-adder:
-\begin{lstlisting}
-  def fullAdder(a: Wire, b: Wire, cin: Wire, sum: Wire, cout: Wire) = {
-    val s = new Wire;
-    val c1 = new Wire;
-    val c2 = new Wire;
-    halfAdder(a, cin, s, c1);
-    halfAdder(b, s, sum, c2);
-    orGate(c1, c2, cout);
-  }
-\end{lstlisting}
-Class \code{Wire} and functions \code{inverter}, \code{andGate}, and
-\code{orGate} represent thus a little language in which users can
-define digital circuits.  We now give implementations of this class
-and these functions, which allow one to simulate circuits.
-These implementations are based on a simple and general API for
-discrete event simulation.
-
-\paragraph{The Simulation API}
-
-Discrete event simulation performs user-defined \emph{actions} at
-specified \emph{times}.  
-An {\em action} is represented as a function which takes no parameters and
-returns a \code{unit} result:
-\begin{lstlisting}
-type Action = () => unit;
-\end{lstlisting}
-The \emph{time} is simulated; it is not the actual ``wall-clock'' time.
-
-A concrete simulation will be done inside an object which inherits
-from the abstract \code{Simulation} class. This class has the following
-signature:
-
-\begin{lstlisting}
-abstract class Simulation {
-  def currentTime: int;
-  def afterDelay(delay: int, action: => Action): unit;
-  def run: unit;
-}
-\end{lstlisting}
-Here,
-\code{currentTime} returns the current simulated time as an integer
-number,
-\code{afterDelay} schedules an action to be performed at a specified
-delay after \code{currentTime}, and
-\code{run} runs the simulation until there are no further actions to be 
-performed.
-
-\paragraph{The Wire Class}
-A wire needs to support three basic actions.
-\begin{itemize}
-\item[]
-\code{getSignal: boolean}~~ returns the current signal on the wire.
-\item[]
-\code{setSignal(sig: boolean): unit}~~ sets the wire's signal to \code{sig}.
-\item[]
-\code{addAction(p: Action): unit}~~ attaches the specified procedure
-\code{p} to the {\em actions} of the wire. All attached action
-procedures will be executed every time the signal of a wire changes.
-\end{itemize}
-Here is an implementation of the \code{Wire} class:
-\begin{lstlisting}
-class Wire {
-  private var sigVal = false;
-  private var actions: List[Action] = List();
-  def getSignal = sigVal;
-  def setSignal(s: boolean) = 
-    if (s != sigVal) {
-      sigVal = s;
-      actions.foreach(action => action()); 
-    }
-  def addAction(a: Action) = {
-    actions = a :: actions; a()
-  }
-}
-\end{lstlisting}
-Two private variables make up the state of a wire.  The variable
-\code{sigVal} represents the current signal, and the variable
-\code{actions} represents the action procedures currently attached to
-the wire.
-
-\paragraph{The Inverter Class}
-We implement an inverter by installing an action on its input wire,
-namely the action which puts the negated input signal onto the output
-signal.  The action needs to take effect at \code{InverterDelay}
-simulated time units after the input changes. This suggests the 
-following implementation:
-\begin{lstlisting}
-def inverter(input: Wire, output: Wire) = {
-  def invertAction() = {
-    val inputSig = input.getSignal;
-    afterDelay(InverterDelay, () => output.setSignal(!inputSig))
-  }
-  input addAction invertAction
-}
-\end{lstlisting}
-
-\paragraph{The And-Gate Class}
-And-gates are implemented analogously to inverters.  The action of an
-\code{andGate} is to output the conjunction of its input signals.
-This should happen at \code{AndGateDelay} simulated time units after
-any one of its two inputs changes. Hence, the following implementation:
-\begin{lstlisting}
-def andGate(a1: Wire, a2: Wire, output: Wire) = {
-  def andAction() = {
-    val a1Sig = a1.getSignal;
-    val a2Sig = a2.getSignal;
-    afterDelay(AndGateDelay, () => output.setSignal(a1Sig & a2Sig));
-  }
-  a1 addAction andAction;
-  a2 addAction andAction;
-}
-\end{lstlisting}
-
-\begin{exercise} Write the implementation of \code{orGate}.
-\end{exercise}
-
-\begin{exercise} Another way is to define an or-gate by a combination of
-inverters and and gates. Define a function \code{orGate} in terms of
-\code{andGate} and \code{inverter}. What is the delay time of this function?
-\end{exercise}
-
-\paragraph{The Simulation Class}
-
-Now, we just need to implement class \code{Simulation}, and we are
-done.  The idea is that we maintain inside a \code{Simulation} object
-an \emph{agenda} of actions to perform.  The agenda is represented as
-a list of pairs of actions and the times they need to be run.  The
-agenda list is sorted, so that earlier actions come before later ones.
-\begin{lstlisting} 
-class Simulation {
-  private type Agenda = List[Pair[int, Action]];
-  private var agenda: Agenda = List();
-\end{lstlisting}
-There is also a private variable \code{curtime} to keep track of the
-current simulated time.
-\begin{lstlisting}
-  private var curtime = 0;
-\end{lstlisting}
-An application of the method \code{afterDelay(delay, action)} 
-inserts the pair \code{(curtime + delay, action)} into the
-\code{agenda} list at the appropriate place.
-\begin{lstlisting}
-  def afterDelay(int delay)(action: => Action): unit = {
-    val actiontime = curtime + delay;
-    def insertAction(ag: Agenda): Agenda = ag match {
-      case List() => 
-        Pair(actiontime, action) :: ag
-      case (first @ Pair(time, act)) :: ag1 =>
-        if (actiontime < time) Pair(actiontime, action) :: ag
-        else first :: insert(ag1)
-    }
-    agenda = insert(agenda)
-  }
-\end{lstlisting}
-An application of the \code{run} method removes successive elements
-from the \code{agenda} and performs their actions.
-It continues until the agenda is empty:
-\begin{lstlisting}
-def run = {
-  afterDelay(0, () => System.out.println("*** simulation started ***"));
-  agenda match {
-    case List() =>
-    case Pair(_, action) :: agenda1 =>
-      agenda = agenda1; action(); run
-  }
-}
-\end{lstlisting}
-
-
-\paragraph{Running the Simulator}
-To run the simulator, we still need a way to inspect changes of
-signals on wires. To this purpose, we write a function \code{probe}.
-\begin{lstlisting}
-def probe(name: String, wire: Wire): unit = {
-  wire addAction (() =>
-    System.out.println(
-      name + " " + currentTime + " new_value = " + wire.getSignal);
-  )
-}
-\end{lstlisting}
-Now, to see the simulator in action, let's define four wires, and place
-probes on two of them: 
-\begin{lstlisting}
-> val input1 = new Wire
-> val input2 = new Wire
-> val sum = new Wire
-> val carry = new Wire
-
-> probe("sum", sum)
-sum 0 new_value = false
-> probe("carry", carry)
-carry 0 new_value = false
-\end{lstlisting}
-Now let's define a half-adder connecting the wires:
-\begin{lstlisting}
-> halfAdder(input1, input2, sum, carry);
-\end{lstlisting}
-Finally, set one after another the signals on the two input wires to
-\code{true} and run the simulation.
-\begin{lstlisting}
-> input1 setSignal true; run
-*** simulation started ***
-sum 8 new_value = true
-> input2 setSignal true; run
-carry 11 new_value = true
-sum 15 new_value = false
-\end{lstlisting}
-
-\section{Summary}
-
-We have seen in this chapter the constructs that let us model state in
-Scala -- these are variables, assignments, and imperative control
-structures.  State and Assignment complicate our mental model of
-computation.  In particular, referential transparency is lost.  On the
-other hand, assignment gives us new ways to formulate programs
-elegantly. As always, it depends on the situation whether purely
-functional programming or programming with assignments works best.
-
-\chapter{Computing with Streams}
-
-The previous chapters have introduced variables, assignment and
-stateful objects.  We have seen how real-world objects that change
-with time can be modeled by changing the state of variables in a
-computation.  Time changes in the real world thus are modeled by time
-changes in program execution. Of course, such time changes are usually
-stretched out or compressed, but their relative order is the same.
-This seems quite natural, but there is a also price to pay: Our simple
-and powerful substitution model for functional computation is no
-longer applicable once we introduce variables and assignment.
-
-Is there another way? Can we model state change in the real world
-using only immutable functions? Taking mathematics as a guide, the
-answer is clearly yes: A time-changing quantity is simply modeled by
-a function \code{f(t)} with a time parameter \code{t}. The same can be
-done in computation. Instead of overwriting a variable with successive
-values, we represent all these values as successive elements in a
-list. So, a mutable variable \code{var x: T} gets replaced by an
-immutable value \code{val x: List[T]}. In a sense, we trade space for
-time -- the different values of the variable now all exit concurrently
-as different elements of the list.  One advantage of the list-based
-view is that we can ``time-travel'', i.e. view several successive
-values of the variable at the same time. Another advantage is that we
-can make use of the powerful library of list processing functions,
-which often simplifies computation. For instance, consider the
-imperative way to compute the sum of all prime numbers in an interval:
-\begin{lstlisting}
-def sumPrimes(start: int, end: int): int = {
-  var i = start;
-  var acc = 0;
-  while (i < end) {
-    if (isPrime(i)) acc = acc + i;
-    i = i + 1;
-  }
-  acc
-}
-\end{lstlisting}
-Note that the variable \code{i} ``steps through'' all values of the interval
-\code{[start .. end-1]}.
-
-A more functional way is to represent the list of values of variable \code{i} directly as \code{range(start, end)}. Then the function can be rewritten as follows.
-\begin{lstlisting}
-def sumPrimes(start: int, end: int) =
-  sum(range(start, end) filter isPrime);
-\end{lstlisting}
-
-No contest which program is shorter and clearer!  However, the
-functional program is also considerably less efficient since it
-constructs a list of all numbers in the interval, and then another one
-for the prime numbers. Even worse from an efficiency point of view is
-the following example:
-
-To find the second prime number between \code{1000} and \code{10000}:
-\begin{lstlisting}
-  range(1000, 10000) filter isPrime at 1
-\end{lstlisting}
-Here, the list of all numbers between \code{1000} and \code{10000} is
-constructed.  But most of that list is never inspected!
-
-However, we can obtain efficient execution for examples like these by
-a trick:
-\begin{quote}
-%\red
- Avoid computing the tail of a sequence unless that tail is actually
-     necessary for the computation.
-\end{quote}
-We define a new class for such sequences, which is called \code{Stream}.
-
-Streams are created using the constant \code{empty} and the constructor \code{cons},
-which are both defined in module \code{scala.Stream}. For instance, the following
-expression constructs a stream with elements \code{1} and \code{2}:
-\begin{lstlisting}
-Stream.cons(1, Stream.cons(2, Stream.empty))
-\end{lstlisting}
-As another example, here is the analogue of \code{List.range},
-but returning a stream instead of a list:
-\begin{lstlisting}
-def range(start: Int, end: Int): Stream[Int] = 
-  if (start >= end) Stream.empty
-  else Stream.cons(start, range(start + 1, end));
-\end{lstlisting}
-(This function is also defined as given above in module
-\code{Stream}).  Even though \code{Stream.range} and \code{List.range}
-look similar, their execution behavior is completely different: 
-
-\code{Stream.range} immediately returns with a \code{Stream} object
-whose first element is \code{start}.  All other elements are computed
-only when they are \emph{demanded} by calling the \code{tail} method
-(which might be never at all).  
-
-Streams are accessed just as lists. as for lists, the basic access
-methods are \code{isEmpty}, \code{head} and \code{tail}. For instance,
-we can print all elements of a stream as follows.
-\begin{lstlisting}
-def print(xs: Stream[a]): unit = 
-  if (!xs.isEmpty) { System.out.println(xs.head); print(xs.tail) };
-\end{lstlisting}
-Streams also support almost all other methods defined on lists (see
-below for where their methods sets differ). For instance, we can find
-the second prime number between \code{1000} and \code{10000} by applying methods
-\code{filter} and \code{apply} on an interval stream:
-\begin{lstlisting}
-  Stream.range(1000, 10000) filter isPrime at 1
-\end{lstlisting}
-The difference to the previous list-based implementation is that now
-we do not needlessly construct and test for primality any numbers
-beyond 3.
-
-\paragraph{Consing and appending streams} Two methods in class \code{List}
-which are not supported by class \code{Stream} are \code{::} and
-\code{:::}.  The reason is that these methods are dispatched on their
-right-hand side argument, which means that this argument needs to be
-evaluated before the method is called. For instance, in the case of
-\code{x :: xs} on lists, the tail \code{xs} needs to be evaluated
-before \code{::} can be called and the new list can be constructed.
-This does not work for streams, where we require that the tail of a
-stream should not be evaluated until it is demanded by a \code{tail} operation.
-The argument why list-append \code{:::} cannot be adapted to streams is analogous.
-
-Instead of \code{x :: xs}, one uses \code{Stream.cons(x, xs)} for
-constructing a stream with first element \code{x} and (unevaluated)
-rest \code{xs}.  Instead of \code{xs ::: ys}, one uses the operation
-\code{xs append ys}.  
-
-\chapter{Iterators}
-
-Iterators are the imperative version of streams. Like streams,
-iterators describe potentially infinite lists. However, there is no
-data-structure which contains the elements of an iterator. Instead, 
-iterators allow one to step through the sequence, using two abstract methods \code{next} and \code{hasNext}.
-\begin{lstlisting}
-trait Iterator[+a] {
-  def hasNext: boolean;
-  def next: a;
-\end{lstlisting}
-Method \code{next} returns successive elements.  Method \code{hasNext}
-indicates whether there are still more elements to be returned by
-\code{next}. Iterators also support some other methods, which are
-explained later.
-
-As an example, here is an application which prints the squares of all
-numbers from 1 to 100.
-\begin{lstlisting}
-var it: Iterator[int] = Iterator.range(1, 100);
-while (it.hasNext) {
-  val x = it.next;
-  System.out.println(x * x)
-}
-\end{lstlisting}
-
-\section{Iterator Methods}
-
-Iterators support a rich set of methods besides \code{next} and
-\code{hasNext}, which is described in the following. Many of these
-methods mimic a corresponding functionality in lists.
-
-\paragraph{Append}
-Method \code{append} constructs an iterator which resumes with the
-given iterator \code{it} after the current iterator has finished.
-\begin{lstlisting}
-  def append[b >: a](that: Iterator[b]): Iterator[b] = new Iterator[b] {
-    def hasNext = Iterator.this.hasNext || that.hasNext;
-    def next = if (Iterator.this.hasNext) Iterator.this.next else that.next;
-  }    
-\end{lstlisting}
-The terms \code{Iterator.this.next} and \code{Iterator.this.hasNext}
-in the definition of \code{append} call the corresponding methods as
-they are defined in the enclosing \code{Iterator} class.  If the
-\code{Iterator} prefix to \code{this} would have been missing,
-\code{hasNext} and \code{next} would have called recursively the
-methods being defined in the result of \code{append}, which is not
-what we want.
-
-\paragraph{Map, FlatMap, Foreach} Method \code{map} 
-constructs an iterator which returns all elements of the original
-iterator transformed by a given function \code{f}.
-\begin{lstlisting}
-  def map[b](f: a => b): Iterator[b] = new Iterator[b] {
-    def hasNext = Iterator.this.hasNext;
-    def next = f(Iterator.this.next);
-  }
-\end{lstlisting}
-Method \code{flatMap} is like method \code{map}, except that the
-transformation function \code{f} now returns an iterator.
-The result of \code{flatMap} is the iterator resulting from appending
-together all iterators returned from successive calls of \code{f}.
-\begin{lstlisting}
-  def flatMap[b](f: a => Iterator[b]): Iterator[b] = new Iterator[b] {
-    private var cur: Iterator[b] = Iterator.empty;
-    def hasNext: Boolean = 
-      if (cur.hasNext) true
-      else if (Iterator.this.hasNext) { cur = f(Iterator.this.next); hasNext }
-      else false;
-    def next: b = 
-      if (cur.hasNext) cur.next
-      else if (Iterator.this.hasNext) { cur = f(Iterator.this.next); next }
-      else throw new Error("next on empty iterator");
-  }
-\end{lstlisting}
-Closely related to \code{map} is the \code{foreach} method, which
-applies a given function to all elements of an iterator, but does not
-construct a list of results
-\begin{lstlisting}
-  def foreach(f: a => Unit): Unit = 
-    while (hasNext) { f(next) }
-\end{lstlisting}
-
-\paragraph{Filter} Method \code{filter} constructs an iterator which
-returns all elements of the original iterator that satisfy a criterion
-\code{p}.
-\begin{lstlisting}
-  def filter(p: a => Boolean) = new BufferedIterator[a] {
-    private val source = 
-      Iterator.this.buffered;
-    private def skip: Unit = 
-      while (source.hasNext && !p(source.head)) { source.next; () }
-    def hasNext: Boolean = 
-      { skip; source.hasNext }
-    def next: a = 
-      { skip; source.next }
-    def head: a = 
-      { skip; source.head; }
-  }
-\end{lstlisting}
-In fact, \code{filter} returns instances of a subclass of iterators
-which are ``buffered''.  A \code{BufferedIterator} object is an
-iterator which has in addition a method \code{head}. This method
-returns the element which would otherwise have been returned by
-\code{head}, but does not advance beyond that element. Hence, the
-element returned by \code{head} is returned again by the next call to
-\code{head} or \code{next}. Here is the definition of the
-\code{BufferedIterator} trait.
-\begin{lstlisting}
-trait BufferedIterator[+a] extends Iterator[a] {
-  def head: a;
-}
-\end{lstlisting}
-Since \code{map}, \code{flatMap}, \code{filter}, and \code{foreach}
-exist for iterators, it follows that for-comprehensions and for-loops
-can also be used on iterators. For instance, the application which prints the squares of numbers between 1 and 100 could have equivalently been expressed as follows.
-\begin{lstlisting}
-for (val i <- Iterator.range(1, 100))
-  System.out.println(i * i);
-\end{lstlisting}
-
-\paragraph{Zip} Method \code{zip} takes another iterator and
-returns an iterator consisting of pairs of corresponding elements
-returned by the two iterators.
-\begin{lstlisting}
-  def zip[b](that: Iterator[b]) = new Iterator[Pair[a, b]] {
-    def hasNext = Iterator.this.hasNext && that.hasNext;
-    def next = Pair(Iterator.this.next, that.next);
-  }
-}
-\end{lstlisting}
-
-\section{Constructing Iterators}
-
-Concrete iterators need to provide implementations for the two
-abstract methods \code{next} and \code{hasNext} in class
-\code{Iterator}. The simplest iterator is \code{Iterator.empty} which
-always returns an empty sequence:
-\begin{lstlisting}
-object Iterator {
-  object empty extends Iterator[All] {
-    def hasNext = false;
-    def next: a = throw new Error("next on empty iterator");
-  }
-\end{lstlisting}
-A more interesting iterator enumerates all elements of an array. This
-iterator is constructed by the \code{fromArray} method, which is also defined in the object \code{Iterator}
-\begin{lstlisting}
-  def fromArray[a](xs: Array[a]) = new Iterator[a] {
-    private var i = 0;
-    def hasNext: Boolean = 
-      i < xs.length;
-    def next: a = 
-      if (i < xs.length) { val x = xs(i) ; i = i + 1 ; x }
-      else throw new Error("next on empty iterator");
-  }
-\end{lstlisting}
-Another iterator enumerates an integer interval.  The
-\code{Iterator.range} function returns an iterator which traverses a
-given interval of integer values. It is defined as follows.
-\begin{lstlisting}
-object Iterator {
-  def range(start: int, end: int) = new Iterator[int] {
-    private var current = start;
-    def hasNext = current < end;
-    def next = {
-      val r = current;
-      if (current < end) current = current + 1
-      else throw new Error("end of iterator");
-      r
-    }
-  }
-}
-\end{lstlisting}
-All iterators seen so far terminate eventually. It is also possible to
-define iterators that go on forever. For instance, the following
-iterator returns successive integers from some start
-value\footnote{Due to the finite representation of type \prog{int},
-numbers will wrap around at $2^31$.}.
-\begin{lstlisting}
-def from(start: int) = new Iterator[int] {
-  private var last = start - 1;
-  def hasNext = true;
-  def next = { last = last + 1; last }
-}
-\end{lstlisting}
-
-\section{Using Iterators}
-
-Here are two more examples how iterators are used. First, to print all
-elements of an array \code{xs: Array[int]}, one can write:
-\begin{lstlisting}
-  Iterator.fromArray(xs) foreach (x => 
-    System.out.println(x))
-\end{lstlisting}
-Or, using a for-comprehension:
-\begin{lstlisting}
-  for (val x <- Iterator.fromArray(xs)) 
-    System.out.println(x)
-\end{lstlisting}
-As a second example, consider the problem of finding the indices of
-all the elements in an array of \code{double}s greater than some
-\code{limit}. The indices should be returned as an iterator.
-This is achieved by the following expression.
-\begin{lstlisting}
-import Iterator._;
-fromArray(xs)
-.zip(from(0))
-.filter(case Pair(x, i) => x > limit)
-.map(case Pair(x, i) => i)
-\end{lstlisting}
-Or, using a for-comprehension:
-\begin{lstlisting}
-import Iterator._;
-for (val Pair(x, i) <- fromArray(xs) zip from(0); x > limit)
-yield i
-\end{lstlisting}
-
-
-
-      
-
-
-
-\chapter{Combinator Parsing}\label{sec:combinator-parsing}
-
-In this chapter we describe how to write combinator parsers in
-Scala. Such parsers are constructed from predefined higher-order
-functions, so called {\em parser combinators}, that closely model the
-constructions of an EBNF grammar \cite{wirth:ebnf}.
-
-As running example, we consider parsers for possibly nested
-lists of identifiers and numbers, which
-are described by the following context-free grammar.
-\bda{p{3cm}cp{10cm}}
-letter &::=& /* all letters */ \\
-digit  &::=& /* all digits */ \\[0.5em]
-ident  &::=& letter \{letter $|$ digit \}\\
-number &::=& digit \{digit\}\\[0.5em]
-list   &::=& `(' [listElems] `)' \\
-listElems &::=& expr [`,' listElems] \\
-expr   &::=& ident | number | list
-
-\eda
-
-\section{Simple Combinator Parsing}
-
-In this section we will only be concerned with the task of recognizing
-input strings, not with processing them. So we can describe parsers
-by the sets of input strings they accept.  There are two
-fundamental operators over parsers:
-\code{&&&} expresses the sequential composition of a parser with
-another, while \code{|||} expresses an alternative. These operations
-will both be defined as methods of a \code{Parser} class.  We will
-also define constructors for the following primitive parsers:
-
-\begin{tabular}{ll}
-\code{empty}    & The parser that accepts the empty string
-\\
-\code{fail}     & The parser that accepts no string
-\\
-\code{chr(c: char)}
-                & The parser that accepts the single-character string ``$c$''.
-\\
-\code{chr(p: char => boolean)}
-                & The parser that accepts single-character strings
-                  ``$c$'' \\
-                & for which $p(c)$ is true.
-\end{tabular}
-
-There are also the two higher-order parser combinators \code{opt},
-expressing optionality and \code{rep}, expressing repetition.
-For any parser $p$, \code{opt(}$p$\code{)} yields a parser that
-accepts the strings accepted by $p$ or else the empty string, while
-\code{rep(}$p$\code{)} accepts arbitrary sequences of the strings accepted by
-$p$. In EBNF, \code{opt(}$p$\code{)} corresponds to $[p]$ and
-\code{rep(}$p$\code{)} corresponds to $\{p\}$.
-
-The central idea of parser combinators is that parsers can be produced
-by a straightforward rewrite of the grammar, replacing \code{::=} with
-\code{=}, sequencing with
-\code{&&&}, choice
-\code{|} with \code{|||}, repetition \code{\{...\}} with
-\code{rep(...)} and optional occurrence \code{[...]} with \code{opt(...)}.
-Applying this process to the grammar of lists
-yields the following class.
-\begin{lstlisting}
-abstract class ListParsers extends Parsers {
-  def chr(p: char => boolean): Parser;
-  def chr(c: char): Parser = chr(d: char => d == c);
-
-  def letter    : Parser = chr(Character.isLetter);
-  def digit     : Parser = chr(Character.isDigit);
-
-  def ident     : Parser = letter &&& rep(letter ||| digit);
-  def number    : Parser = digit &&& rep(digit);
-  def list      : Parser = chr('(') &&& opt(listElems) &&& chr(')');
-  def listElems : Parser = expr &&& (chr(',') &&& listElems ||| empty);
-  def expr      : Parser = ident ||| number ||| list;
-}
-\end{lstlisting}
-This class isolates the grammar from other aspects of parsing. It
-abstracts over the type of input 
-and over the method used to parse a single character
-(represented by the abstract method \code{chr(p: char =>
-boolean))}. The missing bits of information need to be supplied by code
-applying the parser class.
-
-It remains to explain how to implement a library with the combinators
-described above. We will pack combinators and their underlying
-implementation in a base class \code{Parsers}, which is inherited by
-\code{ListParsers}.  The first question to decide is which underlying
-representation type to use for a parser. We treat parsers here
-essentially as functions that take a datum of the input type
-\code{intype} and that yield a parse result of type
-\code{Option[intype]}.  The \code{Option} type is predefined as
-follows.
-\begin{lstlisting}
-trait Option[+a];
-case object None extends Option[All];
-case class Some[a](x: a) extends Option[a];
-\end{lstlisting}
-A parser applied to some input either succeeds or fails. If it fails,
-it returns the constant \code{None}. If it succeeds, it returns a
-value of the form \code{Some(in1)} where \code{in1} represents the
-input that remains to be parsed.
-\begin{lstlisting}
-abstract class Parsers {
-  type intype;
-  abstract class Parser {
-    type Result = Option[intype];  
-    def apply(in: intype): Result;
-\end{lstlisting}
-A parser also implements the combinators
-for sequence and alternative:
-\begin{lstlisting}
-  /*** p &&& q applies first p, and if that succeeds, then q
-   */
-  def &&& (q: => Parser) = new Parser {
-    def apply(in: intype): Result = Parser.this.apply(in) match {
-      case None => None
-      case Some(in1)  => q(in1)
-    }
-  }
-
-  /*** p ||| q applies first p, and, if that fails, then q.
-   */
-  def ||| (q: => Parser) = new Parser {
-    def apply(in: intype): Result = Parser.this.apply(in) match {
-      case None => q(in)
-      case s => s
-    }
-  }
-\end{lstlisting}
-The implementations of the primitive parsers \code{empty} and \code{fail}
-are trivial:
-\begin{lstlisting}
-  val empty = new Parser { def apply(in: intype): Result = Some(in) }
-  val fail  = new Parser { def apply(in: intype): Result = None }
-\end{lstlisting}
-The higher-order parser combinators \code{opt} and \code{rep} can be
-defined in terms of the combinators for sequence and alternative:
-\begin{lstlisting}
-  def opt(p: Parser): Parser = p ||| empty;    // p? = (p | <empty>)
-  def rep(p: Parser): Parser = opt(rep1(p));   // p* = [p+]
-  def rep1(p: Parser): Parser = p &&& rep(p);  // p+ = p p*
-} // end Parser
-\end{lstlisting}
-To run combinator parsers, we still need to decide on a way to handle
-parser input. Several possibilities exist: The input could be
-represented as a list, as an array, or as a random access file.  Note
-that the presented combinator parsers use backtracking to change from
-one alternative to another.  Therefore, it must be possible to reset
-input to a point that was previously parsed. If one restricted the
-focus to LL(1) grammars, a non-backtracking implementation of the
-parser combinators in class \code{Parsers} would also be possible. In
-that case sequential input methods based on (say) iterators or
-sequential files would also be possible.
-
-In our example, we represent the input by a pair of a string, which
-contains the input phrase as a whole, and an index, which represents
-the portion of the input which has not yet been parsed. Since the
-input string does not change, just the index needs to be passed around
-as a result of individual parse steps.  This leads to the following
-class of parsers that read strings:
-\begin{lstlisting}
-class ParseString(s: String) extends Parsers {
-  type intype = int;
-  def chr(p: char => boolean) = new Parser {
-    def apply(in: int): Parser#Result = 
-      if (in < s.length() && p(s charAt in)) Some(in + 1);
-      else None;
-  }
-  val input = 0;
-}
-\end{lstlisting}
-This class implements a method \code{chr(p: char => boolean)} and a
-value \code{input}. The \code{chr} method builds a parser that either
-reads a single character satisfying the given predicate \code{p} or
-fails.  All other parsers over strings are ultimately implemented in
-terms of that method. The \code{input} value represents the input as a
-whole. In out case, it is simply value \code{0}, the start index of
-the string to be read.
-
-Note \code{apply}'s result type, \code{Parser#Result}. This syntax
-selects the type element \code{Result} of the type \code{Parser}. It
-thus corresponds roughly to selecting a static inner class from some
-outer class in Java. Note that we could {\em not} have written
-\code{Parser.Result}, as the latter would express selection of the
-\code{Result} element from a {\em value} named \code{Parser}.
-
-We have now extended the root class \code{Parsers} in two different
-directions: Class \code{ListParsers} defines a grammar of phrases to
-be parsed, whereas class \code{ParseString} defines a method by which
-such phrases are input. To write a concrete parsing application, we
-need to define both grammar and input method. We do this by combining
-two extensions of \code{Parsers} using a {\em mixin composition}.
-Here is the start of a sample application:
-\begin{lstlisting}
-object Test {
-  def main(args: Array[String]): unit = {
-    val ps = new ListParsers with ParseString(args(0));
-\end{lstlisting}
-The last line above creates a new family of parsers by composing class
-\code{ListParsers} with class \code{ParseString}. The two classes
-share the common superclass \code{Parsers}. The abstract method
-\code{chr} in \code{ListParsers} is implemented by class \code{ParseString}.
-
-To run the parser, we apply the start symbol of the grammar
-\code{expr} the argument code{input} and observe the result:
-\begin{lstlisting}
-    ps.expr(input) match { 
-      case Some(n) => 
-        System.out.println("parsed: " + args(0).substring(0, n)); 
-      case None =>
-        System.out.println("nothing parsed"); 
-    }
-  }
-}// end Test
-\end{lstlisting}
-Note the syntax ~\code{ps.expr(input)}, which treats the \code{expr}
-parser as if it was a function. In Scala, objects with \code{apply}
-methods can be applied directly to arguments as if they were functions.
-
-Here is an example run of the program above:
-\begin{lstlisting}
-> java examples.Test "(x,1,(y,z))"
-parsed: (x,1,(y,z))
-> java examples.Test "(x,,1,(y,z))"
-nothing parsed
-\end{lstlisting}
-
-\section{\label{sec:parsers-results}Parsers that Produce Results}
-
-The combinator library of the previous section does not support the
-generation of output from parsing. But usually one does not just want
-to check whether a given string belongs to the defined language, one
-also wants to convert the input string into some internal
-representation such as an abstract syntax tree.
-
-In this section, we modify our parser library to build parsers that
-produce results. We will make use of the for-comprehensions introduced
-in Chapter~\ref{sec:for-notation}.  The basic combinator of sequential
-composition, formerly ~\code{p &&& q}, now becomes
-\begin{lstlisting}
-for (val x <- p; val y <- q) yield e .
-\end{lstlisting}
-Here, the names \code{x} and \code{y} are bound to the results of
-executing the parsers \code{p} and \code{q}. \code{e} is an expression
-that uses these results to build the tree returned by the composed
-parser.
-
-Before describing the implementation of the new parser combinators, we
-explain how the new building blocks are used. Say we want to modify
-our list parser so that it returns an abstract syntax tree of the
-parsed expression. Syntax trees are given by the following class hierarchy:
-\begin{lstlisting}
-abstract class Tree{}
-case class Id (s: String)         extends Tree {}
-case class Num(n: int)            extends Tree {}
-case class Lst(elems: List[Tree]) extends Tree {}
-\end{lstlisting}
-That is, a syntax tree is an identifier, an integer number, or a
-\code{Lst} node with a list of trees as descendants.
-
-As a first step towards parsers that produce results we define three
-little parsers that return a single read character as result.
-\begin{lstlisting}
-abstract class CharParsers extends Parsers {
-  def any: Parser[char];
-  def chr(ch: char): Parser[char] = 
-    for (val c <- any; c == ch) yield c;
-  def chr(p: char => boolean): Parser[char] = 
-    for (val c <- any; p(c)) yield c;
-}
-\end{lstlisting}
-The \code{any} parser succeeds with the first character of remaining
-input as long as input is nonempty. It is abstract in class
-\code{ListParsers} since we want to abstract in this class from the
-concrete input method used.  The two \code{chr} parsers return as before
-the first input character if it equals a given character or matches a
-given predicate. They are now implemented in terms of \code{any}.
-
-The next level is represented by parsers reading identifiers, numbers
-and lists. Here is a parser for identifiers.
-\begin{lstlisting}
-abstract class ListParsers extends CharParsers {
-  def ident: Parser[Tree] = 
-    for (
-      val c: char <- chr(Character.isLetter); 
-      val cs: List[char] <- rep(chr(Character.isLetterOrDigit))
-    ) yield Id((c :: cs).mkString("", "", ""));
-\end{lstlisting}
-Remark: Because \code{chr(...)} returns a single character, its
-repetition \code{rep(chr(...))} returns a list of characters. The
-\code{yield} part of the for-comprehension converts all intermediate
-results into an \code{Id} node with a string as element.  To convert
-the read characters into a string, it conses them into a single list,
-and invokes the \code{mkString} method on the result.
-
-Here is a parser for numbers:
-\begin{lstlisting}
-  def number: Parser[Tree] =
-    for (
-      val d: char <- chr(Character.isDigit);
-      val ds: List[char] <- rep(chr(Character.isDigit))
-    ) yield Num(((d - '0') /: ds) ((x, digit) => x * 10 + digit - '0'));
-\end{lstlisting}
-Intermediate results are in this case the leading digit of
-the read number, followed by a list of remaining digits.  The
-\code{yield} part of the for-comprehension reduces these to a number
-by a fold-left operation.
-
-Here is a parser for lists:
-\begin{lstlisting}
-  def list: Parser[Tree] = 
-    for (
-      val _ <- chr('(');
-      val es <- listElems ||| succeed(List());
-      val _ <- chr(')')
-    ) yield Lst(es);
-
-  def listElems: Parser[List[Tree]] = 
-    for (
-      val x <- expr;
-      val xs <- chr(',') &&& listElems ||| succeed(List())
-    ) yield x :: xs;
-\end{lstlisting}
-The \code{list} parser returns a \code{Lst} node with a list of trees
-as elements.  That list is either the result of \code{listElems}, or,
-if that fails, the empty list (expressed here as: the result of a
-parser which always succeeds with the empty list as result).
-
-The highest level of our grammar is represented by function
-\code{expr}:
-\begin{lstlisting}
-  def expr: Parser[Tree] = 
-    ident ||| number ||| list
-}// end ListParsers.
-\end{lstlisting}
-We now present the parser combinators that support the new
-scheme. Parsers that succeed now return a parse result besides the
-un-consumed input.
-\begin{lstlisting}
-abstract class Parsers {
-  type intype;
-  trait Parser[a] {
-    type Result = Option[Pair[a, intype]];
-    def apply(in: intype): Result;
-\end{lstlisting}
-Parsers are parameterized with the type of their result. The class
-\code{Parser[a]} now defines new methods \code{map}, \code{flatMap}
-and \code{filter}. The \code{for} expressions are mapped by the
-compiler to calls of these functions using the scheme described in
-Chapter~\ref{sec:for-notation}. For parsers, these methods are
-implemented as follows.
-\begin{lstlisting}
-    def filter(pred: a => boolean) = new Parser[a] {
-      def apply(in: intype): Result = Parser.this.apply(in) match {
-        case None => None
-        case Some(Pair(x, in1)) => if (pred(x)) Some(Pair(x, in1)) else None
-      }
-    }
-    def map[b](f: a => b) = new Parser[b] {
-      def apply(in: intype): Result = Parser.this.apply(in) match {
-        case None => None
-        case Some(Pair(x, in1)) => Some(Pair(f(x), in1))
-      }
-    }
-    def flatMap[b](f: a => Parser[b]) = new Parser[b] {
-      def apply(in: intype): Result = Parser.this.apply(in) match {
-        case None => None
-        case Some(Pair(x, in1)) => f(x).apply(in1)
-      }
-    }
-\end{lstlisting}
-The \code{filter} method takes as parameter a predicate $p$ which it
-applies to the results of the current parser. If the predicate is
-false, the parser fails by returning \code{None}; otherwise it returns
-the result of the current parser.  The \code{map} method takes as
-parameter a function $f$ which it applies to the results of the
-current parser. The \code{flatMap} takes as parameter a function
-\code{f} which returns a parser.  It applies \code{f} to the result of
-the current parser and then continues with the resulting parser.  The
-\code{|||} method is essentially defined as before.  The
-\code{&&&} method can now be defined in terms of \code{for}.
-\begin{lstlisting}
-    def ||| (p: => Parser[a]) = new Parser[a] {
-      def apply(in: intype): Result = Parser.this.apply(in) match {
-        case None => p(in)
-        case s => s
-      }
-    }
-
-    def &&& [b](p: => Parser[b]): Parser[b] = 
-      for (val _ <- this; val x <- p) yield x;
-  }// end Parser
-\end{lstlisting}
-
-The primitive parser \code{succeed} replaces \code{empty}. It consumes
-no input and returns its parameter as result.
-\begin{lstlisting}
-  def succeed[a](x: a) = new Parser[a] {
-    def apply(in: intype) = Some(Pair(x, in))
-  }
-\end{lstlisting}
-
-The parser combinators \code{rep} and \code{opt} now also return
-results. \code{rep} returns a list which contains as elements the
-results of each iteration of its sub-parser. \code{opt} returns a list
-which is either empty or returns as single element the result of the
-optional parser.
-\begin{lstlisting}
-  def rep[a](p: Parser[a]): Parser[List[a]] =
-    rep1(p) ||| succeed(List());
-
-  def rep1[a](p: Parser[a]): Parser[List[a]] =
-    for (val x <- p; val xs <- rep(p)) yield x :: xs;
-
-  def opt[a](p: Parser[a]): Parser[List[a]] =
-    (for (val x <- p) yield List(x)) ||| succeed(List());
-} // end Parsers
-\end{lstlisting}
-The root class \code{Parsers} abstracts over which kind of
-input is parsed.  As before, we determine the input method by a separate class.
-Here is \code{ParseString}, this time adapted to parsers that return results.
-It defines now the method \code{any}, which returns the first input character.
-\begin{lstlisting}
-class ParseString(s: String) extends Parsers {
-  type intype = int;
-  val input = 0;
-  def any = new Parser[char] {
-    def apply(in: int): Parser[char]#Result =
-      if (in < s.length()) Some(Pair(s charAt in, in + 1)) else None;
-  }
-}
-\end{lstlisting}
-The rest of the application is as before. Here is a test program which
-constructs a list parser over strings and prints out the result of
-applying it to the command line argument.
-\begin{lstlisting}
-object Test {
-  def main(args: Array[String]): unit = {
-    val ps = new ListParsers with ParseString(args(0));
-    ps.expr(ps.input) match {
-      case Some(Pair(list, _)) => System.out.println("parsed: " + list);
-      case None => "nothing parsed"
-    }
-  }
-}
-\end{lstlisting}
-
-\begin{exercise}\label{exercise:end-marker} The parsers we have defined so
-far can succeed even if there is some input beyond the parsed text. To
-prevent this, one needs a parser which recognizes the end of input.
-Redesign the parser library so that such a parser can be introduced.
-Which classes need to be modified?
-\end{exercise}
-
-\chapter{\label{sec:hm}Hindley/Milner Type Inference}
-
-This chapter demonstrates Scala's data types and pattern matching by
-developing a type inference system in the Hindley/Milner style
-\cite{milner:polymorphism}. The source language for the type inferencer is
-lambda calculus with a let construct called Mini-ML. Abstract syntax
-trees for the Mini-ML are represented by the following data type of
-\code{Terms}.
-\begin{lstlisting}
-trait Term {}
-case class Var(x: String) extends Term {
-  override def toString() = x;
-}
-case class Lam(x: String, e: Term) extends Term {
-  override def toString() = "(\\" + x + "." + e + ")";
-}
-case class App(f: Term, e: Term) extends Term {
-  override def toString() = "(" + f + " " + e + ")";
-}
-case class Let(x: String, e: Term, f: Term) extends Term {
-  override def toString() = "let " + x + " = " + e + " in " + f;
-}
-\end{lstlisting}
-There are four tree constructors: \code{Var} for variables, \code{Lam}
-for function abstractions, \code{App} for function applications, and
-\code{Let} for let expressions. Each case class overrides the
-\code{toString()} method of class \code{Any}, so that terms can be
-printed in legible form.
-
-We next define the types that are
-computed by the inference system.
-\begin{lstlisting}
-sealed trait Type {}
-case class Tyvar(a: String) extends Type {
-  override def toString() = a;
-}
-case class Arrow(t1: Type, t2: Type) extends Type {
-  override def toString() = "(" + t1 + "->" + t2 + ")";
-}
-case class Tycon(k: String, ts: List[Type]) extends Type {
-  override def toString() = 
-    k + (if (ts.isEmpty) "" else ts.mkString("[", ",", "]"));
-}
-\end{lstlisting}
-There are three type constructors: \code{Tyvar} for type variables,
-\code{Arrow} for function types and \code{Tycon} for type constructors
-such as \code{boolean} or \code{List}. Type constructors have as
-component a list of their type parameters. This list is empty for type
-constants such as \code{boolean}. Again, the type constructors
-implement the \code{toString} method in order to display types legibly.
-
-Note that \code{Type} is a \code{sealed} class. This means that no
-subclasses or data constructors that extend \code{Type} can be formed
-outside the sequence of definitions in which \code{Type} is defined.
-This makes \code{Type} a {\em closed} algebraic data type with exactly
-three alternatives. By contrast, type \code{Term} is an {\em open}
-algebraic type for which further alternatives can be defined.
-
-The main parts of the type inferencer are contained in object
-\code{typeInfer}. We start with a utility function which creates
-fresh type variables:
-\begin{lstlisting}
-object typeInfer {
-  private var n: Int = 0;
-  def newTyvar(): Type = { n = n + 1 ; Tyvar("a" + n) }
-\end{lstlisting}
-We next define a class for substitutions. A substitution is an
-idempotent function from type variables to types. It maps a finite
-number of type variables to some types, and leaves all other type
-variables unchanged. The meaning of a substitution is extended
-point-wise to a mapping from types to types.
-\begin{lstlisting}
-  trait Subst extends Any with Function1[Type,Type] {
-
-    def lookup(x: Tyvar): Type;
-
-    def apply(t: Type): Type = t match {
-      case tv @ Tyvar(a) => val u = lookup(tv); if (t == u) t else apply(u); 
-      case Arrow(t1, t2) => Arrow(apply(t1), apply(t2))
-      case Tycon(k, ts) => Tycon(k, ts map apply)
-    }
-
-    def extend(x: Tyvar, t: Type) = new Subst {
-      def lookup(y: Tyvar): Type = if (x == y) t else Subst.this.lookup(y);
-    }
-  }
-  val emptySubst = new Subst { def lookup(t: Tyvar): Type = t }
-\end{lstlisting}
-We represent substitutions as functions, of type \code{Type =>
-Type}. This is achieved by making class \code{Subst} inherit from the
-unary function type \code{Function1[Type, Type]}\footnote{
-The class inherits the function type as a mixin rather than as a direct 
-superclass. This is because in the current Scala implementation, the
-\code{Function1} type is a Java interface, which cannot be used as a direct
-superclass of some other class.}.
-To be an instance
-of this type, a substitution \code{s} has to implement an \code{apply}
-method that takes a \code{Type} as argument and yields another
-\code{Type} as result. A function application \code{s(t)} is then
-interpreted as \code{s.apply(t)}.
-
-The \code{lookup} method is abstract in class \code{Subst}.  There are
-two concrete forms of substitutions which differ in how they
-implement this method.  One form is defined by the \code{emptySubst} value,
-the other is defined by the \code{extend} method in class
-\code{Subst}.
-
-The next data type describes type schemes, which consist of a type and
-a list of names of type variables which appear universally quantified
-in the type scheme. 
-For instance, the type scheme $\forall a\forall b.a \!\arrow\! b$ would be represented in the type checker as:
-\begin{lstlisting}
-TypeScheme(List(TyVar("a"), TyVar("b")), Arrow(Tyvar("a"), Tyvar("b"))) .
-\end{lstlisting}
-The class definition of type schemes does not carry an extends
-clause; this means that type schemes extend directly class
-\code{AnyRef}.  Even though there is only one possible way to
-construct a type scheme, a case class representation was chosen
-since it offers convenient ways to decompose an instance of this type into its
-parts.
-\begin{lstlisting}
-case class TypeScheme(tyvars: List[String], tpe: Type) {
-  def newInstance: Type = {
-    (emptySubst /: tyvars) ((s, tv) => s.extend(tv, newTyvar())) (tpe);
-  }
-}
-\end{lstlisting}
-Type scheme objects come with a method \code{newInstance}, which
-returns the type contained in the scheme after all universally type
-variables have been renamed to fresh variables. The implementation of
-this method folds (with \code{/:}) the type scheme's type variables
-with an operation which extends a given substitution \code{s} by
-renaming a given type variable \code{tv} to a fresh type
-variable. The resulting substitution renames all type variables of the
-scheme to fresh ones. This substitution is then applied to the type
-part of the type scheme.
-
-The last type we need in the type inferencer is
-\code{Env}, a type for environments, which associate variable names
-with type schemes. They are represented by a type alias \code{Env} in
-module \code{typeInfer}:
-\begin{lstlisting}
-type Env = List[Pair[String, TypeScheme]];
-\end{lstlisting}
-There are two operations on environments. The \code{lookup} function
-returns the type scheme associated with a given name, or \code{null}
-if the name is not recorded in the environment.
-\begin{lstlisting}
-  def lookup(env: Env, x: String): TypeScheme = env match {
-    case List() => null
-    case Pair(y, t) :: env1 => if (x == y) t else lookup(env1, x)
-  }
-\end{lstlisting}
-The \code{gen} function turns a given type into a type scheme,
-quantifying over all type variables that are free in the type, but
-not in the environment.
-\begin{lstlisting}
-  def gen(env: Env, t: Type): TypeScheme = 
-    TypeScheme(tyvars(t) diff tyvars(env), t);
-\end{lstlisting}
-The set of free type variables of a type is simply the set of all type
-variables which occur in the type. It is represented here as a list of
-type variables, which is constructed as follows.
-\begin{lstlisting}
-  def tyvars(t: Type): List[Tyvar] = t match {
-    case tv @ Tyvar(a) => 
-      List(tv)
-    case Arrow(t1, t2) => 
-      tyvars(t1) union tyvars(t2)
-    case Tycon(k, ts) => 
-      (List[Tyvar]() /: ts) ((tvs, t) => tvs union tyvars(t));
-  }
-\end{lstlisting}
-Note that the syntax \code{tv @ ...} in the first pattern introduces a variable
-which is bound to the pattern that follows. Note also that the explicit type parameter \code{[Tyvar]} in the expression of the third
-clause is needed to make local type inference work.
-
-The set of free type variables of a type scheme is the set of free
-type variables of its type component, excluding any quantified type variables:
-\begin{lstlisting}
-  def tyvars(ts: TypeScheme): List[Tyvar] = 
-    tyvars(ts.tpe) diff ts.tyvars;
-\end{lstlisting}
-Finally, the set of free type variables of an environment is the union
-of the free type variables of all type schemes recorded in it.
-\begin{lstlisting}
-  def tyvars(env: Env): List[Tyvar] =
-    (List[Tyvar]() /: env) ((tvs, nt) => tvs union tyvars(nt._2));
-\end{lstlisting}
-A central operation of Hindley/Milner type checking is unification,
-which computes a substitution to make two given types equal (such a
-substitution is called a {\em unifier}).  Function \code{mgu} computes
-the most general unifier of two given types $t$ and $u$ under a
-pre-existing substitution $s$.  That is, it returns the most general
-substitution $s'$ which extends $s$, and which makes $s'(t)$ and
-$s'(u)$ equal types. 
-\begin{lstlisting}
-  def mgu(t: Type, u: Type, s: Subst): Subst = Pair(s(t), s(u)) match {
-    case Pair(Tyvar(a), Tyvar(b)) if (a == b) => 
-      s
-    case Pair(Tyvar(a), _) if !(tyvars(u) contains a) =>
-      s.extend(Tyvar(a), u)
-    case Pair(_, Tyvar(a)) =>
-      mgu(u, t, s)
-    case Pair(Arrow(t1, t2), Arrow(u1, u2)) =>
-      mgu(t1, u1, mgu(t2, u2, s))
-    case Pair(Tycon(k1, ts), Tycon(k2, us)) if (k1 == k2) =>
-      (s /: (ts zip us)) ((s, tu) => mgu(tu._1, tu._2, s))
-    case _ => 
-      throw new TypeError("cannot unify " + s(t) + " with " + s(u))
-  }
-\end{lstlisting}
-The \code{mgu} function throws a \code{TypeError} exception if no
-unifier substitution exists. This can happen because the two types
-have different type constructors at corresponding places, or because a
-type variable is unified with a type that contains the type variable
-itself. Such exceptions are modeled here as instances of case classes
-that inherit from the predefined \code{Exception} class.
-\begin{lstlisting}
-  case class TypeError(s: String) extends Exception(s) {}
-\end{lstlisting}
-The main task of the type checker is implemented by function
-\code{tp}. This function takes as parameters an environment $env$, a
-term $e$, a proto-type $t$, and a
-pre-existing substitution $s$.  The function yields a substitution
-$s'$ that extends $s$ and that
-turns $s'(env) \ts e: s'(t)$ into a derivable type judgment according
-to the derivation rules of the Hindley/Milner type system \cite{milner:polymorphism}.  A
-\code{TypeError} exception is thrown if no such substitution exists.
-\begin{lstlisting}
-  def tp(env: Env, e: Term, t: Type, s: Subst): Subst = {
-    current = e;
-    e match {
-      case Var(x) =>
-        val u = lookup(env, x);
-        if (u == null) throw new TypeError("undefined: " + x);
-        else mgu(u.newInstance, t, s)
-
-      case Lam(x, e1) =>
-        val a = newTyvar(), b = newTyvar();
-        val s1 = mgu(t, Arrow(a, b), s);
-        val env1 = Pair(x, TypeScheme(List(), a)) :: env;
-        tp(env1, e1, b, s1)
-
-      case App(e1, e2) =>
-        val a = newTyvar();
-        val s1 = tp(env, e1, Arrow(a, t), s);
-        tp(env, e2, a, s1)
-
-      case Let(x, e1, e2) =>
-        val a = newTyvar();
-        val s1 = tp(env, e1, a, s);
-        tp(Pair(x, gen(env, s1(a))) :: env, e2, t, s1)
-    }
-  } 
-  var current: Term = null;
-\end{lstlisting}
-To aid error diagnostics, the \code{tp} function stores the currently
-analyzed sub-term in variable \code{current}. Thus, if type checking
-is aborted with a \code{TypeError} exception, this variable will
-contain the subterm that caused the problem.
-
-The last function of the type inference module, \code{typeOf}, is a
-simplified facade for \code{tp}. It computes the type of a given term
-$e$ in a given environment $env$. It does so by creating a fresh type
-variable $a$, computing a typing substitution that makes $env \ts e: a$
-into a derivable type judgment, and returning
-the result of applying the substitution to $a$.
-\begin{lstlisting}
-  def typeOf(env: Env, e: Term): Type = {
-    val a = newTyvar();
-    tp(env, e, a, emptySubst)(a)
-  }
-}// end typeInfer
-\end{lstlisting}
-To apply the type inferencer, it is convenient to have a predefined
-environment that contains bindings for commonly used constants. The
-module \code{predefined} defines an environment \code{env} that
-contains bindings for the types of booleans, numbers and lists
-together with some primitive operations over them. It also
-defines a fixed point operator \code{fix}, which can be used to
-represent recursion.
-\begin{lstlisting}
-object predefined {
-  val booleanType = Tycon("Boolean", List());
-  val intType = Tycon("Int", List());
-  def listType(t: Type) = Tycon("List", List(t));
-
-  private def gen(t: Type): typeInfer.TypeScheme = typeInfer.gen(List(), t);
-  private val a = typeInfer.newTyvar();
-  val env = List(
-    Pair("true", gen(booleanType)),
-    Pair("false", gen(booleanType)),
-    Pair("if", gen(Arrow(booleanType, Arrow(a, Arrow(a, a))))),
-    Pair("zero", gen(intType)),
-    Pair("succ", gen(Arrow(intType, intType))),
-    Pair("nil", gen(listType(a))),
-    Pair("cons", gen(Arrow(a, Arrow(listType(a), listType(a))))),
-    Pair("isEmpty", gen(Arrow(listType(a), booleanType))),
-    Pair("head", gen(Arrow(listType(a), a))),
-    Pair("tail", gen(Arrow(listType(a), listType(a)))),
-    Pair("fix", gen(Arrow(Arrow(a, a), a)))
-  )
-}
-\end{lstlisting}
-Here's an example how the type inferencer can be used.
-Let's define a function \code{showType} which returns the type of
-a given term computed in the predefined environment
-\code{Predefined.env}:
-\begin{lstlisting}
-object testInfer {
-  def showType(e: Term): String =
-    try {
-      typeInfer.typeOf(predefined.env, e).toString();
-    } catch {
-      case typeInfer.TypeError(msg) => 
-        "\n cannot type: " + typeInfer.current +
-        "\n reason: " + msg;
-    }
-\end{lstlisting}
-Then the application
-\begin{lstlisting}
-> testInfer.showType(Lam("x", App(App(Var("cons"), Var("x")), Var("nil"))));
-\end{lstlisting}
-would give the response
-\begin{lstlisting}
-> (a6->List[a6])
-\end{lstlisting}
-To make the type inferencer more useful, we complete it with a
-parser. 
-Function \code{main} of module \code{testInfer}
-parses and typechecks a Mini-ML expression which is given as the first
-command line argument.
-\begin{lstlisting}
-  def main(args: Array[String]): unit = {
-    val ps = new MiniMLParsers with ParseString(args(0));
-    ps.all(ps.input) match {
-      case Some(Pair(term, _)) => 
-        System.out.println("" + term + ": " + showType(term));
-      case None =>
-        System.out.println("syntax error");
-    }
-  }
-}// typeInf
-\end{lstlisting}
-To do the parsing, method \code{main} uses the combinator parser
-scheme of Chapter~\ref{sec:combinator-parsing}. It creates a parser
-family \code{ps} as a mixin composition of parsers
-that understand MiniML (but do not know where input comes from) and
-parsers that read input from a given string.  The \code{MiniMLParsers}
-object implements parsers for the following grammar.
-\begin{lstlisting}
-term  ::= "\" ident "." term
-       |  term1 {term1}
-       |  "let" ident "=" term "in" term
-term1 ::= ident
-       |  "(" term ")"
-all   ::= term ";"
-\end{lstlisting}
-Input as a whole is described by the production \code{all}; it
-consists of a term followed by a semicolon. We allow ``whitespace''
-consisting of one or more space, tabulator or newline characters
-between any two lexemes (this is not reflected in the grammar
-above). Identifiers are defined as in
-Chapter~\ref{sec:combinator-parsing} except that an identifier cannot
-be one of the two reserved words "let" and "in".
-\begin{lstlisting}
-abstract class MiniMLParsers[intype] extends CharParsers[intype] {
-
-  /** whitespace */
-  def whitespace = rep{chr(' ') ||| chr('\t') ||| chr('\n')};
-
-  /** A given character, possible preceded by whitespace */
-  def wschr(ch: char) = whitespace &&& chr(ch);
-
-  /** identifiers or keywords */
-  def id: Parser[String] = 
-    for (
-      val c: char <- whitespace &&& chr(Character.isLetter); 
-      val cs: List[char] <- rep(chr(Character.isLetterOrDigit))
-    ) yield (c :: cs).mkString("", "", "");
-
-  /** Non-keyword identifiers */
-  def ident: Parser[String] =
-    for (val s <- id; s != "let" && s != "in") yield s;
-
-  /** term = '\' ident '.' term | term1 {term1} | let ident "=" term in term */
-  def term: Parser[Term] =
-    ( for (
-        val _ <- wschr('\\');
-        val x <- ident;
-        val _ <- wschr('.');
-        val t <- term)
-      yield Lam(x, t): Term )
-    |||
-    ( for (
-        val letid <- id; letid == "let"; 
-        val x <- ident; 
-        val _ <- wschr('='); 
-        val t <- term; 
-        val inid <- id; inid == "in"; 
-        val c <- term)
-      yield Let(x, t, c) )
-    |||
-    ( for (
-        val t <- term1;
-        val ts <- rep(term1))
-      yield (t /: ts)((f, arg) => App(f, arg)) );
-
-  /** term1 = ident | '(' term ')' */
-  def term1: Parser[Term] = 
-    ( for (val s <- ident)
-      yield Var(s): Term )
-    |||
-    ( for (
-        val _ <- wschr('(');
-        val t <- term;
-        val _ <- wschr(')'))
-      yield t );
-
-  /** all = term ';' */
-  def all: Parser[Term] = 
-    for (
-      val t <- term;
-      val _ <- wschr(';'))
-    yield t;
-}
-\end{lstlisting}
-Here are some sample MiniML programs and the output the type inferencer gives for each of them:
-\begin{lstlisting}
-> java testInfer
-| "\x.\f.f(f x);"
-(\x.(\f.(f (f x)))): (a8->((a8->a8)->a8))
-
-> java testInfer 
-| "let id = \x.x  
-|  in if (id true) (id nil) (id (cons zero nil));"
-let id = (\x.x) in (((if (id true)) (id nil)) (id ((cons zero) nil))): List[Int]
-
-> java testInfer
-| "let id = \x.x 
-|  in if (id true) (id nil);"
-let id = (\x.x) in ((if (id true)) (id nil)): (List[a13]->List[a13])
-
-> java testInfer
-| "let length = fix (\len.\xs.
-|    if (isEmpty xs) 
-|      zero 
-|      (succ (len (tail xs))))
-|  in (length nil);"
-let length = (fix (\len.(\xs.(((if (isEmpty xs)) zero) 
-(succ (len (tail xs))))))) in (length nil): Int
-
-> java testInfer 
-| "let id = \x.x 
-|  in if (id true) (id nil) zero;"
-let id = (\x.x) in (((if (id true)) (id nil)) zero): 
- cannot type: zero
- reason: cannot unify Int with List[a14]
-\end{lstlisting}
-
-\begin{exercise}\label{exercise:hm-parse} Using the parser library constructed in
-Exercise~\ref{exercise:end-marker}, modify the MiniML parser library
-so that no marker ``;'' is necessary for indicating the end of input.
-\end{exercise}
-
-\begin{exercise}\label{execcise:hm-extend} Extend the Mini-ML parser and type
-inferencer with a \code{letrec} construct which allows the definition of
-recursive functions. Syntax:
-\begin{lstlisting}
-letrec ident "=" term in term .
-\end{lstlisting}
-The typing of \code{letrec} is as for \code{let}, 
-except that the defined identifier is visible in the defining expression. Using \code{letrec}, the \code{length} function for lists can now be defined as follows.
-\begin{lstlisting}
-letrec length = \xs.
-  if (isEmpty xs)
-    zero
-    (succ (length (tail xs)))
-in ...
-\end{lstlisting}
-\end{exercise}
-
-\chapter{Abstractions for Concurrency}\label{sec:ex-concurrency}
-
-This section reviews common concurrent programming patterns and shows
-how they can be implemented in Scala.
-
-\section{Signals and Monitors}
-
-\example
-The {\em monitor} provides the basic means for mutual exclusion
-of processes in Scala. Every instance of class \code{AnyRef} can be
-used as a monitor by calling one or more of the methods below.
-\begin{lstlisting}
-  def synchronized[a] (e: => a): a;
-  def wait(): unit;
-  def wait(msec: long): unit;
-  def notify(): unit;
-  def notifyAll(): unit;
-\end{lstlisting}
-The \code{synchronized} method executes its argument computation
-\code{e} in mutual exclusive mode -- at any one time, only one thread
-can execute a \code{synchronized} argument of a given monitor.
-
-Threads can suspend inside a monitor by waiting on a signal.  Threads
-that call the \code{wait} method wait until a \code{notify} method of
-the same object is called subsequently by some other thread. Calls to
-\code{notify} with no threads waiting for the signal are ignored.
-
-There is also a timed form of \code{wait}, which blocks only as long
-as no signal was received or the specified amount of time (given in
-milliseconds) has elapsed. Furthermore, there is a \code{notifyAll}
-method which unblocks all threads which wait for the signal.  These
-methods, as well as class \code{Monitor} are primitive in Scala; they
-are implemented in terms of the underlying runtime system.
-
-Typically, a thread waits for some condition to be established. If the
-condition does not hold at the time of the wait call, the thread
-blocks until some other thread has established the condition. It is
-the responsibility of this other thread to wake up waiting processes
-by issuing a \code{notify} or \code{notifyAll}. Note however, that
-there is no guarantee that a waiting process gets to run immediately
-after the call to notify is issued. It could be that other processes
-get to run first which invalidate the condition again. Therefore, the
-correct form of waiting for a condition $C$ uses a while loop:
-\begin{lstlisting}
-while (!$C$) wait();
-\end{lstlisting}
-
-As an example of how monitors are used, here is is an implementation
-of a bounded buffer class.
-\begin{lstlisting}
-class BoundedBuffer[a](N: Int) {
-  var in = 0, out = 0, n = 0;
-  val elems = new Array[a](N);
-
-  def put(x: a) = synchronized {
-    while (n >= N) wait();
-    elems(in) = x ; in = (in + 1) % N ; n = n + 1;
-    if (n == 1) notifyAll();
-  }
-
-  def get: a = synchronized {
-    while (n == 0) wait();
-    val x = elems(out) ; out = (out + 1) % N ; n = n - 1;
-    if (n == N - 1) notifyAll();
-    x
-  }
-}
-\end{lstlisting}
-And here is a program using a bounded buffer to communicate between a
-producer and a consumer process.
-\begin{lstlisting}
-import scala.concurrent.ops._;
-...
-val buf = new BoundedBuffer[String](10);
-spawn { while (true) { val s = produceString ; buf.put(s) } }
-spawn { while (true) { val s = buf.get ; consumeString(s) } }
-}
-\end{lstlisting}
-The \code{spawn} method spawns a new thread which executes the
-expression given in the parameter. It is defined in object \code{concurrent.ops}
-as follows.
-\begin{lstlisting}
-def spawn(p: => unit) = {
-  val t = new Thread() { override def run() = p; }
-  t.start()
-}
-\end{lstlisting}
-
-\comment{
-\section{Logic Variable}
-
-A logic variable (or lvar for short) offers operations \code{:=}
-and \code{value} to define the variable and to retrieve its value.
-Variables can be \code{define}d only once. A call to \code{value}
-blocks until the variable has been defined.
-
-Logic variables can be implemented as follows.
-
-\begin{lstlisting}
-class LVar[a] {
-  private val defined = new Signal
-  private var isDefined: boolean = false
-  private var v: a
-  def value = synchronized {
-    if (!isDefined) defined.wait
-    v
-  }
-  def :=(x: a) = synchronized {
-    v = x ; isDefined = true ; defined.send
-  }
-}
-\end{lstlisting}
-}
-
-\section{SyncVars}
-
-A synchronized variable (or syncvar for short) offers \code{get} and
-\code{put} operations to read and set the variable. \code{get} operations
-block until the variable has been defined. An \code{unset} operation
-resets the variable to undefined state.
-
-Here's the standard implementation of synchronized variables.
-\begin{lstlisting}
-package scala.concurrent;
-class SyncVar[a] {
-  private var isDefined: Boolean = false;
-  private var value: a = _;
-  def get = synchronized {
-    if (!isDefined) wait();
-    value
-  }
-  def set(x: a) = synchronized {
-    value = x ; isDefined = true ; notifyAll();
-  }
-  def isSet: Boolean = synchronized {
-    isDefined;
-  }
-  def unset = synchronized { 
-    isDefined = false; 
-  }
-}
-\end{lstlisting}
-
-\section{Futures}
-\label{sec:futures}
-
-A {\em future} is a value which is computed in parallel to some other
-client thread, to be used by the client thread at some future time.
-Futures are used in order to make good use of parallel processing
-resources.  A typical usage is:
-
-\begin{lstlisting}
-import scala.concurrent.ops._;
-...
-val x = future(someLengthyComputation);
-anotherLengthyComputation;
-val y = f(x()) + g(x());
-\end{lstlisting}
-
-The \code{future} method is defined in object
-\code{scala.concurrent.ops} as follows.
-\begin{lstlisting}
-def future[a](p: => a): unit => a = {
-  val result = new SyncVar[a];
-  fork { result.set(p) }
-  (() => result.get)
-}
-\end{lstlisting}
-
-The \code{future} method gets as parameter a computation \code{p} to
-be performed. The type of the computation is arbitrary; it is
-represented by \code{future}'s type parameter \code{a}.  The
-\code{future} method defines a guard \code{result}, which takes a
-parameter representing the result of the computation. It then forks
-off a new thread that computes the result and invokes the
-\code{result} guard when it is finished. In parallel to this thread,
-the function returns an anonymous function of type \code{a}.
-When called, this functions waits on the result guard to be
-invoked, and, once this happens returns the result argument.
-At the same time, the function reinvokes the \code{result} guard with
-the same argument, so that future invocations of the function can
-return the result immediately.
-
-\section{Parallel Computations}
-
-The next example presents a function \code{par} which takes a pair of
-computations as parameters and which returns the results of the computations
-in another pair. The two computations are performed in parallel.
-
-The function is defined in object
-\code{scala.concurrent.ops} as follows.
-\begin{lstlisting}
-  def par[a, b](xp: => a, yp: => b): Pair[a, b] = {
-    val y = new SyncVar[b];
-    spawn { y set yp }
-    Pair(xp, y.get)
-  }
-\end{lstlisting}
-Defined in the same place is a function \code{replicate} which performs a
-number of replicates of a computation in parallel. Each
-replication instance is passed an integer number which identifies it.
-\begin{lstlisting}
-  def replicate(start: Int, end: Int)(p: Int => Unit): Unit = {
-    if (start == end) 
-      ()
-    else if (start + 1 == end)
-      p(start)
-    else {
-      val mid = (start + end) / 2;
-      spawn { replicate(start, mid)(p) }
-      replicate(mid, end)(p)
-    }
-  }
-\end{lstlisting}
-
-The next function uses \code{replicate} to perform parallel
-computations on all elements of an array.
-
-\begin{lstlisting}
-def parMap[a,b](f: a => b, xs: Array[a]): Array[b] = {
-  val results = new Array[b](xs.length);
-  replicate(0, xs.length) { i => results(i) = f(xs(i)) }
-  results
-}
-\end{lstlisting}
-
-\section{Semaphores}
-
-A common mechanism for process synchronization is a {\em lock} (or:
-{\em semaphore}). A lock offers two atomic actions: \prog{acquire} and
-\prog{release}. Here's the implementation of a lock in Scala:
-
-\begin{lstlisting}
-package scala.concurrent;
-
-class Lock {
-  var available = true;
-  def acquire = synchronized {
-    if (!available) wait();
-    available = false
-  }
-  def release = synchronized {
-    available = true;
-    notify()
-  }
-}
-\end{lstlisting}
-
-\section{Readers/Writers}
-
-A more complex form of synchronization distinguishes between {\em
-readers} which access a common resource without modifying it and {\em
-writers} which can both access and modify it. To synchronize readers
-and writers we need to implement operations \prog{startRead}, \prog{startWrite},
-\prog{endRead}, \prog{endWrite}, such that:
-\begin{itemize}
-\item there can be multiple concurrent readers,
-\item there can only be one writer at one time,
-\item pending write requests have priority over pending read requests,
-but don't preempt ongoing read operations.
-\end{itemize}
-The following implementation of a readers/writers lock is based on the
-{\em mailbox} concept (see Section~\ref{sec:mailbox}).
-
-\begin{lstlisting}
-import scala.concurrent._;
-
-class ReadersWriters {
-  val m = new MailBox;
-  private case class Writers(n: int), Readers(n: int) { m send this; };
-  Writers(0); Readers(0);
-  def startRead = m receive {
-    case Writers(n) if n == 0 => m receive {
-      case Readers(n) => Writers(0) ; Readers(n+1);
-    }
-  }
-  def startWrite = m receive {
-    case Writers(n) =>
-      Writers(n+1);
-      m receive { case Readers(n) if n == 0 => }
-  }
-  def endRead = m receive {
-    case Readers(n) => Readers(n-1)
-  }
-  def endWrite = m receive {
-    case Writers(n) => Writers(n-1) ; if (n == 0) Readers(0)
-  }
-}
-\end{lstlisting}
-
-\section{Asynchronous Channels}
-
-A fundamental way of interprocess communication is the asynchronous
-channel. Its implementation makes use the following simple class for linked
-lists:
-\begin{lstlisting}
-class LinkedList[a] {
-  var elem: a = _;
-  var next: LinkedList[a] = null;
-}
-\end{lstlisting}
-To facilitate insertion and deletion of elements into linked lists,
-every reference into a linked list points to the node which precedes
-the node which conceptually forms the top of the list.
-Empty linked lists start with a dummy node, whose successor is \code{null}.
-
-The channel class uses a linked list to store data that has been sent
-but not read yet. At the opposite end, threads that
-wish to read from an empty channel, register their presence by
-incrementing the \code{nreaders} field and waiting to be notified.
-\begin{lstlisting}
-package scala.concurrent;
-
-class Channel[a] {
-  class LinkedList[a] {
-    var elem: a = _;
-    var next: LinkedList[a] = null;
-  }
-  private var written = new LinkedList[a];
-  private var lastWritten = written;
-  private var nreaders = 0;
-
-  def write(x: a) = synchronized {
-    lastWritten.elem = x;
-    lastWritten.next = new LinkedList[a];
-    lastWritten = lastWritten.next;
-    if (nreaders > 0) notify();
-  }
-
-  def read: a = synchronized {
-    if (written.next == null) {
-      nreaders = nreaders + 1; wait(); nreaders = nreaders - 1;
-    }
-    val x = written.elem;
-    written = written.next;
-    x
-  }
-}
-\end{lstlisting}
-
-\section{Synchronous Channels}
-
-Here's an implementation of synchronous channels, where the sender of
-a message blocks until that message has been received. Synchronous
-channels only need a single variable to store messages in transit, but
-three signals are used to coordinate reader and writer processes.
-\begin{lstlisting}
-package scala.concurrent;
-
-class SyncChannel[a] {
-  private var data: a = _;
-  private var reading = false;
-  private var writing = false;
-
-  def write(x: a) = synchronized {
-    while (writing) wait();
-    data = x;
-    writing = true;
-    if (reading) notifyAll();
-    else while (!reading) wait();
-  }
-
-  def read: a = synchronized {
-    while (reading) wait();
-    reading = true;
-    while (!writing) wait();
-    val x = data;
-    writing = false;
-    reading = false;
-    notifyAll();
-    x
-  }
-}
-\end{lstlisting}
-
-\section{Workers}
-
-Here's an implementation of a {\em compute server} in Scala. The
-server implements a \code{future} method which evaluates a given
-expression in parallel with its caller. Unlike the implementation in
-Section~\ref{sec:futures} the server computes futures only with a
-predefined number of threads. A possible implementation of the server
-could run each thread on a separate processor, and could hence avoid
-the overhead inherent in context-switching several threads on a single
-processor.
-
-\begin{lstlisting}
-import scala.concurrent._, scala.concurrent.ops._;
-
-class ComputeServer(n: Int) {
-
-  private trait Job {
-    type t;
-    def task: t;
-    def ret(x: t): Unit;
-  }
-
-  private val openJobs = new Channel[Job]();
-
-  private def processor(i: Int): Unit = {
-    while (true) {
-      val job = openJobs.read;
-      job.ret(job.task) 
-    }
-  }
-
-  def future[a](p: => a): () => a = {
-    val reply = new SyncVar[a]();
-    openJobs.write{
-      new Job { 
-        type t = a;
-        def task = p;
-        def ret(x: a) = reply.set(x);
-      }
-    }
-    () => reply.get
-  }
-
-  spawn(replicate(0, n) { processor })
-}
-\end{lstlisting}
-Expressions to be computed (i.e. arguments
-to calls of \code{future}) are written to the \code{openJobs}
-channel. A {\em job} is an object with
-\begin{itemize}
-\item
-An abstract type \code{t} which describes the result of the compute
-job.
-\item
-A parameterless \code{task} method of type \code{t} which denotes
-the expression to be computed.
-\item
-A \code{return} method which consumes the result once it is
-computed.
-\end{itemize}
-The compute server creates $n$ \code{processor} processes as part of
-its initialization.  Every such process repeatedly consumes an open
-job, evaluates the job's \code{task} method and passes the result on
-to the job's
-\code{return} method. The polymorphic \code{future} method creates
-a new job where the \code{return} method is implemented by a guard
-named \code{reply} and inserts this job into the set of open jobs by
-calling the \code{isOpen} guard. It then waits until the corresponding
-\code{reply} guard is called.
-
-The example demonstrates the use of abstract types. The abstract type
-\code{t} keeps track of the result type of a job, which can vary
-between different jobs. Without abstract types it would be impossible
-to implement the same class to the user in a statically type-safe
-way, without relying on dynamic type tests and type casts.
-
-
-Here is some code which uses the compute server to evaluate 
-the expression \code{41 + 1}.
-\begin{lstlisting}
-object Test with Executable {
-  val server = new ComputeServer(1);
-  val f = server.future(41 + 1);
-  Console.println(f())
-}
-\end{lstlisting}
-
-\section{Mailboxes}
-\label{sec:mailbox}
-
-Mailboxes are high-level, flexible constructs for process
-synchronization and communication. They allow sending and receiving of
-messages. A {\em message} in this context is an arbitrary object.
-There is a special message \code{TIMEOUT} which is used to signal a
-time-out.
-\begin{lstlisting}
-case object TIMEOUT;
-\end{lstlisting}
-Mailboxes implement the following signature.
-\begin{lstlisting}
-class MailBox {
-  def send(msg: Any): unit;
-  def receive[a](f: PartialFunction[Any, a]): a;
-  def receiveWithin[a](msec: long)(f: PartialFunction[Any, a]): a;
-}
-\end{lstlisting}
-The state of a mailbox consists of a multi-set of messages.
-Messages are added to the mailbox the \code{send} method. Messages
-are removed using the \code{receive} method, which is passed a message
-processor \code{f} as argument, which is a partial function from
-messages to some arbitrary result type. Typically, this function is
-implemented as a pattern matching expression. The \code{receive}
-method blocks until there is a message in the mailbox for which its
-message processor is defined.  The matching message is then removed
-from the mailbox and the blocked thread is restarted by applying the
-message processor to the message. Both sent messages and receivers are
-ordered in time. A receiver $r$ is applied to a matching message $m$
-only if there is no other (message, receiver) pair which precedes $(m,
-r)$ in the partial ordering on pairs that orders each component in
-time.
-
-As a simple example of how mailboxes are used, consider a
-one-place buffer:
-\begin{lstlisting}
-class OnePlaceBuffer {
-  private val m = new MailBox;            // An internal mailbox
-  private case class Empty, Full(x: int); // Types of messages we deal with
-  m send Empty;                           // Initialization
-  def write(x: int): unit =
-    m receive { case Empty => m send Full(x) }
-  def read: int =
-    m receive { case Full(x) => m send Empty ; x }
-}
-\end{lstlisting}
-Here's how the mailbox class can be implemented:
-\begin{lstlisting}
-class MailBox {
-  private abstract class Receiver extends Signal {
-    def isDefined(msg: Any): boolean;
-    var msg = null;
-  }
-\end{lstlisting}
-We define an internal class for receivers with a test method
-\code{isDefined}, which indicates whether the receiver is
-defined for a given message.  The receiver inherits from class
-\code{Signal} a \code{notify} method which is used to wake up a
-receiver thread. When the receiver thread is woken up, the message it
-needs to be applied to is stored in the \code{msg} variable of
-\code{Receiver}.
-\begin{lstlisting}
-  private val sent = new LinkedList[Any];
-  private var lastSent = sent;
-  private val receivers = new LinkedList[Receiver];
-  private var lastReceiver = receivers;
-\end{lstlisting}
-The mailbox class maintains two linked lists,
-one for sent but unconsumed messages, the other for waiting receivers.
-\begin{lstlisting}
-  def send(msg: Any): unit = synchronized {
-    var r = receivers, r1 = r.next;
-    while (r1 != null && !r1.elem.isDefined(msg)) {
-      r = r1; r1 = r1.next;
-    }
-    if (r1 != null) {
-      r.next = r1.next; r1.elem.msg = msg; r1.elem.notify;
-    } else {
-      lastSent = insert(lastSent, msg);
-    }
-  }
-\end{lstlisting}
-The \code{send} method first checks whether a waiting receiver is
-applicable to the sent message. If yes, the receiver is notified.
-Otherwise, the message is appended to the linked list of sent messages.
-\begin{lstlisting}
-  def receive[a](f: PartialFunction[Any, a]): a = {
-    val msg: Any = synchronized {
-      var s = sent, s1 = s.next;
-      while (s1 != null && !f.isDefinedAt(s1.elem)) {
-        s = s1; s1 = s1.next
-      }
-      if (s1 != null) {
-        s.next = s1.next; s1.elem
-      } else {
-        val r = insert(lastReceiver, new Receiver {
-          def isDefined(msg: Any) = f.isDefinedAt(msg);
-        });
-        lastReceiver = r;
-        r.elem.wait();
-        r.elem.msg
-      }
-    }
-    f(msg)
-  }
-\end{lstlisting}
-The \code{receive} method first checks whether the message processor function
-\code{f} can be applied to a message that has already been sent but that
-was not yet consumed. If yes, the thread continues immediately by
-applying \code{f} to the message. Otherwise, a new receiver is created
-and linked into the \code{receivers} list, and the thread waits for a
-notification on this receiver. Once the thread is woken up again, it
-continues by applying \code{f} to the message that was stored in the
-receiver. The insert method on linked lists is defined as follows.
-\begin{lstlisting}
-  def insert(l: LinkedList[a], x: a): LinkedList[a] = {
-    l.next = new LinkedList[a];
-    l.next.elem = x;
-    l.next.next = l.next;
-    l
-  }
-\end{lstlisting}
-The mailbox class also offers a method \code{receiveWithin}
-which blocks for only a specified maximal amount of time.  If no
-message is received within the specified time interval (given in
-milliseconds), the message processor argument $f$ will be unblocked
-with the special \code{TIMEOUT} message.  The implementation of
-\code{receiveWithin} is quite similar to \code{receive}:
-\begin{lstlisting}
-  def receiveWithin[a](msec: long)(f: PartialFunction[Any, a]): a = {
-    val msg: Any = synchronized {
-      var s = sent, s1 = s.next;
-      while (s1 != null && !f.isDefinedAt(s1.elem)) {
-        s = s1; s1 = s1.next ;
-      }
-      if (s1 != null) {
-        s.next = s1.next; s1.elem
-      } else {
-        val r = insert(lastReceiver, new Receiver {
-            def isDefined(msg: Any) = f.isDefinedAt(msg);
-        });
-        lastReceiver = r;
-        r.elem.wait(msec);
-        if (r.elem.msg == null) r.elem.msg = TIMEOUT;
-        r.elem.msg
-      }
-    }
-    f(msg)
-  }
-} // end MailBox
-\end{lstlisting}
-The only differences are the timed call to \code{wait}, and the
-statement following it.
-
-\section{Actors}
-\label{sec:actors}
-
-Chapter~\ref{chap:example-auction} sketched as a program example the
-implementation of an electronic auction service. This service was
-based on high-level actor processes, that work by inspecting messages
-in their mailbox using pattern matching. An actor is simply a thread
-whose communication primitives are those of a mailbox.  Actors are
-hence defined as a mixin composition extension of Java's standard
-\code{Thread} class with the \code{MailBox} class.
-\begin{lstlisting}
-abstract class Actor extends Thread with MailBox;
-\end{lstlisting}
-
-\comment{
-As an extended example of an application that uses actors, we come
-back to the auction server example of Section~\ref{sec:ex-auction}.
-The following code implements:
-
-\begin{figure}[thb]
-\begin{lstlisting}
-class AuctionMessage;
-case class
-  Offer(bid: int, client: Process),                  // make a bid
-  Inquire(client: Process) extends AuctionMessage    // inquire status
-
-class AuctionReply;
-case class
-  Status(asked; int, expiration: Date),           // asked sum, expiration date
-  BestOffer,                                         // yours is the best offer
-  BeatenOffer(maxBid: int),                          // offer beaten by maxBid
-  AuctionConcluded(seller: Process, client: Process),// auction concluded
-  AuctionFailed                                      // failed with no bids
-  AuctionOver extends AuctionReply                   // bidding is closed
-\end{lstlisting}
-\end{figure}
-
-\begin{lstlisting}
-class Auction(seller: Process, minBid: int, closing: Date)
- extends Process {
-
-  val timeToShutdown = 36000000 // msec
-  val delta = 10                // bid increment
-\end{lstlisting}
-\begin{lstlisting}
-  override def run = {
-    var askedBid = minBid
-    var maxBidder: Process = null
-    while (true) {
-      receiveWithin ((closing - Date.currentDate).msec) {
-        case Offer(bid, client) => {
-          if (bid >= askedBid) {
-            if (maxBidder != null && maxBidder != client) {
-              maxBidder send BeatenOffer(bid)
-            }
-            maxBidder = client
-            askedBid = bid + delta
-            client send BestOffer
-          } else client send BeatenOffer(maxBid)
-        }
-\end{lstlisting}
-\begin{lstlisting}
-        case Inquire(client) => {
-          client send Status(askedBid, closing)
-        }
-\end{lstlisting}
-\begin{lstlisting}
-        case TIMEOUT => {
-          if (maxBidder != null) {
-            val reply = AuctionConcluded(seller, maxBidder)
-            maxBidder send reply
-            seller send reply
-          } else seller send AuctionFailed
-          receiveWithin (timeToShutdown) {
-            case Offer(_, client) => client send AuctionOver ; discardAndContinue
-            case _ => discardAndContinue
-            case TIMEOUT => stop
-          }
-        }
-\end{lstlisting}
-\begin{lstlisting}
-        case _ => discardAndContinue
-      }
-    }
-  }
-\end{lstlisting}
-\begin{lstlisting}
-  def houseKeeping: int = {
-    val Limit = 100
-    var nWaiting: int = 0
-    receiveWithin(0) {
-      case _ =>
-        nWaiting = nWaiting + 1
-        if (nWaiting > Limit) {
-          receiveWithin(0) {
-            case Offer(_, _) => continue
-            case TIMEOUT =>
-            case _ => discardAndContinue
-          }
-        } else continue
-      case TIMEOUT =>
-    }
-  }
-}
-\end{lstlisting}
-\begin{lstlisting}
-class Bidder (auction: Process, minBid: int, maxBid: int)
- extends Process {
-  val MaxTries = 3
-  val Unknown = -1
-
-  var nextBid = Unknown
-\end{lstlisting}
-\begin{lstlisting}
-  def getAuctionStatus = {
-    var nTries = 0
-    while (nextBid == Unknown && nTries < MaxTries) {
-      auction send Inquiry(this)
-      nTries = nTries + 1
-      receiveWithin(waitTime) {
-        case Status(bid, _) => bid match {
-          case None => nextBid = minBid
-          case Some(curBid) => nextBid = curBid + Delta
-        }
-        case TIMEOUT =>
-        case _ => continue
-      }
-    }
-    status
-  }
-\end{lstlisting}
-\begin{lstlisting}
-  def bid: unit = {
-    if (nextBid < maxBid) {
-      auction send Offer(nextBid, this)
-      receive {
-        case BestOffer =>
-          receive {
-            case BeatenOffer(bestBid) =>
-              nextBid = bestBid + Delta
-              bid
-            case AuctionConcluded(seller, client) =>
-                   transferPayment(seller, nextBid)
-            case _ => continue
-          }
-
-        case BeatenOffer(bestBid) =>
-          nextBid = nextBid + Delta
-          bid
-
-        case AuctionOver =>
-
-        case _ => continue
-      }
-    }
-  }
-\end{lstlisting}
-\begin{lstlisting}
-  override def run = {
-    getAuctionStatus
-    if (nextBid != Unknown) bid
-  }
-
-  def transferPayment(seller: Process, amount: int)
-}
-\end{lstlisting}
-}
diff --git a/doc/reference/ImplementationStatus.tex b/doc/reference/ImplementationStatus.tex
deleted file mode 100644
index f2c74b8695..0000000000
--- a/doc/reference/ImplementationStatus.tex
+++ /dev/null
@@ -1,50 +0,0 @@
-
-The present Scala compiler does not yet implement all of the Scala
-specification. Its currently existing omissions and deviations are
-listed below. We are working on a refined implementation that
-addresses these issues.
-\begin{enumerate}
-\item
-Unicode support is still limited. At present we only permit Unicode
-encodings \verb@\uXXXX@ in strings and backquote-enclosed identifiers.
-To define or access a Unicode identifier, you need to put it in
-backquotes and use the \verb@\uXXXX@ encoding.
-\item 
-The unicode operator ``$\Rightarrow$''
-(\sref{sec:idents}) is not yet recognized; you need to use the two
-character ASCII equivalent ``\code{=>}'' instead.
-\item
-The current implementation does not yet support run-time types.
-All types are erased (\sref{sec:erasure}) during compilation. This means that
-the following operations give potentially wrong results.
-\begin{itemize}
-\item
-Type tests and type casts to parameterized types. Here it is only tested
-that a value is an instance of the given top-level type constructor.
-\item
-Type tests and type casts to type parameters and abstract types.  Here
-it is only tested that a value is an instance of the type parameter's upper bound.  
-\item
-Polymorphic array creation. If \code{t} is a type variable or abstract type, then
-\code{new Array[t]} will yield an array of the upper bound of \code{t}.
-\end{itemize}
-\item
-Return expressions are not yet permitted inside an anonymous function
-or inside a call-by-name argument (i.e.\ a function argument corresponding to a 
-\code{def} parameter).
-\item
-Members of the empty package (\sref{sec:packagings}) cannot yet be
-accessed from other source files.  Hence, all library classes and
-objects have to be in some package.
-\item
-At present, auxiliary constructors (\sref{sec:constr-defs}) are only permitted
-for monomorphic classes.
-\item
-The \code{Array} class supports as yet only a restricted set of
-operations as given in \sref{cls:array}. It is planned to extend that
-interface. In particular, arrays will implement the \code{scala.Seq}
-trait as well as the methods needed to support for-comprehensions.
-\item
-At present, all classes used as mixins must be accessible to the Scala
-compiler in source form.
-\end{enumerate}
diff --git a/doc/reference/Makefile b/doc/reference/Makefile
deleted file mode 100644
index 38af2e0e44..0000000000
--- a/doc/reference/Makefile
+++ /dev/null
@@ -1,51 +0,0 @@
-############################################################-*-Makefile-*-####
-# Scala Reference
-##############################################################################
-# $Id$
-
-##############################################################################
-# Configuration
-
-ROOT			 = ../..
-
-include $(ROOT)/Makefile.import
-
-##############################################################################
-# Variables
-
-# project
-PROJECT_SOURCES		+= $(LATEX_SOURCES)
-
-# latex
-LATEX_FORMATS		+= dvi
-LATEX_FORMATS		+= ps
-LATEX_FORMATS		+= pdf
-
-LATEX_TARGETS		+= $(LATEX_FORMATS:%=ScalaRationale.%)
-LATEX_TARGETS		+= $(LATEX_FORMATS:%=ScalaReference.%)
-LATEX_TARGETS		+= $(LATEX_FORMATS:%=ScalaByExample.%)
-LATEX_TARGETS		+= $(LATEX_FORMATS:%=ProgrammingInScala.%)
-
-LATEX_SOURCES		+= ExamplesPart.tex
-LATEX_SOURCES		+= ReferencePart.tex
-LATEX_SOURCES		+= ScalaRationale.tex
-LATEX_SOURCES		+= ScalaByExample.tex
-LATEX_SOURCES		+= ScalaReference.tex
-LATEX_SOURCES		+= ProgrammingInScala.tex
-LATEX_SOURCES		+= Scala.bib
-
-# latex
-TEXINPUTS		:= $(PROJECT_SUPPORTDIR)/latex:$(TEXINPUTS):
-BIBINPUTS		:= .
-
-##############################################################################
-# Includes
-
-include $(PROJECT_SUPPORTDIR)/make/latex.mk
-
-##############################################################################
-
-clean			:
-	$(RM) *.out *.pdf *.ps *.dvi *.aux *.log *.bbl *.blg *.toc
-
-##############################################################################
diff --git a/doc/reference/ProgrammingInScala.tex b/doc/reference/ProgrammingInScala.tex
deleted file mode 100644
index ce88840053..0000000000
--- a/doc/reference/ProgrammingInScala.tex
+++ /dev/null
@@ -1,89 +0,0 @@
-\documentclass[a4paper,12pt,twoside,titlepage]{book}
-
-\usepackage{scaladoc}
-\usepackage{fleqn}
-\usepackage{modefs}
-\usepackage{math}
-\usepackage{scaladefs}
-\renewcommand{\todo}[1]{}
-
-
-
-\ifpdf
-    \pdfinfo {
-        /Author   (Martin Odersky)
-        /Title    (Programming in Scala)
-        /Keywords (Scala)
-        /Subject  ()
-        /Creator  (TeX)
-        /Producer (PDFLaTeX)
-    }
-\fi
-
-\renewcommand{\doctitle}{Programming in Scala\\[33mm]\ }
-\renewcommand{\docauthor}{Martin Odersky\\[53mm]\ }
-
-\begin{document}
-
-\frontmatter
-\makedoctitle
-\clearemptydoublepage
-\tableofcontents
-\mainmatter
-\sloppy
-
-\part{Rationale}
-
-\input{RationalePart}
-
-\paragraph{Acknowledgments}
-Many people have contributed to the definition and implementation of
-the Scala language and to parts of this book. First of all, I would
-like to thank the Scala team at EPFL consisting of Philippe Altherr,
-Vincent Cremet, Burak Emir, St\'ephane Micheloud, Nikolay Mihaylov,
-Michel Schinz, Erik Stenman, and Matthias Zenger. They put a lot of
-effort in the Scala compiler, tools, and documentation and have
-contributed in an essential way to the specification of the Scala
-language through many observations, clever suggestions, and
-discussions. Members of the team have also contributed examples in
-this book, as well as parts of the specification. Phil Bagwell, Gilad
-Bracha, Erik Ernst, Erik Mejer, Benjamin Pierce, Enno Runne, and Phil
-Wadler have given very useful feedback on the Scala design. 
-
-The documentation ows a great debt to Abelson's and Sussman's
-wonderful book ``Structure and Interpretation of Computer
-Programs''\cite{abelson-sussman:structure}. I have adapted several of
-their examples and exercises in the ``Scala By Example'' part of this
-book. Of course, the working language has in each case been changed
-from Scheme to Scala. Furthermore, the examples make use of Scala's
-object-oriented constructs where appropriate.
-
-\part{Scala by Example}
-
-Scala is a programming language that fuses elements from
-object-oriented and functional programming. This part introduces Scala
-in an informal way, through a sequence of examples.
-
-Chapters~\ref{chap:example-one} and \ref{chap:example-auction}
-highlight some of the features that make Scala interesting. The
-following chapters introduce the language constructs of Scala in a
-more thorough way, starting with simple expressions and functions, and
-working up through objects and classes, lists and streams, mutable
-state, pattern matching to more complete examples that show
-interesting programming techniques. The present informal exposition is
-complemented by the Scala Language Reference Manual which specifies
-Scala in a more detailed and precise way.
-
-\input{ExamplesPart}
-
-\part{The Scala Language Specification \\ \ \\ \Large Version 1.0}
-
-\input{ReferencePart}
-
-\bibliographystyle{alpha}
-\bibliography{Scala}
-
-\input{ReferencePartAppendix}
-
-
-\end{document}
diff --git a/doc/reference/RationalePart.tex b/doc/reference/RationalePart.tex
deleted file mode 100644
index c14eaef5ef..0000000000
--- a/doc/reference/RationalePart.tex
+++ /dev/null
@@ -1,164 +0,0 @@
-%% $Id$
-
-There are hundreds of programming languages in active use, and many
-more are being designed each year. It is therefore hard to justify the
-development of yet another language. Nevertheless, this is what we
-attempt to do here.  Our argument is based on two claims:
-\begin{itemize}
-\item[] {\em Claim 1:} The raise in importance of web services and
-other distributed software is a fundamental paradigm
-shift in programming. It is comparable in scale to the shift 20 years ago
-from character-oriented to graphical user interfaces.
-\item[] {\em Claim 2:} That paradigm shift will provide demand
-for new programming languages, just as graphical user interfaces
-promoted the adoption of object-oriented languages.
-\end{itemize}
-For the last 20 years, the most common programming model was
-object-oriented: System components are objects, and computation is
-done by method calls.  Methods themselves take object references as
-parameters. Remote method calls let one extend this programming model
-to distributed systems. The problem of this model is that it does not
-scale up very well to wide-scale networks where messages can be
-delayed and components may fail. Web services address the message
-delay problem by increasing granularity, using method calls with
-larger, structured arguments, such as XML trees.  They address the
-failure problem by using transparent replication and avoiding server
-state.  Conceptually, they are {\em tree transformers} that consume
-incoming message documents and produce outgoing ones.  \comment{ To
-back up the first claim, one observes that web services and other
-distributed software increasingly tend to communicate using structured
-or semi-structured data. A typical example is the use of XML to
-describe data managed by applications as well as the messages between
-applications. This tends to affect the role of a program in a
-fundamental way. Previously, programs could be seen as objects that
-reacted to method calls and in turn called methods of other
-objects. Some of these method calls might originate from users while
-others might originate from other computers via remote invocations.
-These method calls have simple unstructured parameters or object
-references as arguments.  Web services, on the other hand, communicate
-with each other by transmitting asynchronous messages that carry
-structured documents, usually in XML format. Programs then
-conceptually become {\em tree transformers} that consume incoming
-message documents and produce outgoing ones.  }
-
-Why should this have an effect on programming languages? There are at
-least two reasons: First, today's object-oriented languages are not
-very good at analyzing and transforming XML trees. Because such trees
-usually contain data but no methods, they have to be decomposed and
-constructed from the ``outside'', that is from code which is external
-to the tree definition itself. In an object-oriented language, the
-ways of doing so are limited. The most common solution \cite{w3c:dom} is
-to represent trees in a generic way, where all tree nodes are values
-of a common type.  This makes it easy to write generic traversal
-functions, but forces applications to operate on a very low conceptual
-level, which often loses important semantic distinctions present in
-the XML data.  More semantic precision is obtained if different
-internal types model different kinds of nodes.  But then tree
-decompositions require the use of run-time type tests and type casts
-to adapt the treatment to the kind of node encountered. Such type
-tests and type casts are generally not considered good object-oriented
-style. They are rarely efficient, nor easy to use.
-
-
-By contrast, tree transformation is the natural domain of functional
-languages. Their algebraic data types, pattern matching and
-higher-order functions make these languages ideal for the task. It's
-no wonder, then, that specialized languages for transforming XML data
-such as XSLT are functional.
-
-Another reason why functional language constructs are attractive for
-web-services is that mutable state is problematic in this setting.
-Components with mutable state are harder to replicate or to restore
-after a failure. Data with mutable state is harder to cache than
-immutable data. Functional language constructs make it relatively easy
-to construct components without mutable state.
-
-Many web services are constructed by combining different languages.
-For instance, a service might use XSLT to handle document
-transformation, XQuery for database access, and Java for the
-``business logic''.  The downside of this approach is that the
-necessary amount of cross-language glue can make applications
-cumbersome to write, verify, and maintain. A particular problem is
-that cross-language interfaces are usually not statically typed.
-Hence, the benefits of a static type system are missing where they are
-needed most -- at the join points of components written in different
-paradigms.  
-
-Conceivably, the glue problem could be addressed by a ``multi-paradigm''
-language that would express object-oriented, concurrent, as well
-as functional aspects of an application.  But one needs to be careful
-not to simply replace cross-language glue by awkward interfaces
-between different paradigms within the language itself.  Ideally, one
-would hope for a fusion which unifies concepts found in different
-paradigms instead of an agglutination, which merely includes them side
-by side.  This fusion is what we try to achieve with Scala
-\footnote{Scala stands for ``Scalable Language''. The term means
-  ``Stairway'' in Italian}.
-
-Scala is both an object-oriented and functional language.  It is a
-pure object-oriented language in the sense that every value is an
-object. Types and behavior of objects are described by
-classes. Classes can be composed using mixin composition.  Scala is
-designed to work seamlessly with mainstream object-oriented languages,
-in particular Java and C\#.
-
-Scala is also a functional language in the sense that every function
-is a value. Nesting of function definitions and higher-order functions
-are naturally supported. Scala also supports a general notion of
-pattern matching which can model the algebraic types used in many
-functional languages. Furthermore, this notion of pattern matching
-naturally extends to the processing of XML data.
-
-The design of Scala is driven by the desire to unify object-oriented
-and functional elements. Here are three examples how this is achieved:
-\begin{itemize}
-\item
-Since every function is a value and every value is an object, it
-follows that every function in Scala is an object. Indeed, there is a
-root class for functions which is specialized in the Scala standard
-library to data structures such as arrays and hash tables.
-\item
-Data structures in many functional languages are defined using
-algebraic data types. They are decomposed using pattern matching.
-Object-oriented languages, on the other hand, describe data with class
-hierarchies. Algebraic data types are usually closed, in that the
-range of alternatives of a type is fixed when the type is defined.  By
-contrast, class hierarchies can be extended by adding new leaf
-classes.  Scala adopts the object-oriented class hierarchy scheme for
-data definitions, but allows pattern matching against values coming
-from a whole class hierarchy, not just values of a single type.
-This can express both closed and extensible data types, and also
-provides a convenient way to exploit run-time type information in
-cases where static typing is too restrictive.
-\item
-Module systems of functional languages such as SML or Caml excel in
-abstraction; they allow very precise control over visibility of names
-and types, including the ability to partially abstract over types.  By
-contrast, object-oriented languages excel in composition; they offer
-several composition mechanisms lacking in module systems, including
-inheritance and unlimited recursion between objects and classes.
-Scala unifies the notions of object and module, of module signature
-and interface, as well as of functor and class. This combines the
-abstraction facilities of functional module systems with the
-composition constructs of object-oriented languages. The unification
-is made possible by means of a new type system based on path-dependent
-types \cite{odersky-et-al:fool10}.
-\end{itemize}
-There are several other languages that try to bridge the gap between
-the functional and object oriented
-paradigms. Smalltalk\cite{goldberg-robson:smalltalk-language},
-Python\cite{rossum:python}, or Ruby\cite{matsumtoto:ruby} come to
-mind. Unlike these languages, Scala has an advanced static type
-system, which contains several innovative constructs.  This aspect
-makes the Scala definition a bit more complicated than those of the
-languages above. On the other hand, Scala enjoys the robustness,
-safety and scalability benefits of strong static typing. Furthermore,
-Scala incorporates recent advances in type inference, so that
-excessive type annotations in user programs can usually be avoided.
-
-% rest of this report is structured as follows. Chapters
-%\ref{sec:simple-examples} to \ref{sec:concurrency} give an informal overview of
-%Scala by means of a sequence of program examples.  The remaining
-%chapters contain the language definition. The definition is formulated
-%in prose but tries to be precise.
-
diff --git a/doc/reference/ReferencePart.tex b/doc/reference/ReferencePart.tex
deleted file mode 100644
index b5c29deb75..0000000000
--- a/doc/reference/ReferencePart.tex
+++ /dev/null
@@ -1,4905 +0,0 @@
-\renewcommand{\todo}[1]{}
-\newcommand{\notyet}[1]{\footnote{#1 not yet implemented.}}
-\newcommand{\Ts}{\mbox{\sl Ts}}
-\newcommand{\tps}{\mbox{\sl tps}}
-\newcommand{\psig}{\mbox{\sl psig}}
-\newcommand{\fsig}{\mbox{\sl fsig}}
-\newcommand{\csig}{\mbox{\sl csig}}
-\newcommand{\args}{\mbox{\sl args}}
-\newcommand{\targs}{\mbox{\sl targs}}
-\newcommand{\enums}{\mbox{\sl enums}}
-\newcommand{\proto}{\mbox{\sl pt}}
-\newcommand{\argtypes}{\mbox{\sl Ts}}
-\newcommand{\stats}{\mbox{\sl stats}}
-\newcommand{\overload}{\la\mbox{\sf and}\ra}
-\newcommand{\op}{\mbox{\sl op}}
-
-\newcommand{\ifqualified}[1]{}
-\newcommand{\iflet}[1]{}
-\newcommand{\ifundefvar}[1]{}
-\newcommand{\iffinaltype}[1]{}
-\newcommand{\ifpackaging}[1]{}
-\newcommand{\ifnewfor}[1]{}
-
-\newcommand{\U}[1]{\mbox{$\backslash$u{#1}}}
-\newcommand{\Urange}[2]{\mbox{$\backslash$u{#1}-$\backslash$u{#2}}}
-%\newcommand{\U}[1]{\mbox{U+{#1}}}
-
-\chapter{Lexical Syntax}
-
-Scala programs are written using the Unicode character set.
-This chapter defines the two modes of Scala's lexical syntax, the
-Scala mode and the \textsc{Xml} mode. If not otherwise mentioned, the following 
-descriptions of Scala tokens refer to Scala mode, and literal characters `c' refer 
-to the ASCII fragment \Urange{0000}{007F}. 
-
-In Scala mode, \textit{Unicode escapes} are replaced by the corresponding
-Unicode character with the given hexadecimal code.
-\begin{lstlisting}
-UnicodeEscape ::= \{\\}u{u} HexDigit HexDigit HexDigit HexDigit
-HexDigit      ::= '0' | $\ldots$ | `9' | `A' | $\ldots$ | `F' | `a' | $\ldots$ | `f' |
-\end{lstlisting}
-To construct tokens, characters are distinguished according to the following classes 
-(Unicode general category given in parentheses):
-\begin{enumerate}
-\item Whitespace characters. \U{0020} | \U{0009} | \U{000D} | \U{000A}
-\item Letters, which include lower case letters(Ll), upper case letters(Lu), titlecase letters(Lt), other letters(Lo), letter numerals(Nl) and the 
-two characters \U{0024} ~\lstinline@`$\Dollar$'@ and \U{005F} ~\lstinline@`_'@, which
-both count as upper case letters
-\item Digits ~\lstinline@`0' | $\ldots$ | `9'@.
-\item Parentheses ~\lstinline@`(' | `)' | `[' | `]' | `{' | `}'@.
-\item Delimiter characters ~\lstinline@``' | `'' | `"' | `.' | `;' | `,'@.
-\item Operator characters. These consist of all printable ASCII characters \Urange{0020}{007F}. 
-which are in none of the sets above, mathematical symbols(Sm) and other symbols(So).
-\end{enumerate}
-\newpage
-\section{Identifiers}\label{sec:idents}
-
-\syntax\begin{lstlisting}
-op        ::=  special {special}
-varid     ::=  lower idrest
-id        ::=  upper idrest
-            |  varid
-            |  op
-            |  ```string chars`''
-idrest    ::= {letter $|$ digit} [`_' op | `_' idrest]
-\end{lstlisting}
-
-There are three ways to form an identifier. First, an identifier can
-start with a letter which can be followed by an arbitrary sequence of
-letters and digits. This may be followed by underscore `\lstinline@_@'
-characters and other string composed of either letters and digits or
-of special characters.  Second, an identifier can start with a
-special character followed by an arbitrary sequence of special
-characters.  Finally, an identifier may also be formed by an arbitrary
-string between back-quotes (host systems may impose some restrictions
-on which strings are legal for identifiers).  As usual, a longest
-match rule applies. For instance, the string
-
-\begin{lstlisting}
-big_bob++=`def`
-\end{lstlisting}
-
-decomposes into the three identifiers \lstinline@big_bob@, \lstinline@++=@, and
-\code{def}.  The rules for pattern matching further distinguish between
-{\em variable identifiers}, which start with a lower case letter, and
-{\em constant identifiers}, which do not.
-
-
-The `\lstinline[mathescape=false]@$@'\comment{$} character is reserved for compiler-synthesized identifiers.
-User programs are not allowed to define identifiers which contain `\lstinline[mathescape=false]@$@'\comment{$}
-characters. 
-
-The following names are reserved words instead of being members of the
-syntactic class \code{id} of lexical identifiers.
-
-\begin{lstlisting}
-abstract    case    catch    class    def    
-do    else    extends    false    final    
-finally    for    if    implicit    import
-match    new    null    object    override
-package    private    protected    return    sealed
-super    this    throw    trait    try
-true    type    val    var    while
-with   yield
-_    :    =    =>    <-    <:    >:    #    @
-\end{lstlisting}
-
-The Unicode operator \U{21D2} `$\Rightarrow$' has the ASCII equivalent
-`$=>$', which is also reserved.
-
-\example
-Here are examples of identifiers:
-\begin{lstlisting}
-    x    Object        maxIndex        p2p      empty_?
-    +    +_field       $\alpha\rho\epsilon\tau\eta$
-\end{lstlisting}
-
-\section{Braces and Semicolons}
-
-A semicolon `\lstinline@;@' is implicitly inserted after every closing brace
-if there is a new line character between closing brace and the next
-regular token after it, except if that token cannot legally start a
-statement.
-
-The tokens which cannot legally start a statement
-are the following delimiters and reserved words:
-\begin{lstlisting}
-catch    else    extends    finally    with    yield
-,    .    ;    :    =    =>    <-    <:    <%    >:    #    @    )    ]    }
-\end{lstlisting}
-
-\section{Literals}
-
-There are literals for integer numbers (of types \code{Int} and \code{Long}),
-floating point numbers (of types \code{Float} and \code{Double}), characters, and
-strings.  The syntax of these literals is in each case as in Java.
-
-\todo{say that we take values from Java, give examples of some lits in particular float and double.}
-
-\syntax\begin{lstlisting}
-intLit       ::=  $\mbox{\rm\em ``as in Java''}$
-floatLit     ::=  $\mbox{\rm\em ``as in Java''}$
-charLit      ::=  $\mbox{\rm\em ``as in Java''}$
-stringLit    ::=  $\mbox{\rm\em ``as in Java''}$
-\end{lstlisting}
-
-\section{Whitespace and Comments}
-
-Tokens may be separated by whitespace characters
-and/or comments. Comments come in two forms:
-
-A single-line comment is a sequence of characters which starts with
-\lstinline@//@ and extends to the end of the line.
-
-A multi-line comment is a sequence of characters between \lstinline@/*@ and
-\lstinline@*/@. Multi-line comments may be nested.
-
-\section{XML mode\label{sec::xmlMode}}
-
-In order to allow literal inclusion of XML fragments, lexical analysis
-switches from Scala mode to XML mode when encountering an opening
-angle bracket '<' in the following circumstance: The '<' must be
-preceded either by whitespace, an opening parenthesis or an opening
-brace and immediately followed by a character starting an XML name.
-
-\syntax\begin{lstlisting}
- ( whitespace | '(' | '{' ) '<' XNameStart
-
-  XNameStart ::= `_' | BaseChar | Ideographic $\mbox{\rm\em (as in W3C XML, but without }$ `:'
-\end{lstlisting}
-
-The scanner switches from XML mode to Scala mode if either
-\begin{itemize}
-\item the XML expression or the XML pattern started by the initial '<' has been 
-successfully parsed, or if
-
-\item the parser encounters an embedded Scala expression or pattern and 
-forces the Scanner 
-back to normal mode, until the Scala expression or pattern is
-successully parsed. In this case, since code and XML fragments can be
-nested, the parser has to maintain a stack that reflects the nesting
-of XML and Scala expressions adequately.
-\end{itemize}
-
-Note that no Scala tokens are constructed in XML mode, and that comments are interpreted
-as text.
-
-\chapter{\label{sec:names}Identifiers, Names and Scopes}
-
-Names in Scala identify types, values, methods, and classes which
-are collectively called {\em entities}.  Names are introduced by
-definitions, declarations (\sref{sec:defs}) or import clauses
-(\sref{sec:import}), which are collectively called {\em binders}.
-
-There are two different name spaces, one for types (\sref{sec:types})
-and one for terms (\sref{sec:exprs}).  The same name may designate a
-type and a term, depending on the context where the name is used.  
-
-A definition or declaration has a {\em scope} in which the entity
-defined by a single name can be accessed using a simple name. Scopes
-are nested, and a definition or declaration in some inner scope {\em
-shadows} a definition in an outer scope that contributes to the same
-name space. Furthermore, a definition or declaration shadows bindings
-introduced by a preceding import clause, even if the import clause is
-in the same block. Import clauses, on the other hand, only shadow
-bindings introduced by other import clauses in outer blocks.
-
-A reference to an unqualified (type- or term-) identifier $x$ is bound
-by the unique binder, which
-\begin{itemize}
-\item defines an entity with name $x$ in the same namespace as the
-identifier, and
-\item shadows all other binders that define entities with name $x$ in that namespace.
-\end{itemize}
-It is an error if no such binder exists.  If $x$ is bound by an import
-clause, then the simple name $x$ is taken to be equivalent to the
-qualified name to which $x$ is mapped by the import clause. If $x$ is bound by a definition or declaration,
-then $x$ refers to the entity introduced by that
-binder. In that case, the type of $x$ is the type of the referenced
-entity.
-
-\example Consider the following nested definitions and imports:
-
-\begin{lstlisting}
-object m1 {
-  object m2 { val x: int = 1; val y: int = 2 }
-  object m3 { val x: boolean = true; val y: String = "" }
-  val x: int = 3;              
-  { import m2._;            // shadows nothing
-                            //   reference to `x' is ambiguous here
-    val x: String = "abc";  // shadows preceding import
-                            //   name `x' refers to latest val definition
-    { import m3._           // shadows only preceding import m2
-                            // reference to `x' is ambiguous here
-                            //   name `y' refers to latest import clause
-    }
-  }
-} 
-\end{lstlisting}
-
-A reference to a qualified (type- or term-) identifier $e.x$ refers to
-the member of the type $T$ of $e$ which has the name $x$ in the same
-namespace as the identifier. It is an error if $T$ is not a value type
-(\sref{sec:value-types}). The type of $e.x$ is the member type of the
-referenced entity in $T$.
-
-\chapter{\label{sec:types}Types}
-
-\syntax\begin{lstlisting}
-  Type          ::=  Type1 `=>' Type
-                  |  `(' [Types] `)' `=>' Type
-                  |  Type1
-  Type1         ::=  SimpleType {with SimpleType} [Refinement]
-  SimpleType    ::=  StableId
-                  |  SimpleType `#' id
-                  |  Path `.' type
-                  |  SimpleType TypeArgs
-                  |  `(' Type ')'
-  Types         ::=  Type {`,' Type}
-\end{lstlisting}
-
-We distinguish between first-order types and type constructors, which
-take type parameters and yield types. A subset of first-order types
-called {\em value types} represents sets of (first-class) values.
-Value types are either {\em concrete} or {\em abstract}. Every
-concrete value type can be represented as a {\em class type}, i.e.\ a
-type designator (\sref{sec:type-desig}) that refers to a 
-class\footnote{We assume that objects and packages also
-implicitly define a class (of the same name as the object or package,
-but inaccessible to user programs).} (\sref{sec:classes}), 
-or as a {\em compound type} (\sref{sec:compound-types}) 
-consisting of class types and possibly
-also a refinement (\sref{sec:refinements}) that further constrains the
-types of its members.
-
-A shorthand exists for denoting function types
-(\sref{sec:function-types}).  Abstract value types are introduced by
-type parameters and abstract type bindings (\sref{sec:typedcl}).
-Parentheses in types are used for grouping.
-
-Non-value types capture properties of
-identifiers that are not values
-(\sref{sec:synthetic-types}).  There is no syntax to express these
-types directly in Scala.
-
-\section{Paths}\label{sec:paths}\label{sec:stable-ids}
-
-\syntax\begin{lstlisting}
-  StableId        ::=  id
-                    |  Path `.' id 
-                    |  [id '.'] super [`[' id `]'] `.' id
-  Path            ::=  StableId
-                    |  [id `.'] this
-\end{lstlisting}
-
-Paths are not types themselves, but they can be a part of named types
-and in that way form a central role in Scala's type system.
-
-A path is one of the following.
-\begin{itemize}
-\item
-The empty path $\epsilon$ (which cannot be written explicitly in user programs).
-\item
-\lstinline@$C$.this@, where $C$ references a class. 
-The path \code{this} is taken as a shorthand for \lstinline@$C$.this@ where 
-$C$ is the name of the class directly enclosing the reference. 
-\item
-\lstinline@$p$.$x$@ where $p$ is a path and $x$ is a stable member of $p$.
-{\em Stable members} are members introduced by value or object
-definitions, as well as packages.
-\item
-\lstinline@$C$.super.$x$@ or \lstinline@$C$.super[$M\,$].$x$@
-where $C$ references a class and $x$ references a 
-stable member of the super class or designated mixin class $M$ of $C$. 
-The prefix \code{super} is taken as a shorthand for \lstinline@$C$.super@ where 
-$C$ is the name of the class directly enclosing the reference. 
-\end{itemize}
-A {\em stable identifier} is a path which ends in an identifier.
-
-\section{Value Types}\label{sec:value-types}
-
-\subsection{Singleton Types}
-\label{sec:singleton-type}
-
-\syntax\begin{lstlisting}
-  SimpleType  ::=  Path `.' type
-\end{lstlisting}
-
-A singleton type is of the form \lstinline@$p$.type@, where $p$ is a
-path pointing to a value expected to conform to
-\lstinline@scala.AnyRef@.  The type denotes the set of values
-consisting of the value denoted by $p$ and \lstinline@null@.
-
-\subsection{Type Projection}
-\label{sec:type-project}
-
-\syntax\begin{lstlisting} 
-SimpleType  ::=  SimpleType `#' id
-\end{lstlisting}
-
-A type projection \lstinline@$T$#$x$@ references the type member named 
-$x$ of type $T$. $T$ must be either a singleton type,
-or a non-abstract class type, or a Java class type (in either of the
-last two cases, it is guaranteed that $T$ has no abstract type
-members).
-
-\subsection{Type Designators}
-\label{sec:type-desig}
-
-\syntax\begin{lstlisting}
-  SimpleType  ::=  StableId
-\end{lstlisting}
-
-A type designator refers to a named value type. It can be simple or
-qualified. All such type designators are shorthands for type projections.
-
-Specifically, the unqualified type name $t$ where $t$ is bound in some
-class, object, or package $C$ is taken as a shorthand for
-\lstinline@$C$.this.type#$t$@.  If $t$ is not bound in a class, object, or
-package, then $t$ is taken as a shorthand for
-\lstinline@$\epsilon$.type#$t$@.
-
-A qualified type designator has the form \lstinline@$p$.$t$@ where $p$ is
-a path (\sref{sec:paths}) and $t$ is a type name. Such a type designator is
-equivalent to the type projection \lstinline@$p$.type#$x$@.
-
-\example 
-Some type designators and their expansions are listed below. We assume
-a local type parameter $t$, a value \code{maintable}
-with a type member \code{Node} and the standard class \lstinline@scala.Int@, 
-\begin{lstlisting}
-  t                     $\epsilon$.type#t
-  Int                   scala.type#Int
-  scala.Int             scala.type#Int
-  data.maintable.Node   data.maintable.type#Node
-\end{lstlisting}
-
-\subsection{Parameterized Types}
-\label{sec:param-types}
-
-\syntax\begin{lstlisting}
-  SimpleType      ::=  SimpleType TypeArgs
-  TypeArgs        ::=  `[' Types `]'
-\end{lstlisting}
-
-A parameterized type $T[U_1 \commadots U_n]$ consists of a type designator
-$T$ and type parameters $U_1 \commadots U_n$ where $n \geq 1$.  $T$
-must refer to a type constructor which takes $n$ type parameters $a_1 \commadots a_n$ 
-with lower bounds $L_1 \commadots L_n$ and upper bounds $U_1 \commadots U_n$.
-
-The parameterized type is well-formed if each actual type parameter
-{\em conforms to its bounds}, i.e.\ $L_i\sigma <: T_i <: U_i\sigma$ where $\sigma$
-is the substitution $[a_1 := T_1 \commadots a_n := T_n]$.
-
-\example\label{ex:param-types}
-Given the partial type definitions:
-
-\begin{lstlisting}
-  class TreeMap[a <: Ord[a], b] { $\ldots$ }
-  class List[a] { $\ldots$ }
-  class I extends Ord[I] { $\ldots$ }
-\end{lstlisting}
-
-the following parameterized types are well formed:
-
-\begin{lstlisting}
-  TreeMap[I, String]
-  List[I]
-  List[List[Boolean]]
-\end{lstlisting}
-
-\example Given the type definitions of \ref{ex:param-types},
-the following types are ill-formed:
-
-\begin{lstlisting}
-  TreeMap[I]                // illegal: wrong number of parameters
-  TreeMap[List[I], Boolean] // illegal: type parameter not within bound
-\end{lstlisting}
-
-\subsection{Compound Types}
-\label{sec:compound-types}
-\label{sec:refinements}
-
-\syntax\begin{lstlisting}
-  Type            ::=  SimpleType {with SimpleType} [Refinement]
-  Refinement      ::=  `{' [RefineStat {`;' RefineStat}] `}'
-  RefineStat      ::=  Dcl
-                    |  type TypeDef
-                    |
-\end{lstlisting}
-
-A compound type ~\lstinline@$T_1$ with $\ldots$ with $T_n$ {$R\,$}@~  represents
-objects with members as given in the component types $T_1 \commadots
-T_n$ and the refinement \lstinline@{$R\,$}@. Each component type $T_i$ must be a
-class type \todo{Relax for first?}. A
-refinement \lstinline@{$R\,$}@ contains declarations and type
-definitions. Each declaration or definition in a refinement must
-override a declaration or definition in one of the component types
-$T_1 \commadots T_n$. The usual rules for overriding (\sref{sec:overriding})
-apply. If no refinement is given, the empty refinement is implicitly
-added, i.e. ~\lstinline@$T_1$ with $\ldots$ with $T_n$@~ is a shorthand for
-~\lstinline@$T_1$ with $\ldots$ with $T_n$ {}@.
- 
-\subsection{Function Types}
-\label{sec:function-types}
-
-\syntax\begin{lstlisting}
-  SimpleType     ::=  Type1 `=>' Type
-                   |  `(' [Types] `)' `=>' Type
-\end{lstlisting}
-The type ~\lstinline@($T_1 \commadots T_n$) => $U$@~ represents the set of function
-values that take arguments of types $T_1 \commadots T_n$ and yield
-results of type $U$.  In the case of exactly one argument type
-~\lstinline@$T$ => $U$@~ is a shorthand for ~\lstinline@($T\,$) => $U$@.  Function types
-associate to the right, e.g.~\lstinline@($S\,$) => ($T\,$) => $U$@~ is the same as
-~\lstinline@($S\,$) => (($T\,$) => $U\,$)@.
-
-Function types are shorthands for class types that define \code{apply}
-functions.  Specifically, the $n$-ary function type 
-~\lstinline@($T_1 \commadots T_n$) => U@~ is a shorthand for the class type
-\lstinline@Function$n$[$T_1 \commadots T_n$,$U\,$]@. Such class
-types are defined in the Scala library for $n$ between 0 and 9 as follows.
-\begin{lstlisting}
-package scala;
-trait Function$n$[-$T_1 \commadots$ -$T_n$, +$R$] {
-  def apply($x_1$: $T_1 \commadots x_n$: $T_n$): $R$;
-  override def toString() = "<function>";
-}
-\end{lstlisting}
-Hence, function types are covariant in their result type, and
-contravariant in their argument types.
-
-\section{Non-Value Types}
-\label{sec:synthetic-types}
-
-The types explained in the following do not denote sets of values, nor
-do they appear explicitly in programs. They are introduced in this
-report as the internal types of defined identifiers.
-
-\subsection{Method Types}
-\label{sec:method-types}
-
-A method type is denoted internally as $(\Ts)U$, where $(\Ts)$ is a
-sequence of types $(T_1 \commadots T_n)$ for some $n \geq 0$
-and $U$ is a (value or method) type.  This type represents named
-methods that take arguments of types $T_1 \commadots T_n$ 
-and that return a result of type $U$.
-
-Method types associate to the right: $(\Ts_1)(\Ts_2)U$ is treated as
-$(\Ts_1)((\Ts_2)U)$.
-
-A special case are types of methods without any parameters. They are
-written here \lstinline@=> T@. Parameterless methods name expressions
-that are re-evaluated each time the parameterless method name is
-referenced.
-
-Method types do not exist as types of values. If a method name is used
-as a value, its type is implicitly converted to a corresponding
-function type (\sref{sec:impl-conv}).
-
-\example The declarations
-\begin{lstlisting}
-def a: Int
-def b (x: Int): Boolean
-def c (x: Int) (y: String, z: String): String
-\end{lstlisting}
-produce the typings
-\begin{lstlisting}
-a: => Int
-b: (Int) Boolean
-c: (Int) (String, String) String
-\end{lstlisting}
-
-\subsection{Polymorphic Method Types}
-\label{sec:poly-types}
-
-A polymorphic method type is denoted internally as ~\lstinline@[$\tps\,$]$T$@~ where
-\lstinline@[$\tps\,$]@ is a type parameter section 
-~\lstinline@[$a_1$ >: $L_1$ <: $U_1 \commadots a_n$ >: $L_n$ <: $U_n$]@~ 
-for some $n \geq 0$ and $T$ is a
-(value or method) type.  This type represents named methods that
-take type arguments ~\lstinline@$S_1 \commadots S_n$@~ which
-conform (\sref{sec:param-types}) to the lower bounds
-~\lstinline@$L_1 \commadots L_n$@~ and the upper bounds
-~\lstinline@$U_1 \commadots U_n$@~ and that yield results of type $T$.
-
-\example The declarations
-\begin{lstlisting}
-def empty[a]: List[a]
-def union[a <: Comparable[a]] (x: Set[a], xs: Set[a]): Set[a]
-\end{lstlisting}
-produce the typings
-\begin{lstlisting}
-empty : [a >: All <: Any] List[a]
-union : [a >: All <: Comparable[a]] (x: Set[a], xs: Set[a]) Set[a]  .
-\end{lstlisting}
-
-\comment{
-\subsection{Overloaded Types}
-\label{sec:overloaded-types}
-
-More than one values or methods are defined in the same scope with the
-same name, we model
-
-An overloaded type consisting of type alternatives $T_1 \commadots
-T_n (n \geq 2)$ is denoted internally $T_1 \overload \ldots \overload T_n$.
-
-\example The definitions
-\begin{lstlisting}
-def println: unit;
-def println(s: string): unit = $\ldots$;
-def println(x: float): unit = $\ldots$;
-def println(x: float, width: int): unit = $\ldots$;
-def println[a](x: a)(tostring: a => String): unit = $\ldots$
-\end{lstlisting}
-define a single function \code{println} which has an overloaded
-type.
-\begin{lstlisting}
-println:  => unit $\overload$
-          (String) unit $\overload$
-          (float) unit $\overload$
-          (float, int) unit $\overload$
-          [a] (a) (a => String) unit
-\end{lstlisting}
-
-\example The definitions
-\begin{lstlisting}
-def f(x: T): T = $\ldots$;
-val f = 0
-\end{lstlisting}
-define a function \code{f} which has type ~\lstinline@(x: T)T $\overload$ Int@.
-}
-
-\section{Base Classes and Member Definitions}
-\label{sec:base-classes-member-defs}
-
-Types, bounds and base classes of class members depend on the way the
-members are referenced.  Central here are three notions, namely:
-\begin{enumerate}
-\item the notion of the set of base classes of a type $T$,
-\item the notion of a type $T$ in some class $C$ seen from some 
-      prefix type $S$,
-\item the notion of a member binding of some type $T$.
-\end{enumerate}
-These notions are defined mutually recursively as follows.
-
-1. The set of {\em base classes} of a type is a set of class types, 
-given as follows.
-\begin{itemize}
-\item
-The base classes of a class type $C$ are the base classes of class
-$C$.
-\item
-The base classes of an aliased type are the base classes of its alias.
-\item
-The base classes of an abstract type are the base classes of its upper bound.
-\item
-The base classes of a parameterized type 
-~\lstinline@$C$[$T_1 \commadots T_n$]@~ are the base classes
-of type $C$, where every occurrence of a type parameter $a_i$ 
-of $C$ has been replaced by the corresponding parameter type $T_i$.
-\item
-The base classes of a singleton type \lstinline@$p$.type@ are the base classes of
-the type of $p$.
-\item
-The base classes of a compound type 
-~\lstinline@$T_1$ with $\ldots$ with $T_n$ {$R\,$}@~ 
-are the {\em reduced union} of the base
-classes of all $T_i$'s. This means: 
-Let the multi-set $\SS$ be the multi-set-union of the
-base classes of all $T_i$'s.
-If $\SS$ contains several type instances of the same class, say
-~\lstinline@$S^i$#$C$[$T^i_1 \commadots T^i_n$]@~ $(i \in I)$, then
-all those instances 
-are replaced by one of them which conforms to all
-others. It is an error if no such instance exists, or if $C$ is not a trait 
-(\sref{sec:traits}). It follows that the reduced union, if it exists,
-produces a set of class types, where different types are instances of different classes.
-\item
-The base classes of a type selection \lstinline@$S$#$T$@ are
-determined as follows. If $T$ is an alias or abstract type, the
-previous clauses apply. Otherwise, $T$ must be a (possibly
-parameterized) class type, which is defined in some class $B$.  Then
-the base classes of \lstinline@$S$#$T$@ are the base classes of $T$
-in $B$ seen from the prefix type $S$.
-\end{itemize}
-
-2. The notion of a type $T$
-{\em in class $C$ seen from some prefix type
-$S\,$} makes sense only if the prefix type $S$
-has a type instance of class $C$ as a base class, say
-~\lstinline@$S'$#$C$[$T_1 \commadots T_n$]@. Then we define as follows.
-\begin{itemize}
- \item 
-  If \lstinline@$S$ = $\epsilon$.type@, then $T$ in $C$ seen from $S$ is $T$ itself.
- \item Otherwise, if $T$ is the $i$'th type parameter of some class $D$, then
-   \begin{itemize}
-   \item
-   If $S$ has a base class ~\lstinline@$D$[$U_1 \commadots U_n$]@, for some type parameters
-   ~\lstinline@[$U_1 \commadots U_n$]@, then $T$ in $C$ seen from $S$ is $U_i$.
-   \item
-   Otherwise, if $C$ is defined in a class $C'$, then
-   $T$ in $C$ seen from $S$ is the same as $T$ in $C'$ seen from $S'$.
-   \item
-   Otherwise, if $C$ is not defined in another class, then  
-   $T$ in $C$ seen from $S$ is $T$ itself.
-  \end{itemize}
-\item
-   Otherwise, 
-   if $T$ is the singleton type \lstinline@$D$.this.type@ for some class $D$
-   then
-   \begin{itemize}
-   \item
-   If $D$ is a subclass of $C$ and 
-   $S$ has a type instance of class $D$ among its base classes,
-   then $T$ in $C$ seen from $S$ is $S$.
-   \item
-   Otherwise, if $C$ is defined in a class $C'$, then
-   $T$ in $C$ seen from $S$ is the same as $T$ in $C'$ seen from $S'$.
-   \item
-   Otherwise, if $C$ is not defined in another class, then  
-   $T$ in $C$ seen from $S$ is $T$ itself.
-   \end{itemize}
-\item
-  If $T$ is some other type, then the described mapping is performed
-  to all its type components.
-\end{itemize}
-
-If $T$ is a possibly parameterized class type, where $T$'s class
-is defined in some other class $D$, and $S$ is some prefix type,
-then we use ``$T$ seen from $S$'' as a shorthand for
-``$T$ in $D$ seen from $S$''.
-
-3. The {\em member bindings} of a type $T$ are all bindings $d$ such that
-there exists a type instance of some class $C$ among the base classes of $T$
-and there exists a definition or declaration $d'$ in $C$
-such that $d$ results from $d'$ by replacing every
-type $T'$ in $d'$ by $T'$ in $C$ seen from $T$.
-
-The {\em definition} of a type projection \lstinline@$S$#$t$@ is the member
-binding $d$ of the type $t$ in $S$. In that case, we also say
-that \lstinline@$S$#$t$@ {\em is defined by} $d$.
-
-\section{Relations between types}
-
-We define two relations between types.
-\begin{quote}\begin{tabular}{l@{\gap}l@{\gap}l}
-\em Type equivalence & $T \equiv U$ & $T$ and $U$ are interchangeable
-in all contexts.
-\\
-\em Conformance & $T \conforms U$ & Type $T$ conforms to type $U$.
-\end{tabular}\end{quote}
-
-\subsection{Type Equivalence}
-\label{sec:type-equiv}
-
-Equivalence $(\equiv)$ between types is the smallest congruence\footnote{ A
-congruence is an equivalence relation which is closed under formation
-of contexts} such that the following holds:
-\begin{itemize}
-\item 
-If $t$ is defined by a type alias ~\lstinline@type $t$ = $T$@, then $t$ is
-equivalent to $T$.
-\item
-If a path $p$ has a singleton type ~\lstinline@$q$.type@, then
-~\lstinline@$p$.type $\equiv q$.type@.
-\item
-If $O$ is defined by an object definition, and $p$ is a path
-consisting only of package or object selectors and ending in $O$, then
-~\lstinline@$O$.this.type $\equiv p$.type@.
-\item
-Two compound types are equivalent if their component types are
-pairwise equivalent and their refinements are equivalent. Two
-refinements are equivalent if they bind the same names and the
-modifiers, types and bounds of every declared entity are equivalent in
-both refinements.
-\item
-Two method types are equivalent if they have equivalent result
-types, both have the same number of parameters, and corresponding
-parameters have equivalent types as well as the same \code{def} or
-\lstinline@*@ modifiers.  Note that the names of parameters do not matter
-for method type equivalence.
-\item
-Two polymorphic types are equivalent if they have the same number of
-type parameters, and, after renaming one set of type parameters by
-another, the result types as well as lower and upper bounds of
-corresponding type parameters are equivalent.
-\item
-Two overloaded types are equivalent if for every alternative type in
-either type there exists an equivalent alternative type in the other.
-\end{itemize}
-
-\subsection{Conformance}
-\label{sec:subtyping}
-
-The conformance relation $(\conforms)$ is the smallest 
-transitive relation that satisfies the following conditions.
-\begin{itemize}
-\item Conformance includes equivalence. If $T \equiv U$ then $T \conforms U$.
-\item For every value type $T$, 
-      $\mbox{\code{scala.All}} \conforms T \conforms \mbox{\code{scala.Any}}$. 
-\item For every value type $T \conforms \mbox{\code{scala.AnyRef}}$ 
-      one has $\mbox{\code{scala.AllRef}} \conforms T$.
-\item A type variable or abstract type $t$ conforms to its upper bound and
-      its lower bound conforms to $t$. 
-\item A class type or parameterized type $c$ conforms to any of its base-types, $b$.
-\item A type projection \lstinline@$T$#$t$@ conforms to \lstinline@$U$#$t$@ if 
-      $T$ conforms to $U$.
-\item A parameterized type ~\lstinline@$T$[$T_1 \commadots T_n$]@~ conforms to 
-      ~\lstinline@$T$[$U_1 \commadots U_n$]@~ if
-      the following three conditions hold for $i = 1 \commadots n$. 
-      \begin{itemize}
-      \item
-      If the $i$'th type parameter of $T$ is declared covariant, then $T_i \conforms U_i$.
-      \item
-      If the $i$'th type parameter of $T$ is declared contravariant, then $U_i \conforms T_i$.
-      \item
-      If the $i$'th type parameter of $T$ is declared neither covariant 
-      nor contravariant, then $U_i \equiv T_i$.
-      \end{itemize}
-\item A compound type ~\lstinline@$T_1$ with $\ldots$ with $T_n$ {$R\,$}@~ conforms to
-      each of its component types $T_i$.
-\item If $T \conforms U_i$ for $i = 1 \commadots n$ and for every
-      binding of a type or value $x$ in $R$ there exists a member
-      binding of $x$ in $T$ subsuming it, then $T$ conforms to the
-      compound type ~\lstinline@$U_1$ with $\ldots$ with $U_n$ {$R\,$}@.
-\item If
-        $T_i \equiv T'_i$ for $i = 1 \commadots n$ and $U$ conforms to $U'$ 
-        then the method type $(T_1 \commadots T_n) U$ conforms to
-        $(T'_1 \commadots T'_n) U'$.
-\item If, assuming 
-$L'_1 \conforms a_1 \conforms U'_1 \commadots L'_n \conforms a_n \conforms U'_n$ 
-one has $L_i \conforms L'_i$ and $U'_i \conforms U_i$
-for $i = 1 \commadots n$, as well as $T \conforms T'$, then the polymorphic type
-$[a_1 >: L_1 <: U_1 \commadots a_n >: L_n <: U_n] T$ conforms to the polymorphic type
-$[a_1 >: L'_1 <: U'_1 \commadots a_n >: L'_n <: U'_n] T'$.
-\item 
-An overloaded type $T_1 \overload \ldots \overload T_n$ conforms to each of its alternative types $T_i$.
-\item
-A type $S$ conforms to the overloaded type $T_1 \overload \ldots \overload T_n$
-if $S$ conforms to each alternative type $T_i$.  \todo{Really?}
-\end{itemize}
-
-A declaration or definition in some compound type of class type $C$
-{\em subsumes} another
-declaration of the same name in some compound type or class type $C'$, if one of the following holds.
-\begin{itemize}
-\item
-A value declaration ~\lstinline@val $x$: $T$@~ or value definition
-~\lstinline@val $x$: $T$ = $e$@~ subsumes a value declaration
-~\lstinline@val $x$: $T'$@~ if $T \conforms T'$.
-\item
-A type alias
-$\TYPE;t=T$ subsumes a type alias $\TYPE;t=T'$ if
-$T \equiv T'$.
-\item 
-A type declaration ~\lstinline@type $t$ >: $L$ <: $U$@~ subsumes
-a type declaration ~\lstinline@type $t$ >: $L'$ <: $U'$@~ if $L' \conforms L$ and 
-$U \conforms U'$.
-\item
-A type or class definition of some type $t$ subsumes an abstract
-type declaration ~\lstinline@type t >: L <: U@~ if
-$L \conforms t \conforms U$.
-\end{itemize}
-
-The $(\conforms)$ relation forms a partial order between types. The {\em
-least upper bound} or the {\em greatest lower bound} of a set of types
-is understood to be relative to that order.
-
-\paragraph{Note} The least upper bound of a set of types does not always exist. For instance, consider
-the class definitions
-\begin{lstlisting}
-class A[+t] {}
-class B extends A[B];
-class C extends A[C];
-\end{lstlisting}
-Then the types ~\lstinline@A[Any], A[A[Any]], A[A[A[Any]]], ...@~ form
-a descending sequence of upper bounds for \code{B} and \code{C}. The
-least upper bound would be the infinite limit of that sequence, which
-does not exist as a Scala type. Since cases like this are in general
-impossible to detect, a Scala compiler is free to reject a term
-which has a type specified as a least upper or greatest lower bound,
-and that bound would be more complex than some compiler-set
-limit\footnote{The current Scala compiler limits the nesting level
-of parameterization in such bounds to 10.}.
-
-\section{Type Erasure}
-\label{sec:erasure}
-
-A type is called {\em generic} if it contains type arguments or type variables.
-{\em Type erasure} is a mapping from (possibly generic) types to
-non-generic types. We write $|T|$ for the erasure of type $T$.
-The erasure mapping is defined as follows.
-\begin{itemize}
-\item The erasure of a type variable is the erasure of its upper bound.
-\item The erasure of a parameterized type $T[T_1 \commadots T_n]$ is $|T|$.
-\item The erasure of a singleton type \lstinline@$p$.type@ is the 
-      erasure of the type of $p$.
-\item The erasure of a type projection \lstinline@$T$#$x$@ is \lstinline@|$T$|#$x$@.
-\item The erasure of a compound type ~\lstinline@$T_1$ with $\ldots$ with $T_n$ {$R\,$}@ 
-      is $|T_1|$.
-\item The erasure of every other type is the type itself.
-\end{itemize}
-
-\section{Implicit Conversions}
-\label{sec:impl-conv}
-
-\todo{Include Anything to unit?}
-
-The following implicit conversions are applied to expressions of
-method type that are used as values, rather than being applied to some
-arguments.
-\begin{itemize}
-\item
-A parameterless method $m$ of type \lstinline@=> $T$@
-is converted to type $T$ by evaluating the expression to which $m$ is bound.
-\item
-An expression $e$ of polymorphic type 
-\begin{lstlisting}
-[$a_1$ >: $L_1$ <: $U_1 \commadots a_n$ >: $L_n$ <: $U_n$]$T$
-\end{lstlisting}
-which does not appear as the function part of
-a type application is converted to type $T$
-by determining with local type inference
-(\sref{sec:local-type-inf}) instance types ~\lstinline@$T_1 \commadots T_n$@~ 
-for the type variables ~\lstinline@$a_1 \commadots a_n$@~ and
-implicitly embedding $e$ in the type application
-~\lstinline@$e$[$U_1 \commadots U_n$]@~ (\sref{sec:type-app}).
-\item
-An expression $e$ of monomorphic method type
-$(\Ts_1) \ldots (\Ts_n) U$ of arity $n > 0$
-which does not appear as the function part of an application is
-converted to a function type by implicitly embedding $e$ in
-the following term, where $x$ is a fresh variable and each $ps_i$ is a
-parameter section consisting of parameters with fresh names of types $\Ts_i$:
-\begin{lstlisting}
-(val $x$ = $e$ ; $(ps_1) \ldots \Arrow \ldots \Arrow (ps_n) \Arrow x(ps_1)\ldots(ps_n)$)
-\end{lstlisting}
-This conversion is not applicable to functions with call-by-name
-parameters \lstinline@$x$: => $T$@ or repeated parameters
-\lstinline@x: T*@, (\sref{sec:parameters}), because its result would
-violate the well-formedness rules for anonymous functions
-(\sref{sec:closures}). Hence, methods with such parameters
-always need to be applied to arguments immediately.
-\end{itemize}
-
-When used in an expression, a value of type \code{byte}, \code{char},
-or \code{short} is always implicitly converted to a value of type
-\code{int}.
-
-%If an expression $e$ has type $T$ where $T$ does not conform to the
-%expected type $pt$ and $T$ has a member named \lstinline@coerce@ of type
-%$[]U$ where $U$ does conform to $pt$, then the expression is typed and evaluated is if it was
-%\lstinline@$e$.coerce@.
-
-Implicit conversions can also be user-defined. This is expained in
-Chapter~\ref{sec:views}.
-
-\chapter{Basic Declarations and Definitions}
-\label{sec:defs}
-
-\syntax\begin{lstlisting}
-  Dcl             ::=  val ValDcl
-                    |  var VarDcl
-                    |  def FunDcl
-                    |  type TypeDcl
-  Def             ::=  val PatDef 
-                    |  var VarDef 
-                    |  def FunDef 
-                    |  type TypeDef 
-                    |  TmplDef
-\end{lstlisting}
-
-A {\em declaration} introduces names and assigns them types. It can
-appear as one of the statements of a class definition
-(\sref{sec:templates}) or as part of a refinement in a compound
-type (\ref{sec:refinements}).
-
-A {\em definition} introduces names that denote terms or types. It can
-form part of an object or class definition or it can be local to a
-block.  Both declarations and definitions produce {\em bindings} that
-associate type names with type definitions or bounds, and that
-associate term names with types.
-
-The scope of a name introduced by a declaration or definition is the
-whole statement sequence containing the binding.  However, there is a
-restriction on forward references: In a statement sequence $s_1 \ldots
-s_n$, if a simple name in $s_i$ refers to an entity defined by $s_j$
-where $j \geq i$, then every non-empty statement between and including
-$s_i$ and $s_j$ must be an import clause,
-or a function, type, class, or object definition. It may not be 
-a value definition, a variable definition, or an expression.
-
-\comment{
-Every basic definition may introduce several defined names, separated
-by commas. These are expanded according to the following scheme:
-\bda{lcl}
-\VAL;x, y: T = e && \VAL; x: T = e \\
-                 && \VAL; y: T = x \\[0.5em]
-
-\LET;x, y: T = e && \LET; x: T = e \\
-                 && \VAL; y: T = x \\[0.5em]
-
-\DEF;x, y (ps): T = e &\tab\mbox{expands to}\tab& \DEF; x(ps): T = e \\
-                      && \DEF; y(ps): T = x(ps)\\[0.5em]
-
-\VAR;x, y: T := e && \VAR;x: T := e\\
-                  && \VAR;y: T := x\\[0.5em]
-
-\TYPE;t,u = T && \TYPE; t = T\\
-              && \TYPE; u = t\\[0.5em]
-\eda
-
-All definitions have a ``repeated form'' where the initial
-definition keyword is followed by several constituent definitions
-which are separated by commas.  A repeated definition is
-always interpreted as a sequence formed from the
-constituent definitions. E.g.\ the function definition
-~\lstinline@def f(x) = x, g(y) = y@~ expands to
-~\lstinline@def f(x) = x; def g(y) = y@~ and
-the type definition
-~\lstinline@type T, U <: B@~ expands to
-~\lstinline@type T; type U <: B@.
-}
-\comment{
-If an element in such a sequence introduces only the defined name,
-possibly with some type or value parameters, but leaves out any
-additional parts in the definition, then those parts are implicitly
-copied from the next subsequent sequence element which consists of
-more than just a defined name and parameters. Examples:
-\begin{itemize}
-\item[]
-The variable declaration ~\lstinline@var x, y: int@~ 
-expands to ~\lstinline@var x: int; var y: int@.
-\item[]
-The value definition ~\lstinline@val x, y: int = 1@~ 
-expands to ~\lstinline@val x: int = 1; val y: int = 1@.
-\item[]
-The class definition ~\lstinline@case class X(), Y(n: int) extends Z@~ expands to
-~\lstinline@case class X extends Z; case class Y(n: int) extends Z@.
-\item
-The object definition ~\lstinline@case object Red, Green, Blue extends Color@~
-expands to  
-\begin{lstlisting}
-case object Red extends Color; 
-case object Green extends Color;
-case object Blue extends Color .
-\end{lstlisting}
-\end{itemize}
-}
-\section{Value Declarations and Definitions}
-\label{sec:valdef}
-
-\syntax\begin{lstlisting}
-  Dcl          ::=  val ValDcl
-  ValDcl       ::=  id {`,' id} `:' Type
-  Def          ::=  val PatDef 
-  PatDef       ::=  Pattern2 {`,' Pattern2} [`:' Type] `=' Expr
-\end{lstlisting}
-
-A value declaration ~\lstinline@val $x$: $T$@~ introduces $x$ as a name of a value of
-type $T$.  
-
-A value definition ~\lstinline@val $x$: $T$ = $e$@~ defines $x$ as a name of the
-value that results from the evaluation of $e$. The type $T$ may be
-omitted, in which case the type of expression $e$ is assumed.
-If a type $T$ is given, then $e$ is expected to conform to it.
-
-Evaluation of the value definition implies evaluation of its
-right-hand side $e$.  The effect of the value definition is to bind
-$x$ to the value of $e$ converted to type $T$.
-
-Value definitions can alternatively have a pattern
-(\sref{sec:patterns}) as left-hand side.  If $p$ is some pattern other
-than a simple name or a name followed by a colon and a type, then the
-value definition ~\lstinline@val $p$ = $e$@~ is expanded as follows:
-
-1. If the pattern $p$ has bound variables $x_1 \commadots x_n$, where $n > 1$:
-\begin{lstlisting}
-val $\Dollar x$ = $e$ match {case $p$ => scala.Tuple$n$($x_1 \commadots x_n$)}
-val $x_1$ = $\Dollar x$._1
-$\ldots$
-val $x_n$ = $\Dollar x$._n  .
-\end{lstlisting}
-Here, $\Dollar x$ is a fresh name.  The class
-\lstinline@Tuple$n$@ is defined for $n = 2 \commadots 9$ in package
-\code{scala}.
-
-2. If $p$ has a unique bound variable $x$:
-\begin{lstlisting}
-val $x$ = $e$ match { case $p$ => $x$ }
-\end{lstlisting}
-
-3. If $p$ has no bound variables:
-\begin{lstlisting}
-$e$ match { case $p$ => ()}
-\end{lstlisting}
-
-\example
-The following are examples of value definitions
-\begin{lstlisting}
-val pi = 3.1415;
-val pi: double = 3.1415;  // equivalent to first definition
-val Some(x) = f();        // a pattern definition
-val x :: xs = mylist;     // an infix pattern definition
-\end{lstlisting}
-
-The last two definitions have the following expansions.
-\begin{lstlisting}
-val x = f() match { case Some(x) => x }
-
-val x$\Dollar$ = mylist match { case x :: xs => scala.Tuple2(x, xs) }
-val x = x$\Dollar$._1;
-val xs = x$\Dollar$._2;
-\end{lstlisting}
-
-A value declaration ~\lstinline@val $x_1 \commadots x_n$: $T$@~
-is a
-shorthand for the sequence of value declarations
-~\lstinline@val $x_1$: $T$; ...; val $x_n$: $T$@.
-A value definition ~\lstinline@val $p_1 \commadots p_n$ = $e$@~
-is a
-shorthand for the sequence of value definitions
-~\lstinline@val $p_1$ = $e$; ...; val $p_n$ = $e$@.
-A value definition ~\lstinline@val $p_1 \commadots p_n: T$ = $e$@~
-is a
-shorthand for the sequence of value definitions
-~\lstinline@val $p_1: T$ = $e$; ...; val $p_n: T$ = $e$@.
-
-\section{Variable Declarations and Definitions}
-\label{sec:vardef}
-
-\syntax\begin{lstlisting}
-  Dcl            ::=  var VarDcl
-  Def            ::=  var VarDef
-  VarDcl         ::=  id {`,' id} `:' Type
-  VarDef         ::=  id {`,' id} [`:' Type] `=' Expr
-                   |  id {`,' id} `:' Type `=' `_'
-\end{lstlisting}
-
-A variable declaration ~\lstinline@var $x$: $T$@~ is equivalent to declarations
-of a {\em getter function} $x$ and a {\em setter function}
-\lstinline@$x$_=@, defined as follows:
-
-\begin{lstlisting}
-  def $x$: $T$;
-  def $x$_= ($y$: $T$): unit
-\end{lstlisting}
-
-An implementation of a class containing variable declarations
-may define these variables using variable definitions, or it may
-define setter and getter functions directly.
-
-A variable definition ~\lstinline@var $x$: $T$ = $e$@~ introduces a mutable
-variable with type $T$ and initial value as given by the
-expression $e$. The type $T$ can be omitted, 
-in which case the type of $e$ is assumed. If $T$ is given, then $e$ 
-is expected to conform to it.
-
-A variable definition ~\lstinline@var $x$: $T$ = _@~ introduces a mutable
-variable with type \ $T$ and a default initial value. 
-The default value depends on the type $T$ as follows:
-\begin{quote}\begin{tabular}{ll}
-\code{0} & if $T$ is \code{int} or one of its subrange types, \\
-\code{0L} & if $T$ is \code{long},\\
-\lstinline@0.0f@ & if $T$ is \code{float},\\
-\lstinline@0.0d@ & if $T$ is \code{double},\\
-\code{false} & if $T$ is \code{boolean},\\
-\lstinline@()@ & if $T$ is \code{unit}, \\
-\code{null} & for all other types $T$.
-\end{tabular}\end{quote}
-
-When they occur as members of a template, both forms of variable
-definition also introduce a getter function $x$ which returns the
-value currently assigned to the variable, as well as a setter function
-\lstinline@$x$_=@ which changes the value currently assigned to the variable.
-The functions have the same signatures as for a variable declaration.
-The getter and setter functions are then members of the template
-instead of the variable accessed by them.
-
-\example The following example shows how {\em properties} can be
-simulated in Scala. It defines a class \code{TimeOfDayVar} of time
-values with updatable integer fields representing hours, minutes, and
-seconds. Its implementation contains tests that allow only legal
-values to be assigned to these fields. The user code, on the other
-hand, accesses these fields just like normal variables.
-
-\begin{lstlisting}
-class TimeOfDayVar {
-  private var h: int = 0;
-  private var m: int = 0;
-  private var s: int = 0;
-
-  def hours              =  h;
-  def hours_= (h: int)   =  if (0 <= h && h < 24) this.h = h 
-                            else throw new DateError();
-
-  def minutes            =  m;
-  def minutes_= (m: int) =  if (0 <= m && m < 60) this.m = m
-                            else throw new DateError();
-
-  def seconds            =  s;
-  def seconds_= (s: int) =  if (0 <= s && s < 60) this.s = s
-                            else throw new DateError();
-}
-val d = new TimeOfDayVar;
-d.hours = 8; d.minutes = 30; d.seconds = 0;
-d.hours = 25;                 // throws a DateError exception
-\end{lstlisting}
-
-A variable declaration ~\lstinline@var $x_1 \commadots x_n$: $T$@~
-is a
-shorthand for the sequence of variable declarations
-~\lstinline@var $x_1$: $T$; ...; var $x_n$: $T$@.
-A variable definition ~\lstinline@var $x_1 \commadots x_n$ = $e$@~
-is a
-shorthand for the sequence of variable definitions
-~\lstinline@var $x_1$ = $e$; ...; var $x_n$ = $e$@.
-A variable definition ~\lstinline@var $x_1 \commadots x_n: T$ = $e$@~
-is a
-shorthand for the sequence of variable definitions
-~\lstinline@var $x_1: T$ = $e$; ...; var $x_n: T$ = $e$@.
-
-\section{Type Declarations and Type Aliases}
-\label{sec:typedcl}
-\label{sec:typealias}
-
-\syntax\begin{lstlisting}
-  Dcl             ::=  type TypeDcl
-  TypeDcl         ::=  id [>: Type] [<: Type]
-  Def             ::=  type TypeDef
-  TypeDef         ::=  id [TypeParamClause] `=' Type
-\end{lstlisting}
-
-A {\em type declaration} ~\lstinline@type $t$ >: $L$ <: $U$@~ declares $t$ to
-be an abstract type with lower bound type $L$ and upper bound
-type $U$.  If such a declaration appears as a member declaration
-of a type, implementations of the type may implement $t$ with any
-type $T$ for which $L \conforms T \conforms U$. Either or both bounds may
-be omitted.  If the lower bound $L$ is missing, the bottom type
-\lstinline@scala.All@ is assumed.  If the upper bound $U$ is missing,
-the top type \lstinline@scala.Any@ is assumed.
-
-A {\em type alias} ~\lstinline@type $t$ = $T$@~ defines $t$ to be an alias
-name for the type $T$.  The left hand side of a type alias may
-have a type parameter clause, e.g. ~\lstinline@type $t$[$\tps\,$] = $T$@.  The scope
-of a type parameter extends over the right hand side $T$ and the
-type parameter clause $\tps$ itself.  
-
-The scope rules for definitions (\sref{sec:defs}) and type parameters
-(\sref{sec:funsigs}) make it possible that a type name appears in its
-own bound or in its right-hand side.  However, it is a static error if
-a type alias refers recursively to the defined type constructor itself.  
-That is, the type $T$ in a type alias ~\lstinline@type $t$[$\tps\,$] = $T$@~ may not refer
-directly or indirectly to the name $t$.  It is also an error if
-an abstract type is directly or indirectly its own upper or lower bound.
-
-\example The following are legal type declarations and definitions:
-\begin{lstlisting}
-type IntList = List[Integer];
-type T <: Comparable[T];
-type Two[a] = Tuple2[a, a];
-\end{lstlisting}
-
-The following are illegal:
-\begin{lstlisting}
-type Abs = Comparable[Abs];       // recursive type alias
-
-type S <: T;                      // S, T are bounded by themselves.
-type T <: S;
-
-type T <: AnyRef with T;          // T is abstract, may not be part of
-                                  // compound type
-
-type T >: Comparable[T.That];     // Cannot select from T.
-                                  // T is a type, not a value
-\end{lstlisting}
-
-If a type alias ~\lstinline@type $t$[$\tps\,$] = $S$@~ refers to a class type
-$S$, the name $t$ can also be used as a constructor for
-objects of type $S$.
-
-\example The \code{Predef} module contains a definition which establishes \code{Pair} 
-as an alias of the parameterized class \code{Tuple2}:
-\begin{lstlisting}
-type Pair[+a, +b] = Tuple2[a, b];
-\end{lstlisting}
-As a consequence, for any two types $S$ and $T$, the type
-~\lstinline@Pair[$S$, $T\,$]@~ is equivalent to the type ~\lstinline@Tuple2[$S$, $T\,$]@.
-\code{Pair} can also be used as a constructor instead of \code{Tuple2}, as in
-\begin{lstlisting}
-new Pair[Int, Int](1, 2) .
-\end{lstlisting}
-
-\section{Type Parameters}\label{sec:type-params}
-
-\syntax\begin{lstlisting}
-  TypeParamClause  ::=  `[' VarTypeParam {`,' VarTypeParam} `]'
-  VarTypeParam     ::=  [`+' | `-'] TypeParam
-  TypeParam        ::=  id [>: Type] [<: Type | <% Type]
-\end{lstlisting}
-
-
-Type parameters appear in type definitions, class definitions, and
-function definitions.  In this section we consider only type parameter
-definitions with lower bounds ~\lstinline@>: $L$@~ and upper bounds
-~\lstinline@<: $U$@~ whereas a discussion of view bounds
-~\lstinline@<% $U$@~ are deferred to Section~\ref{sec:view-bounds}.
-
-The most general form of a type parameter is
-~\lstinline@$\pm t$ >: $L$ <: $U$@.  Here, $L$, and $U$ are lower
-and upper bounds that constrain possible type arguments for the
-parameter, and $\pm$ is a {\em variance}, i.e.\ an optional prefix 
-of either \lstinline@+@, or \lstinline@-@.
-
-\comment{
-The upper bound $U$ in a type parameter clauses may not be a final
-class. The lower bound may not denote a value type.\todo{Why}
-}
-The names of all type parameters in a type parameter clause must be
-pairwise different.  The scope of a type parameter includes in each
-case the whole type parameter clause. Therefore it is possible that a
-type parameter appears as part of its own bounds or the bounds of
-other type parameters in the same clause.  However, a type parameter
-may not be bounded directly or indirectly by itself.
-
-\example Here are some well-formed type parameter clauses:
-\begin{lstlisting}
-[s, t]
-[ex <: Throwable]
-[a <: Ord[b], b <: a]
-[a, b, c >: a <: b]
-\end{lstlisting}
-The following type parameter clauses are illegal
-since type parameter are bounded by themselves.
-\begin{lstlisting}
-[a >: a]                 
-[a <: b, b <: c, c <: a]
-\end{lstlisting}
-
-Variance annotations indicate how type instances with the given type
-parameters vary with respect to subtyping (\sref{sec:subtyping}).  A
-`\lstinline@+@' variance indicates a covariant dependency, a `\lstinline@-@'
-variance indicates a contravariant dependency, and a missing variance
-indication indicates an invariant dependency.
-
-A variance annotation constrains the way the annotated type variable
-may appear in the type or class which binds the type parameter.  In a
-type definition ~\lstinline@type $t$[$\tps\,$] = $S$@, type parameters labeled
-`\lstinline@+@' must only appear in covariant position in $S$ whereas
-type parameters labeled `\lstinline@-@' must only appear in contravariant
-position. Analogously, for a class definition
-~\lstinline@class $c$[$\tps\,$]($ps\,$): $s$ extends $t$@, type parameters labeled
-`\lstinline@+@' must only appear in covariant position in the self type
-$s$ and the template $t$, whereas type
-parameters labeled `\lstinline@-@' must only appear in contravariant
-position. 
-
-The variance position of a type parameter in a type or template is
-defined as follows.  Let the opposite of covariance be contravariance,
-and the opposite of invariance be itself.  The top-level of the type
-or template is always in covariant position. The variance position
-changes at the following constructs.
-\begin{itemize}
-\item
-The variance position of a method parameter is the opposite of the 
-variance position of the enclosing parameter clause.
-\item
-The variance position of a type parameter is the opposite of the
-variance position of the enclosing type parameter clause.
-\item
-The variance position of the lower bound of a type declaration or type parameter 
-is the opposite of the variance position of the type declaration or parameter.  
-\item
-The right hand side $S$ of a type alias ~\lstinline@type $t$[$\tps\,$] = $S$@~ 
-is always in invariant position.
-\item
-The type of a mutable variable is always in invariant position.
-\item 
-The prefix $S$ of a type selection \lstinline@$S$#$T$@ is always in invariant position.
-\item
-For a type argument $T$ of a type ~\lstinline@$S$[$\ldots T \ldots$ ]@: If the
-corresponding type parameter is invariant, then $T$ is in
-invariant position.  If the corresponding type parameter is
-contravariant, the variance position of $T$ is the opposite of
-the variance position of the enclosing type ~\lstinline@$S$[$\ldots T \ldots$ ]@.
-\end{itemize}
-
-\example The following variance annotation is legal. 
-\begin{lstlisting}
-abstract class P[+a, +b] {
-  def fst: a; def snd: b
-}
-\end{lstlisting}
-With this variance annotation, elements
-of type $P$ subtype covariantly with respect to their arguments. 
-For instance, 
-\begin{lstlisting}
-P[IOException, String] <: P[Throwable, AnyRef] .
-\end{lstlisting}
-
-If we make the elements of $P$ mutable, 
-the variance annotation becomes illegal. 
-\begin{lstlisting}
-abstract class Q[+a, +b] { 
-  var fst: a;           // **** error: illegal variance:
-  var snd: b            // `a', `b' occur in invariant position.
-}
-\end{lstlisting}
-
-\example The following variance annotation is illegal, since $a$ appears
-in contravariant position in the parameter of \code{append}:
-
-\begin{lstlisting}
-trait Vector[+a] {
-  def append(x: Vector[a]): Vector[a]; 
-                        // **** error: illegal variance: 
-                        // `a' occurs in contravariant position.
-}
-\end{lstlisting} 
-The problem can be avoided by generalizing the type of \code{append}
-by means of a lower bound:
-
-\begin{lstlisting}
-trait Vector[+a] {
-  def append[b >: a](x: Vector[b]): Vector[b];
-}
-\end{lstlisting}
-
-\example Here is a case where a contravariant type parameter is useful.
-
-\begin{lstlisting}
-trait OutputChannel[-a] {
-  def write(x: a): unit
-}
-\end{lstlisting}
-With that annotation, we have that
-\lstinline@OutputChannel[AnyRef]@ conforms to \lstinline@OutputChannel[String]@.  
-That is, a
-channel on which one can write any object can substitute for a channel
-on which one can write only strings.
-
-\section{Function Declarations and Definitions}
-\label{sec:defdef}
-\label{sec:funsigs}
-\label{sec:parameters}
-
-\syntax\begin{lstlisting} 
-Dcl                ::=  def FunDcl
-FunDcl             ::=  FunSig {`,' FunSig} `:' Type 
-Def                ::=  def FunDef
-FunDef             ::=  FunSig {`,' FunSig} [`:' Type] `=' Expr 
-FunSig             ::=  id [FunTypeParamClause] {ParamClause} 
-FunTypeParamClause ::= `[' TypeParam {`,' TypeParam} `]' 
-ParamClause        ::= `(' [Param {`,' Param}] `)' 
-Param              ::=  id `:' [`=>'] Type [`*']
-\end{lstlisting}
-
-A function declaration has the form ~\lstinline@def $f \psig$: $T$@, where
-$f$ is the function's name, $\psig$ is its parameter
-signature and $T$ is its result type. A function definition
-~\lstinline@$f \psig$: $T$ = $e$@~ also includes a {\em function body} $e$,
-i.e.\ an expression which defines the function's result.  A parameter
-signature consists of an optional type parameter clause \lstinline@[$\tps\,$]@,
-followed by zero or more value parameter clauses
-~\lstinline@($ps_1$)$\ldots$($ps_n$)@.  Such a declaration or definition
-introduces a value with a (possibly polymorphic) method type whose
-parameter types and result type are as given.
-
-A type parameter clause $\tps$ consists of one or more type
-declarations (\sref{sec:typedcl}), which introduce type parameters,
-possibly with bounds.  The scope of a type parameter includes
-the whole signature, including any of the type parameter bounds as
-well as the function body, if it is present.  
-
-A value parameter clause $ps$ consists of zero or more formal
-parameter bindings such as \lstinline@$x$: $T$@, which bind value
-parameters and associate them with their types.  The scope of a formal
-value parameter name $x$ is the function body, if one is
-given. Both type parameter names and value parameter names must be
-pairwise distinct.
-
-The type of a value parameter may be prefixed by \code{=>}, e.g.\
-~\lstinline@$x$: => $T$@. The type of such a parameter is then the
-parameterless method type ~\lstinline@=> $T$@. This indicates that the
-corresponding argument is not evaluated at the point of function
-application, but instead is evaluated at each use within the
-function. That is, the argument is evaluated using {\em call-by-name}.
-
-\example The declaration
-\begin{lstlisting}
-def whileLoop (cond: => Boolean) (stat: => Unit): Unit
-\end{lstlisting}
-indicates that both parameters of \code{whileLoop} are evaluated using
-call-by-name.
-
-The last value parameter of a parameter section may be suffixed by
-``\code{*}'', e.g.\ ~\lstinline@(..., $x$:$T$*)@.  The type of such a
-{\em repeated} parameter inside the method is then the sequence type
-\lstinline@scala.Seq[$T$]@.  Methods with repeated parameters
-\lstinline@$T$*@ take a variable number of arguments of type $T$.  That is,
-if a method $m$ with type ~\lstinline@($T_1 \commadots T_n, S$*)$U$@~
-is applied to arguments $(e_1 \commadots e_k)$ where $k \geq n$, then
-$m$ is taken in that application to have type $(T_1 \commadots T_n, S
-\commadots S)U$, with $k - n$ occurrences of type $S$.  
-\todo{Change to ???: If the method
-is converted to a function type instead of being applied immediately,
-a repeated parameter \lstinline@$T$*@ is taken to be ~\lstinline@scala.Seq[$T$]@~
-instead.}
-
-\example The following method definition computes the sum of a variable number
-of integer arguments.
-\begin{lstlisting}
-def sum(args: int*) {
-  var result = 0;
-  for (val arg <- args.elements) result = result + arg;
-  result
-}
-\end{lstlisting}
-The following applications of this method yield \code{0}, \code{1},
-\code{6}, in that order.
-\begin{lstlisting}
-sum()
-sum(1)
-sum(1, 2, 3, 4, 5)
-\end{lstlisting}
-
-
-The type of the function body must conform to the function's declared
-result type, if one is given. If the function definition is not
-recursive, the result type may be omitted, in which case it is
-determined from the type of the function body.
-
-For any index $i$ let $\fsig_i$ be a function signature consisting of a function
-name, an optional type parameter section, and zero or more parameter
-sections.  Then a function declaration 
-~\lstinline@def $\fsig_1 \commadots \fsig_n$: $T$@~ 
-is a shorthand for the sequence of function
-declarations ~\lstinline@def $\fsig_1$: $T$; ...; def $\fsig_n$: $T$@.  
-A function definition ~\lstinline@def $\fsig_1 \commadots \fsig_n$ = $e$@~ is a
-shorthand for the sequence of function definitions 
-~\lstinline@def $\fsig_1$ = $e$; ...; def $\fsig_n$ = $e$@.  
-A function definition
-~\lstinline@def $\fsig_1 \commadots \fsig_n: T$ = $e$@~ is a shorthand for the
-sequence of function definitions 
-~\lstinline@def $\fsig_1: T$ = $e$; ...; def $\fsig_n: T$ = $e$@.
-
-\section{Overloaded Definitions}
-\label{sec:overloaded-defs}
-\todo{change}
-
-An overloaded definition is a set of $n > 1$ value or function
-definitions in the same statement sequence that define the same name,
-binding it to types ~\lstinline@$T_1 \commadots T_n$@, respectively.
-The individual definitions are called {\em alternatives}.  Overloaded
-definitions may only appear in the statement sequence of a template.
-Alternatives always need to specify the type of the defined entity
-completely.  It is an error if the types of two alternatives $T_i$ and
-$T_j$ have the same erasure (\sref{sec:erasure}).
-
-\todo{Say something about bridge methods.}
-%This must be a well-formed
-%overloaded type
-
-\section{Import Clauses}
-\label{sec:import}
-
-\syntax\begin{lstlisting}
-  Import          ::= import ImportExpr {`,' ImportExpr}
-  ImportExpr      ::= StableId `.' (id | `_' | ImportSelectors)
-  ImportSelectors ::= `{' {ImportSelector `,'} 
-                      (ImportSelector | `_') `}'
-  ImportSelector  ::= id [`=>' id | `=>' `_']
-\end{lstlisting}
-
-An import clause has the form ~\lstinline@import $p$.$I$@~ where $p$ is a stable
-identifier (\sref{sec:paths}) and $I$ is an import expression.
-The import expression determines a set of names of members of $p$
-which are made available without qualification. The most general form
-of an import expression is a list of {\em import selectors}
-\begin{lstlisting}
-{ $x_1$ => $y_1 \commadots x_n$ => $y_n$, _ }
-\end{lstlisting}
-for $n \geq 0$, where the final wildcard `\lstinline@_@' may be absent.  It
-makes available each member \lstinline@$p$.$x_i$@ under the unqualified name
-$y_i$. I.e.\ every import selector ~\lstinline@$x_i$ => $y_i$@~ renames
-\lstinline@$p$.$x_i$@ to
-$y_i$.  If a final wildcard is present, all members $z$ of
-$p$ other than ~\lstinline@$x_1 \commadots x_n$@~ are also made available
-under their own unqualified names.
-
-Import selectors work in the same way for type and term members. For
-instance, an import clause ~\lstinline@import $p$.{$x$ => $y\,$}@~ renames the term
-name \lstinline@$p$.$x$@ to the term name $y$ and the type name \lstinline@$p$.$x$@
-to the type name $y$. At least one of these two names must
-reference a member of $p$.
-
-If the target in an import selector is a wildcard, the import selector
-hides access to the source member. For instance, the import selector
-~\lstinline@$x$ => _@~ ``renames'' $x$ to the wildcard symbol (which is
-unaccessible as a name in user programs), and thereby effectively
-prevents unqualified access to $x$. This is useful if there is a
-final wildcard in the same import selector list, which imports all
-members not mentioned in previous import selectors.
-
-Several shorthands exist. An import selector may be just a simple name
-$x$. In this case, $x$ is imported without renaming, so the
-import selector is equivalent to ~\lstinline@$x$ => $x$@. Furthermore, it is
-possible to replace the whole import selector list by a single
-identifier or wildcard. The import clause ~\lstinline@import $p$.$x$@~ is
-equivalent to ~\lstinline@import $p$.{$x\,$}@~, i.e.\ it makes available without
-qualification the member $x$ of $p$. The import clause
-~\lstinline@import $p$._@~ is equivalent to
-~\lstinline@import $p$.{_}@, 
-i.e.\ it makes available without qualification all members of $p$
-(this is analogous to ~\lstinline@import $p$.*@~ in Java).
-
-An import clause with multiple import expressions
-~\lstinline@import $p_1$.$I_1 \commadots p_n$.$I_n$@~ is interpreted as a
-sequence of import clauses 
-~\lstinline@import $p_1$.$I_1$; $\ldots$; import $p_n$.$I_n$@.
-
-\example Consider the object definition:
-\begin{lstlisting}
-object M { 
-  def z = 0, one = 1; 
-  def add(x: Int, y: Int): Int = x + y 
-}
-\end{lstlisting}
-Then the block
-\begin{lstlisting}
-{ import M.{one, z => zero, _}; add(zero, one) }
-\end{lstlisting}
-is equivalent to the block 
-\begin{lstlisting}
-{ M.add(M.z, M.one) } .
-\end{lstlisting}
-
-\chapter{Classes and Objects}
-\label{sec:globaldefs}
-
-\syntax\begin{lstlisting}
-  TmplDef          ::=  ([case] class | trait) ClassDef
-                    |  [case] object ObjectDef
-\end{lstlisting}
-
-Classes (\sref{sec:classes}) and objects
-(\sref{sec:modules}) are both defined in terms of {\em templates}.
-
-\section{Templates}
-\label{sec:templates}
-
-\syntax\begin{lstlisting}
-  Template        ::=  Constr {`with' Constr} [TemplateBody]
-  TemplateBody    ::=  `{' [TemplateStat {`;' TemplateStat}] `}'
-\end{lstlisting}
-
-A template defines the type signature, behavior and initial state of a
-class of objects or of a single object. Templates form part of
-instance creation expressions, class definitions, and object
-definitions.  A template
-~\lstinline@$sc$ with $mc_1$ with $\ldots$ with $mc_n$ {$\stats\,$}@~
-consists of a constructor invocation $sc$
-which defines the template's {\em superclass}, constructor invocations
-~\lstinline@$mc_1 \commadots mc_n$@~ $(n \geq 0)$, which define the
-template's {\em mixin classes}, and a statement sequence $\stats$ which
-contains additional member definitions for the template.  Superclass
-and mixin classes together are called the {\em parent classes} of a
-template.  They must be pairwise different.  The superclass of a
-template must be a subtype of the superclass of each mixin class.  The
-{\em least proper supertype} of a template is the class type or
-compound type (\sref{sec:compound-types}) consisting of the its parent
-classes.
-
-\todo{introduce ScalaObject}
-
-Member definitions define new members or overwrite members in the
-parent classes.  If the template forms part of a class definition,
-the statement part $\stats$ may also contain declarations of abstract members.
-%The type of each non-private definition or declaration of a
-%template must be equivalent to a type which does not refer to any
-%private members of that template.
-
-\todo{Make all references to Java generic}
-
-\paragraph{Inheriting from Java Types} A template may have a Java class as
-its superclass and Java interfaces as its mixin classes. On the other
-hand, it is not permitted to have a Java class as a mixin class, or a
-Java interface as a superclass.
-
-\subsection{Constructor Invocations}
-\label{sec:constr-invoke}
-\syntax\begin{lstlisting}
-  Constr  ::=  StableId [TypeArgs] [`(' [Exprs] `)']  
-\end{lstlisting}
-
-Constructor invocations define the type, members, and initial state of
-objects created by an instance creation expression, or of parts of an
-object's definition which are inherited by a class or object
-definition. A constructor invocation is a function application
-\lstinline@$x$.$c$($\args\,$)@, where $x$ is a stable identifier
-(\sref{sec:stable-ids}), $c$ is a type name which either
-designates a class or defines an alias type for one, and $\args$
-is an argument list, which matches one of the constructors of that
-class. The prefix `\lstinline@$x$.@' can be omitted. 
-%The class $c$ must conform to \lstinline@scala.AnyRef@, 
-%i.e.\ it may not be a value type.  
-The argument list \lstinline@($\args\,$)@ can also be omitted, in which case an
-empty argument list \lstinline@()@ is implicitly added.
-
-\subsection{Base Classes}
-\label{sec:base-classes}
-
-For every template, class type and constructor invocation we define
-two sets of class types: the {\em base classes} and {\em mixin base
-classes}. Their definitions are as follows.
-
-The {\em mixin base classes} of a template 
-~\lstinline@$sc$ with $mc_1$ with $\ldots$ with $mc_n$ {$\stats\,$}@~ 
-are 
-the reduced union (\sref{sec:base-classes-member-defs}) of the base classes of all
-mixins $mc_i$. The mixin base classes of a class type $C$ are the
-mixin base classes of the template augmented by $C$ itself. The
-mixin base classes of a constructor invocation of type $T$ are the
-mixin base classes of class $T$.
-
-The {\em base classes} of a template consist are the reduced union of
-the base classes of its superclass and the template's mixin base
-classes.  The base classes of class \lstinline@scala.Any@ consist of
-just the class itself. The base classes of some other class type $C$
-are the base classes of the template represented by $C$ augmented by
-$C$ itself.  The base classes of a constructor invocation of type $T$
-are the base classes of $T$.
-
-The notions of mixin base classes and base classes are extended from
-classes to arbitrary types following the definitions of
-\sref{sec:base-classes-member-defs}.
-
-\comment{
-If two types in the base class sequence of a template refer to the
-same class definition, then that definition must define a trait
-(\sref{sec:traits}), and the type that comes later in the sequence must
-conform to the type that comes first. 
-(\sref{sec:base-classes-member-defs}).
-}
-
-\example 
-Consider the following class definitions:
-\begin{lstlisting}
-class A;
-class B extends A;
-trait C extends A;
-class D extends A;
-class E extends B with C with D;
-class F extends B with D with E;
-\end{lstlisting} 
-The mixin base classes and base classes of classes \code{A-F} are given in
-the following table:
-\begin{quote}\begin{tabular}{|l|l|l|} \hline
- \ & Mixin base classes & Base classes \\  \hline
-A & A & A, ScalaObject, AnyRef, Any \\
-B & B & B, A, ScalaObject, AnyRef, Any \\
-C & C & C, A, ScalaObject, AnyRef, Any \\
-D & D & D, A, ScalaObject, AnyRef, Any \\
-E & C, D, E & E, B, C, D, A, ScalaObject, AnyRef, Any \\
-F & C, D, E, F & F, B, D, E, C, A, ScalaObject, AnyRef, Any \\ \hline
-\end{tabular}\end{quote}
-Note that \code{D} is inherited twice by \code{F}, once directly, the
-other time indirectly through \code{E}. This is permitted, since
-\code{D} is a trait.
-
-
-\subsection{Evaluation}
-
-The evaluation of a template or constructor invocation depends on
-whether the template defines an object or is a superclass of a
-constructed object, or whether it is used as a mixin for a defined
-object.  In the second case, the evaluation of a template used as a
-mixin depends on an {\em actual superclass}, which is known at the
-point where the template is used in a definition of an object, but not
-at the point where it is defined. The actual superclass is used in the
-determination of the meaning of \code{super} (\sref{sec:this-super}).
-
-We therefore define two notions of template evaluation: (Plain)
-evaluation (as a defining template or superclass) and mixin evaluation
-with a given superclass $sc$. These notions are defined for templates
-and constructor invocations as follows.
-
-A {\em mixin evaluation with superclass $sc$} of a template
-~\lstinline@$sc'$ with $mc_1$ with $mc_n$ {$\stats\,$}@~ consists of mixin
-evaluations with superclass $sc$ of the mixin constructor invocations
-~\lstinline@$mc_1 \commadots mc_n$@~ in the order they are given, followed by an
-evaluation of the statement sequence $\stats$.  Within $\stats$ the
-actual superclass refers to $sc$.  A mixin evaluation with superclass
-$sc$ of a class constructor invocation \code{ci} consists of an evaluation
-of the constructor function and its arguments in the order they are
-given, followed by a mixin evaluation with superclass $sc$ of the
-template represented by the constructor invocation.
-
-An {\em evaluation} of a template
-~\lstinline@$sc$ with $mc_1$ with $mc_n$ with ($\stats\,$)@~ consists of an evaluation of
-the superclass constructor invocation $sc$,
-followed by a mixin evaluation with superclass $sc$ of the template. An
-evaluation of a class constructor invocation \code{ci} consists of an
-evaluation of the constructor function and its arguments in
-the order they are given, followed by an evaluation of the template
-represented by the constructor invocation.
-
-\subsection{Template Members}
-
-\label{sec:members}
-
-The object resulting from evaluation of a template has directly bound
-members and inherited members. Members can be abstract or concrete.
-For a template $T$ these categories are defined as follows. 
-\begin{enumerate}
-\item
-A {\em directly bound} member of $T$ is an entity introduced by a member
-definition or declaration in $T$'s statement sequence. The
-member is called {\em abstract} if it is introduced by a declaration,
-{\em concrete} otherwise.
-\item
-A {\em concrete inherited} member of $T$ is a non-private, concrete member of
-one of $T$'s parent classes, except if a member with the same name is
-already directly bound in $T$ or the member is mixin-overridden in
-$T$. A member $m$ of $T$'s superclass is {\em mixin-overridden} in $T$
-if there is a concrete member of a mixin base class of $T$ which
-either overrides $m$ itself or overrides a member named $m$ of a base
-class of $T$'s superclass.
-\item
-An {\em abstract inherited} member of $T$ is a non-private, abstract member
-of one of $T$'s parent classes $P_i$, except if the template has a
-directly bound or concrete inherited member with the same name, or the
-template has an abstract member inherited from a parent class $P_j$ where
-$j > i$\todo{OK to leave out?: , and which has the same modifiers and type as the member
-inherited from $P_j$ would have in $T$}.
-\end{enumerate}
-It is an error if a template has more than one member with
-the same name. 
-
-
-
-\comment{
-The type of a member $m$ is determined as follows: If $m$ is defined
-in $\stats$, then its type is the type as given in the member's
-declaration or definition. Otherwise, if $m$ is inherited from the
-base class ~\lstinline@$B$[$T_1$, $\ldots$. $T_n$]@, $B$'s class declaration has formal
-parameters ~\lstinline@[$a_1 \commadots a_n$]@, and $M$'s type in $B$ is $U$, then
-$M$'s type in $C$ is ~\lstinline@$U$[$a_1$ := $T_1 \commadots a_n$ := $T_n$]@.
-
-\ifqualified{
-Members of templates have internally qualified names $Q\qex x$ where
-$x$ is a simple name and $Q$ is either the empty name $\epsilon$, or
-is a qualified name referencing the module or class that first
-introduces the member. A basic declaration or definition of $x$ in a
-module or class $M$ introduces a member with the following qualified
-name:
-\begin{enumerate}
-\item
-If the binding is labeled with an ~\lstinline@override $Q$@\notyet{Override
-  with qualifier} modifier,
-where $Q$ is a fully qualified name of a base class of $M$, then the
-qualified name is the qualified expansion (\sref{sec:names}) of $x$ in
-$Q$.
-\item
-If the binding is labeled with an \code{override} modifier without a
-base class name, then the qualified name is the qualified expansion
-of $x$ in $M$'s least proper supertype (\sref{sec:templates}).
-\item
-An implicit \code{override} modifier is added and case (2) also
-applies if $M$'s least proper supertype contains an abstract member
-with simple name $x$.
-\item
-If no \code{override} modifier is given or implied, then if $M$ is
-labeled \code{qualified}, the qualified name is $M\qex x$. If $M$ is
-not labeled \code{qualified}, the qualified name is $\epsilon\qex x$.
-\end{enumerate}
-}
-}
-
-\example Consider the class definitions
-
-\begin{lstlisting}
-class A { def f: Int = 1 ; def g: Int = 2 ; def h: Int = 3 }
-abstract class B { def f: Int = 4 ; def g: Int }
-abstract class C extends A with B { def h: Int }
-\end{lstlisting}
-
-Then class \code{C} has a directly bound abstract member \code{h}. It
-inherits member \code{f} from class \code{B} and member \code{g} from
-class \code{A}.
-
-\ifqualified{
-\example\label{ex:compound-b}
-Consider the definitions:
-\begin{lstlisting}
-qualified class Root extends Any { def r1: Root, r2: Int }
-qualified class A extends Root { def r1: A, a: String }
-qualified class B extends A { def r1: B, b: Double }
-\end{lstlisting}
-Then ~\lstinline@A with B@~ has members
-\lstinline@Root::r1@ of type \code{B}, \lstinline@Root::r2@ of type \code{Int},
-\lstinline@A::a:@ of type \code{String}, and \lstinline@B::b@ of type \code{Double},
-in addition to the members inherited from class \code{Any}.
-}
-
-\subsection{Overriding}
-\label{sec:overriding}
-
-A template member $M$ that has the same \ifqualified{qualified} name
-as a non-private member $M'$ of a base class (and that belongs to the
-same namespace) is said to {\em override} that member.  In this case
-the binding of the overriding member $M$ must subsume
-(\sref{sec:subtyping}) the binding of the overridden member $M'$.
-Furthermore, the overridden definition may not be a class definition.
-Method definitions may only override other method definitions (or the
-methods implicitly defined by a variable definition). They may not
-override value definitions.  Finally, the following restrictions
-on modifiers apply to $M$ and $M'$:
-\begin{itemize}
-\item
-$M'$ must not be labeled \code{final}.
-\item
-$M$ must not be labeled \code{private}.
-\item
-If $M$ is labeled \code{protected}, then $M'$ must also be
-labeled \code{protected}.
-\item
-If $M'$ is not an abstract member, then
-$M$ must be labeled \code{override}.
-\item
-If $M'$ is labeled \code{abstract} and \code{override}, and $M'$ is a
-member of the static superclass of the class containing the definition
-of $M$, then $M$ must also be labeled \code{abstract} and
-\code{override}.
-\end{itemize}
-
-\example\label{ex:compound-a}
-Consider the definitions:
-\begin{lstlisting}
-trait Root { type T <: Root }
-trait A extends Root { type T <: A }
-trait B extends Root { type T <: B }
-trait C extends A with B;
-\end{lstlisting}
-Then the trait definition \code{C} is not well-formed because the
-binding of \code{T} in \code{C} is
-~\lstinline@type T <: B@,
-which fails to subsume the binding ~\lstinline@type T <: A@~ of \code{T}
-in type \code{A}. The problem can be solved by adding an overriding 
-definition of type \code{T} in class \code{C}:
-\begin{lstlisting}
-class C extends A with B { type T <: C }
-\end{lstlisting}
-
-\subsection{Modifiers}
-\label{sec:modifiers}
-
-\syntax\begin{lstlisting}
-  Modifier        ::=  LocalModifier
-                    |  private
-                    |  protected
-                    |  override 
-  LocalModifier   ::=  abstract
-                    |  final
-                    |  sealed
-\end{lstlisting}
-
-Member definitions may be preceded by modifiers which affect the
-\ifqualified{qualified names, }accessibility and usage of the
-identifiers bound by them.  If several modifiers are given, their
-order does not matter, but the same modifier may not occur repeatedly.
-Modifiers preceding a repeated definition apply to all constituent
-definitions.  The rules governing the validity and meaning of a
-modifier are as follows.
-\begin{itemize}
-\item
-The \code{private} modifier can be used with any definition in a
-template. Private members can be accessed only from within the template
-that defines them.  
-%Furthermore, accesses are not permitted in
-%packagings (\sref{sec:topdefs}) other than the one containing the
-%definition. 
-Private members are not inherited by subclasses and they
-may not override definitions in parent classes.
-\code{private} may not be applied to abstract members, and it
-may not be combined in one modifier list with
-\code{protected}, \code{final} or \code{override}.
-\item
-The \code{protected} modifier applies to class member definitions.
-Protected members can be accessed from within the template of the defining
-class as well as in all templates that have the defining class as a base class.
-%Furthermore, accesses from the template of the defining class are not
-%permitted in packagings other than the one
-%containing the definition.  
-A protected identifier $x$ may be used as
-a member name in a selection \lstinline@$r$.$x$@ only if $r$ is one of the reserved
-words \code{this} and
-\code{super}, or if $r$'s type conforms to a type-instance of the class
-which contains the access.
-\item
-The \code{override} modifier applies to class member definitions.  It
-is mandatory for member definitions that override some other concrete
-member definition in a super- or mixin-class. If an \code{override}
-modifier is given, there must be at least one overridden member
-definition.  
-
-The \code{override} modifier has an additional significance when
-combined with the \code{abstract} modifier.  That modifier combination
-is only allowed for members of abstract classes.  A member
-labeled \code{abstract} and \code{override} must override some
-member of the superclass of the class containing the definition.
-
-We call a member of a template {\em incomplete} if it is either
-abstract (i.e.\ defined by a declaration), or it is labeled
-\code{abstract} and \code{override} and it overrides an incomplete
-member of the template's superclass.
-
-Note that the \code{abstract override} modifier combination does not
-influence the concept whether a member is concrete or
-abstract. A member for which only a declaration is given is abstract,
-whereas a member for which a full definition is given is concrete.
-
-\item
-The \code{abstract} modifier is used in class definitions. It is
-mandatory if the class has incomplete members.  Abstract classes
-cannot be instantiated (\sref{sec:inst-creation}) with a constructor
-invocation unless followed by mixin constructors or statements which
-override all incomplete members of the class.
-
-The \code{abstract} modifier can also be used in conjunction with
-\code{override} for class member definitions. In that case the meaning
-of the previous discussion applies.
-\item
-The \code{final} modifier applies to class member definitions and to
-class definitions. A \code{final} class member definition may not be
-overridden in subclasses. A \code{final} class may not be inherited by
-a template. \code{final} is redundant for object definitions.  Members
-of final classes or objects are implicitly also final, so the
-\code{final} modifier is redundant for them, too.  \code{final} may
-not be applied to incomplete members, and it may not be combined in one
-modifier list with \code{private} or \code{sealed}.
-\item
-The \code{sealed} modifier applies to class definitions. A
-\code{sealed} class may not be inherited, except if either
-\begin{itemize}
-\item
-the inheriting template is nested within the definition of the sealed
-class itself, or
-\item
-the inheriting template belongs to a class or object definition which
-forms part of the same statement sequence as the definition of the
-sealed class.
-\end{itemize}
-\end{itemize}
-
-\example A useful idiom to prevent clients of a class from
-constructing new instances of that class is to declare the class
-\code{abstract} and \code{sealed}:
-
-\begin{lstlisting}
-object m {
-  abstract sealed class C (x: Int) {
-    def nextC = C(x + 1) {}
-  }
-  val empty = new C(0) {}
-}
-\end{lstlisting}
-For instance, in the code above clients can create instances of class
-\lstinline@m.C@ only by calling the \code{nextC} method of an existing \lstinline@m.C@
-object; it is not possible for clients to create objects of class
-\lstinline@m.C@ directly. Indeed the following two lines are both in error:
-
-\begin{lstlisting}
-  m.C(0)    // **** error: C is abstract, so it cannot be instantiated.
-  m.C(0) {} // **** error: illegal inheritance from sealed class.
-\end{lstlisting}
-
-\subsection{Attributes}
-
-\syntax\begin{lstlisting}
-  AttributeClause ::=  `[' Attribute {`,' Attribute} `]'
-  Attribute       ::=  Constr
-\end{lstlisting}
-
-Attributes associate meta-information with definitions.  A simple
-attribute clause has the form $[C]$ or $[C(a_1 \commadots a_n)]$.
-Here, $c$ is a constructor of a class $C$, which must comform to the
-class \lstinline@scala.Attribute@. All given constructor arguments
-$a_1 \commadots a_n$ must be constant expressions. An attribute clause
-applies to the first definition or declaration following it. More than
-one attribute clause may precede a definition and declaration. The
-order in which these clauses are given does not matter.  It is also
-possible to combine several attributres separated by commas in one
-clause. Such a combined clause $[A_1 \commadots A_n]$ is equivalent to
-a set of clauses $[A_1] \ldots [A_n]$.
-
-The meaning of attribute clauses is implementation-dependent. On the
-Java platform, the following attributes have a standard meaning.\bigskip
-
-\lstinline@transient@
-\begin{quote}
-Marks a field to be non-persistent; this is
-equivalent to the \lstinline@transient@
-modifier in Java.
-\end{quote}
-
-\lstinline@volatile@
-\begin{quote}Marks a field which can change its value
-outside the control of the program; this
-is equivalent to the \lstinline@volatile@
-modifier in Java.
-\end{quote}
-
-\lstinline@Serializable@
-\begin{quote}Marks a class to be serializable; this is
-equivalent to inheriting from the 
-\lstinline@java.io.Serializable@ interface
-in Java.
-\end{quote}
-
-\lstinline@SerialVersionUID(<longlit>)@
-\begin{quote}Attaches a serial version identifier (a
-\lstinline@long@ constant) to a class.
-This is equivalent to a the following field
-definition in Java:
-\begin{lstlisting}[language=Java]
-  private final static SerialVersionUID = <longlit>;
-\end{lstlisting}
-\end{quote}
-
-
-\section{Class Definitions}
-\label{sec:classes}
-
-\syntax\begin{lstlisting} 
-  TmplDef          ::= class ClassDef 
-  ClassDef         ::= ClassSig {`,' ClassSig} [`:' SimpleType] ClassTemplate 
-  ClassSig         ::= id [TypeParamClause] [ClassParamClause] 
-  ClassTemplate    ::= extends Template | TemplateBody |
-  ClassParamClause ::= `(' [ClassParam {`,' ClassParam}] `)'
-  ClassParam       ::= [{Modifier} `val'] Param
-\end{lstlisting}
-
-The most general form of class definition is 
-~\lstinline@class $c$[$\tps\,$]($ps\,$): $s$ extends $t$@.
-Here,
-\begin{itemize}
-\item[]
-$c$ is the name of the class to be defined.
-\item[] $\tps$ is a non-empty list of type parameters of the class
-being defined.  The scope of a type parameter is the whole class
-definition including the type parameter section itself.  It is
-illegal to define two type parameters with the same name.  The type
-parameter section \lstinline@[$\tps\,$]@ may be omitted. A class with a type
-parameter section is called {\em polymorphic}, otherwise it is called
-{\em monomorphic}.
-\item[] 
-$ps$ is a formal value parameter clause for the {\em primary
-constructor} of the class. The scope of a formal value parameter includes
-the template $t$. However, a formal value parameter may not form 
-part of the types of any of the parent classes or members of $t$.
-It is illegal to define two formal value parameters with the same name.
-The formal parameter section \lstinline@($ps\,$)@ may be omitted, in which case
-an empty parameter section \lstinline@()@ is assumed.
-
-If a formal parameter declaration $x: T$ is preceded by a \code{val}
-keyword, an accessor definition for this parameter is implicitly added
-to the class. The accessor introduces a value member $x$ of $c$ that is
-defined as alias of the parameter. The formal paremter declaration may
-contain modifiers, which then carry over to the accessor definition.
-\item[] 
-$s$ is the {\em self type} of the class. Inside the
-class, the type of \code{this} is assumed to be $s$.  The self
-type must conform to the self types of all classes which are inherited
-by the template $t$. The self type declaration `\lstinline@:$s$@' may be
-omitted, in which case the self type of the class is assumed to be
-equal to \lstinline@$c$[$\tps\,$]@.
-\item[] 
-$t$ is a
-template (\sref{sec:templates}) of the form
-\begin{lstlisting}
-$sc$ with $mc_1$ with $\ldots$ with $mc_n$ { $\stats$ }   $\gap(n \geq 0)$
-\end{lstlisting}
-which defines the base classes, behavior and initial state of objects of
-the class. The extends clause ~\lstinline@extends $sc$@~ 
-can be omitted, in which case
-~\lstinline@extends scala.AnyRef@~ is assumed.  The class body
-~\lstinline@{$\stats\,$}@~ may also be omitted, in which case the empty body
-\lstinline@{}@ is assumed.
-\end{itemize}
-This class definition defines a type \lstinline@$c$[$\tps\,$]@ and a constructor
-which when applied to parameters conforming to types $ps$
-initializes instances of type \lstinline@$c$[$\tps\,$]@ by evaluating the template
-$t$.
-
-For any index $i$ let $\csig_i$ be a class signature consisting of a class
-name and optional type parameter and value parameter sections. Let $ct$
-be a class template.
-Then a class definition 
-~\lstinline@class $\csig_1 \commadots \csig_n$ $ct$@~ 
-is a shorthand for the sequence of class definitions
-~\lstinline@class $\csig_1$ $ct$; ...; class $\csig_n$ $ct$@.
-A class definition 
-~\lstinline@class $\csig_1 \commadots \csig_n: T$ $ct$@~ 
-is a shorthand for the sequence of class definitions
-~\lstinline@class $\csig_1: T$ $ct$; ...; class $\csig_n: T$ $ct$@.
-
-\subsection{Constructor Definitions}\label{sec:constr-defs}
-
-\syntax\begin{lstlisting}
-  FunDef          ::=  this ParamClause`=' ConstrExpr
-  ConstrExpr      ::=  this ArgumentExprs
-                    |  `{' this ArgumentExprs {`;' BlockStat} `}'
-\end{lstlisting}
-
-A class may have additional constructors besides the primary
-constructor.  These are defined by constructor definitions of the form
-~\lstinline@def this($ps\,$) = $e$@.  Such a definition introduces an
-additional constructor for the enclosing class, with parameters as
-given in the formal parameter list $ps$, and whose evaluation is
-defined by the constructor expression $e$.  The scope of each formal
-parameter is the constructor expression $e$.  A constructor expression
-is either a self constructor invocation \lstinline@this($\args\,$)@ or
-a block which begins with a self constructor invocation.  Neither the
-signature, nor the self constructor invocation of a constructor
-definition may refer to \verb@this@, or refer to value parameters or
-members of the enclosing class by simple name.
-
-If there are auxiliary constructors of a class $C$, they define
-together with $C$'s primary constructor an overloaded constructor
-value. The usual rules for overloading resolution
-(\sref{sec:overloaded-defs}) apply for constructor invocations of $C$,
-including the self constructor invocations in the constructor
-expressions themselves. To prevent infinite cycles of constructor
-invocations, there is the restriction that every self constructor
-invocation must refer to a constructor definition which precedes it
-(i.e. it must refer to either a preceding auxiliary constructor or the
-primary constructor of the class).  The type of a constructor
-expression must be always so that a generic instance of the class is
-constructed.  I.e., if the class in question has name $C$ and type
-parameters \lstinline@[$\tps\,$]@, then each constructor must construct an
-instance of \lstinline@$C$[$\tps\,$]@; it is not permitted to instantiate formal
-type parameters.
-
-\example Consider the class definition
-
-\begin{lstlisting}
-class LinkedList[a]() {
-  var head = _;
-  var tail = null;
-  def isEmpty = tail != null;  
-  def this(head: a) = { this(); this.head = head; }
-  def this(head: a, tail: List[a]) = { this(head); this.tail = tail }
-}
-\end{lstlisting}
-This defines a class \code{LinkedList} with an overloaded constructor of type
-\begin{lstlisting}
-[a](): LinkedList[a]   $\overload$
-[a](x: a): LinkedList[a]    $\overload$
-[a](x: a, xs: LinkedList[a]): LinkedList[a]  .
-\end{lstlisting}
-The second constructor alternative constructs an singleton list, while the
-third one constructs a list with a given head and tail.
-
-\subsection{Case Classes}
-\label{sec:case-classes}
-
-\syntax\begin{lstlisting} 
-  TmplDef  ::=  case class ClassDef
-\end{lstlisting}
-
-If a class definition is prefixed with \code{case}, the class is said
-to be a {\em case class}.  The primary constructor of a case class may
-be used in a constructor pattern (\sref{sec:patterns}).  
-The following four restrictions ensure efficient pattern matching for
-case classes.
-\begin{enumerate}
-\item None of the base classes of a case class may be a case
-class. 
-\item No type may have two different case classes among its base types. 
-\item A case class may not inherit indirectly from a
-\lstinline@sealed@ class.  That is, if a base class $b$ of a case class $c$
-is marked \lstinline@sealed@, then $b$ must be a parent class of $c$.
-\item
-The primary constructor of a case class may not have any call-by-name
-parameters (\sref{sec:parameters}).
-\end{enumerate}
-
-A case class definition of ~\lstinline@$c$[$\tps\,$]($ps\,$)@~ with type
-parameters $\tps$ and value parameters $ps$ implicitly
-generates a function definition for a {\em case class factory}
-together with the class definition itself:
-\begin{lstlisting}
-def c[$\tps\,$]($ps\,$): $s$ = new $c$[$\tps\,$]($ps\,$)
-\end{lstlisting}
-(Here, $s$ is the self type of class $c$. 
-If a type parameter section
-is missing in the class, it is also missing in the factory
-definition).  
-
-All formal value parameters of a case class are implicitly prefixed
-with a \code{val} keyword. Therefore, accessor definitions
-(\sref{sec:classes}) for such parameters are generated.
-
-Also implicitly defined are accessor member definitions
-in the class that return its value parameters. Every binding
-$x: T$ in the parameter section leads to a value definition of
-$x$ that defines $x$ to be an alias of the parameter.  
-%Every
-%parameterless function binding \lstinline@def x: T@ leads to a
-%parameterless function definition of $x$ which returns the result
-%of invoking the parameter function.  
-%The case class may not contain a
-%directly bound member with the same simple name as one of its value
-%parameters.
-
-Every case class implicitly overrides some method definitions of class
-\lstinline@scala.AnyRef@ (\sref{sec:cls-object}) unless a definition of the same
-method is already given in the case class itself or a concrete
-definition of the same method is given in some base class of the case
-class different from \code{AnyRef}. In particular:
-\begin{itemize}
-\item[] Method ~\lstinline@equals: (Any)boolean@~ is structural equality, where two
-instances are equal if they belong to the same class and
-have equal (with respect to \code{equals}) primary constructor arguments.
-\item[] Method ~\lstinline@hashCode: ()int@~ computes a hash-code
-depending on the data structure in a way which maps equal (with respect to
-\code{equals}) values to equal hash-codes.
-\item[] Method ~\lstinline@toString: ()String@~ returns a string representation which
-contains the name of the class and its primary constructor arguments.
-\end{itemize}
-
-\example Here is the definition of abstract syntax for lambda
-calculus:
-
-\begin{lstlisting}
-class Expr;
-case class
-  Var       (x: String)              extends Expr,
-  Apply     (f: Expr, e: Expr)       extends Expr,
-  Lambda    (x: String, e: Expr)     extends Expr;
-\end{lstlisting}
-This defines a class \code{Expr} with case classes
-\code{Var}, \code{Apply} and \code{Lambda}. A call-by-value evaluator for lambda
-expressions could then be written as follows.
-
-\begin{lstlisting}
-type Env = String => Value;
-case class Value(e: Expr, env: Env);
-
-def eval(e: Expr, env: Env): Value = e match {
-  case Var (x) =>
-    env(x)
-  case Apply(f, g) =>
-    val Value(Lambda (x, e1), env1) = eval(f, env);
-    val v = eval(g, env);
-    eval (e1, (y => if (y == x) v else env1(y)))
-  case Lambda(_, _) =>
-    Value(e, env)
-}
-\end{lstlisting}
-
-It is possible to define further case classes that extend type
-\code{Expr} in other parts of the program, for instance
-\begin{lstlisting}
-case class Number(x: Int) extends Expr;
-\end{lstlisting}
-
-This form of extensibility can be excluded by declaring the base class
-\code{Expr} \code{sealed}; in this case, the only classes permitted to
-extend \code{Expr} are those which are nested inside \code{Expr}, or
-which appear in the same statement sequence as the definition of
-\code{Expr}.
-
-\section{Traits}
-
-\label{sec:traits}
-
-\syntax\begin{lstlisting}
-  TmplDef          ::=  trait ClassDef
-\end{lstlisting}
-
-A class definition which starts with the reserved word \code{trait}
-instead of \code{class} defines a trait. A trait is a specific
-kind of an abstract class, so the \code{abstract} modifier is
-redundant for it.  The trait definition must satisfy the following
-four restrictions.
-\begin{enumerate}
-\item There are no value parameters in the trait's primary constructor, nor
-      are there secondary constructors.
-\item All mixin base classes of the trait are traits.
-\item All parent class constructors of the trait
-      are primary constructors with empty value
-      parameter lists. 
-\item All non-empty statements in the trait's template are either
-      imports or pure definitions.
-\end{enumerate}
-A {\em pure} definition can be evaluated without any side effect.
-Function, type, class, or object definitions are always pure. A value
-definition is pure if its right-hand side expression is pure. A
-secondary constructor definition is pure if its right-hand side 
-consists only
-Pure
-expressions are paths, literals, and typed expressions $e: T$ where
-$e$ is pure.
-
-These restrictions ensure that the evaluation of the mixin constructor
-of a trait has no effect. Therefore, traits may appear several times 
-in the base classes of a template, whereas other classes cannot.
-%\item Packagings may add interface classes as new base classes to an
-%existing class or module.
-
-\example\label{ex:comparable}
-The following trait class defines the property of being
-ordered, i.e. comparable to objects of some type. It contains an abstract method
-\lstinline@<@ and default implementations of the other comparison operators
-\lstinline@<=@, \lstinline@>@, and \lstinline@>=@.
-
-\begin{lstlisting}
-trait Ord[t <: Ord[t]]: t {
-  def < (that: t): Boolean;
-  def <=(that: t): Boolean = this < that || this == that;
-  def > (that: t): Boolean = that < this;
-  def >=(that: t): Boolean = that <= this;
-}
-\end{lstlisting}
-
-\section{Object Definitions}
-\label{sec:modules}
-\label{sec:object-defs}
-
-\syntax\begin{lstlisting}
-  ObjectDef       ::=  id {`,' id} [`:' SimpleType] ClassTemplate
-\end{lstlisting}
-
-An object definition defines a single object of a new class. Its 
-most general form is
-~\lstinline@object $m$: $s$ extends $t$@. Here,
-\begin{itemize}
-\item[]
-$m$ is the name of the object to be defined.
-\item[] $s$ is the {\em self type} of the object. References to $m$
-are assumed to have type $s$. Furthermore, inside the template $t$,
-the type of \code{this} is also assumed to be $s$.  The type of the
-anonymous class defined by $t$ must conform to $s$ and $s$ must
-conform to the self types of all classes which are inherited by
-$t$. The self type declaration `$:s$' may be omitted, in which case
-the self type is assumed to be equal to the anonymous class defined by
-$t$.
-\item[] 
-$t$ is a
-template (\sref{sec:templates}) of the form
-\begin{lstlisting}
-$sc$ with $mc_1$ with $\ldots$ with $mc_n$ { $\stats$ }
-\end{lstlisting}
-which defines the base classes, behavior and initial state of $m$.
-The extends clause ~\lstinline@extends $sc$@~
-can be omitted, in which case
-~\lstinline@extends scala.AnyRef@~ is assumed.  The class body
-~\lstinline@{$\stats\,$}@~ may also be omitted, in which case the empty body
-\lstinline@{}@ is assumed.
-\end{itemize}
-The object definition defines a single object (or: {\em module})
-conforming to the template $t$.  It is roughly equivalent to a class
-definition and a value definition that creates an object of the class:
-\begin{lstlisting}
-final class $m\Dollar$cls: $s$ extends $t$;
-final val $m$: $s$ = new m$\Dollar$cls;
-\end{lstlisting}
-(The \code{final} modifiers are omitted if the definition occurs as
-part of a block. The class name \lstinline@$m\Dollar$cls@ is not
-accessible for user programs.)
-
-There are however two differences between an object definition and a
-pair of class and value definitions such as the one given above.  First,
-object definitions may appear as top-level definitions in a
-compilation unit, whereas value definitions may not.  Second, the
-module defined by an object definition is instantiated lazily.  The
-~\lstinline@new $m\Dollar$cls@~ constructor is evaluated not at the point
-of the object definition, but is instead evaluated the first time $m$
-is dereferenced during execution of the program (which might be never
-at all). An attempt to dereference $m$ again in the course of
-evaluation of the constructor leads to a infinite loop or run-time
-error.  Other threads trying to dereference $m$ while the constructor
-is being evaluated block until evaluation is complete.
-
-\example
-Classes in Scala do not have static members; however, an equivalent
-effect can be achieved by an accompanying object definition
-E.g.
-\begin{lstlisting}
-abstract class Point {
-  val x: Double;
-  val y: Double;
-  def isOrigin = (x == 0.0 && y == 0.0);
-}
-object Point {
-  val origin = new Point() { val x = 0.0; val y = 0.0 }
-}
-\end{lstlisting}
-This defines a class \code{Point} and an object \code{Point} which
-contains \code{origin} as a member.  Note that the double use of the
-name \code{Point} is legal, since the class definition defines the name
-\code{Point} in the type name space, whereas the object definition
-defines a name in the term namespace.
-
-This technique is applied by the Scala compiler when interpreting a
-Java class with static members. Such a class $C$ is conceptually seen
-as a pair of a Scala class that contains all instance members of $C$
-and a Scala object that contains all static members of $C$.
-
-Let $ct$ be a class template. 
-Then an object definition 
-~\lstinline@object $x_1 \commadots x_n$ $ct$@~ 
-is a shorthand for the sequence of object definitions
-~\lstinline@object $x_1$ $ct$; ...; object $x_n$ $ct$@.
-An object definition 
-~\lstinline@object $x_1 \commadots x_n: T$ $ct$@~ 
-is a shorthand for the sequence of object definitions
-~\lstinline@object $x_1: T$ $ct$; ...; object $x_n: T$ $ct$@.
-
-
-\comment{
-\example Here's an outline of a module definition for a file system.
-
-\begin{lstlisting}
-module FileSystem {
-  private type FileDirectory;
-  private val dir: FileDirectory
-
-  interface File {
-    def read(xs: Array[Byte])
-    def close: Unit
-  }
-
-  private class FileHandle extends File { $\ldots$ }
-
-  def open(name: String): File = $\ldots$
-}
-\end{lstlisting}
-}
-
-\chapter{Expressions}
-\label{sec:exprs}
-
-\syntax\begin{lstlisting}
-  Expr            ::=  [Bindings `=>'] Expr
-                    |  Expr1
-  Expr1           ::=  if `(' Expr `)' Expr [[`;'] else Expr]
-                    |  try `{' block `}' [catch Expr] [finally Expr]
-                    |  while '(' Expr ')' Expr
-                    |  do Expr [`;'] while `(' Expr ')'
-                    |  for `(' Enumerators `)' [yield] Expr
-                    |  return [Expr]
-                    |  throw Expr
-                    |  [SimpleExpr `.'] id `=' Expr
-                    |  SimpleExpr ArgumentExprs `=' Expr
-                    |  PostfixExpr [`:' Type1]
-                    |  MethodClosure
-  PostfixExpr     ::=  InfixExpr [id]
-  InfixExpr       ::=  PrefixExpr
-                    |  InfixExpr id PrefixExpr
-  PrefixExpr      ::=  [`-' | `+' | `~' | `!'] SimpleExpr 
-  SimpleExpr      ::=  Literal
-                    |  Path
-                    |  `(' [Expr] `)'
-                    |  BlockExpr
-                    |  new Template 
-                    |  SimpleExpr `.' id 
-                    |  SimpleExpr TypeArgs
-                    |  SimpleExpr ArgumentExprs
-                    |  XmlExpr
-  ArgumentExprs   ::=  `(' [Exprs] ')'
-                    |  BlockExpr
-  MethodClosure   ::=  `.' Id {`.' Id | TypeArgs | ArgumentExprs}
-  BlockExpr       ::=  `{' CaseClause {CaseClause} `}'
-                    |  `{' Block `}'
-  Block           ::=  {BlockStat `;'} [ResultExpr]
-  ResultExpr      ::=  Expr1
-                    |  Bindings `=>' Block
-  Exprs           ::=  Expr {`,' Expr}
-\end{lstlisting}
-
-Expressions are composed of operators and operands. Expression forms are
-discussed subsequently in decreasing order of precedence. 
-
-The typing of expressions is often relative to some {\em expected
-type}.  When we write ``expression $e$ is expected to conform to
-type $T$'', we mean: (1) the expected type of $e$ is
-$T$, and (2) the type of expression $e$ must conform to
-$T$.
-
-\section{Literals}
-
-\syntax\begin{lstlisting}
-  SimpleExpr    ::=  Literal
-  Literal       ::=  intLit
-                  |  floatLit
-                  |  charLit
-                  |  stringLit
-                  |  symbolLit
-                  |  true
-                  |  false
-                  |  null
-\end{lstlisting}
-
-Typing and evaluation of numeric, character, and string literals are
-generally as in Java.  An integer literal denotes an integer
-number. Its type is normally \code{int}. However, if the expected type
-$\proto$ of the expression is either \code{byte}, \code{short}, or
-\code{char} and the integer number fits in the numeric range defined
-by the type, then the number is converted to type $\proto$ and the
-expression's type is $\proto$.  A floating point literal denotes a
-single-precision or double precision IEEE floating point number. A
-character literal denotes a Unicode character. A string literal
-denotes a member of \lstinline@String@.
-
-A symbol literal ~\lstinline@'$x$@~ is a shorthand for the expression
-~\lstinline@scala.Symbol("$x$")@. If the symbol literal is followed by
-actual parameters, as in ~\lstinline@'$x$($\args\,$)@, then the whole
-expression is taken to be a shorthand for
-~\lstinline@scala.Symbol("$x$", $\args\,$)@.
-
-The boolean truth values are denoted by the reserved words \code{true}
-and \code{false}. The type of these expressions is \code{boolean}, and
-their evaluation is immediate. 
-
-The \code{null} literal is of type \lstinline@scala.AllRef@. It
-denotes a reference value which refers to a special ``null' object,
-which implements methods in class \lstinline@scala.AnyRef@ as follows:
-\begin{itemize}
-\item
-\lstinline@eq($x\,$)@, \lstinline@==($x\,$)@, \lstinline@equals($x\,$)@ return \code{true} iff their
-argument $x$ is also the ``null'' object.
-\item
-\lstinline@isInstanceOf[$T\,$]@ always returns \code{false}.
-\item
-\lstinline@asInstanceOf[$T\,$]@ returns the ``null'' object itself if
-$T$ conforms to \lstinline@scala.AnyRef@, and throws a
-\lstinline@NullPointerException@ otherwise.
-\item
-\code{toString()} returns the string ``null''.
-\end{itemize}
-A reference to any other member of the ``null'' object causes a
-\code{NullPointerException} to be thrown. 
-
-\section{Designators}
-\label{sec:designators}
-
-\syntax\begin{lstlisting}
-  Designator  ::=  Path
-                |  SimpleExpr `.' id
-\end{lstlisting}
-
-A designator refers to a named term. It can be a {\em simple name} or
-a {\em selection}. If $r$ is a stable identifier of type $T$, the
-selection $r.x$ refers to the term member of $r$ that is identified in
-$T$ by the name $x$.  For other expressions $e$, $e.x$ is typed as if
-it was $(\VAL;y=e\semi y.x)$ for some fresh name $y$. The typing rules
-for blocks implies that in that case $x$'s type may not refer to any
-abstract type member of $e$.
-
-The expected type of a designator's prefix is always missing.
-The
-type of a designator is normally the type of the entity it refers
-to. However, if the designator is a path (\sref{sec:paths}) $p$,
-its type is \lstinline@$p$.type@, provided the expression's expected type is
-a singleton type, or $p$ occurs as the prefix of a selection
-or type selection.
-
-The selection $e.x$ is evaluated by first evaluating the qualifier
-expression $e$. The selection's result is then the value to which the
-selector identifier is bound in the object resulting from evaluation of $e$.
-
-\section{This and Super}
-\label{sec:this-super}
-
-\syntax\begin{lstlisting}
-  SimpleExpr    ::=  [id `.'] this
-                  |  [id `.'] super [`[' id `]'] `.' id
-\end{lstlisting}
-
-The expression \code{this} can appear in the statement part of a
-template or compound type. It stands for the object being defined by
-the innermost template or compound type enclosing the reference. If
-this is a compound type, the type of \code{this} is that compound type.
-If it is a template of an instance creation expression, the type of
-\code{this} is the type of that template. If it is a template of a
-class or object definition with simple name $C$, the type of this
-is the same as the type of \lstinline@$C$.this@.
-
-The expression \lstinline@$C$.this@ is legal in the statement part of an
-enclosing class or object definition with simple name $C$. It
-stands for the object being defined by the innermost such definition.
-If the expression's expected type is a singleton type, or
-\lstinline@$C$.this@ occurs as the prefix of a selection, its type is
-\lstinline@$C$.this.type@, otherwise it is the self type of class $C$.
-
-A reference \lstinline@super.$m$@ in a template refers to the
-definition of $m$ in the actual superclass (\sref{sec:base-classes})
-of the template.  A reference \lstinline@$C$.super.$m$@ refers to the
-definition of $m$ in the actual superclass of the innermost enclosing
-class or object definition named $C$ which encloses the reference. The
-definition $m$ referred to via \code{super} or \lstinline@$C$.super@
-must be concrete, or the template containing the reference must have an
-incomplete (\sref{sec:modifiers}) member $m'$ which overrides $m$.
-
-The \code{super} prefix may be followed by a mixin qualifier
-\lstinline@[$M\,$]@, as in \lstinline@$C$.super[$M\,$].$x$@. This is called a {\em mixin
-super reference}.  In this case, the reference is to the member of
-$x$ in the (first) mixin class of $C$ whose simple name
-is $M$. That member may not be abstract.
-
-\example\label{ex:super}
-Consider the following class definitions
-
-\begin{lstlisting}
-class Root { val x = "Root" }
-class A extends Root { override val x = "A" ; val superA = super.x }
-class B extends Root { override val x = "B" ; val superB = super.x }
-class C extends A with B { 
-  override val x = "C" ; val superC = super.x 
-}
-class D extends A { val superD = super.x }
-class E extends C with D { val superE = super.x }
-\end{lstlisting}
-Then we have:
-\begin{lstlisting}
-(new A).superA == "Root", (new B).superB == "Root"
-(new C).superA == "Root", (new C).superB == "A", (new C).superC == "A"
-(new D).superA == "Root", (new D).superD == "A"
-(new E).superA == "Root", (new E).superB == "A", (new E).superC == "A",
-   (new E).superD == "C", (new E).superE == "C"
-\end{lstlisting}
-Note that the \code{superB} function returns different results
-depending on whether \code{B} is used as defining class or as a mixin class.
-
-\example Consider the following class definitions:
-\begin{lstlisting}
-class Shape {
-  override def equals(other: Any) = $\ldots$;
-  $\ldots$
-}
-trait Bordered extends Shape {
-  val thickness: int;
-  override def equals(other: Any) = other match {
-    case that: Bordered => 
-      super equals other && this.thickness == that.thickness
-    case _ => false
-  }
-  $\ldots$
-}
-trait Colored extends Shape {
-  val color: Color;
-  override def equals(other: Any) = other match {
-    case that: Colored => 
-      super equals other && this.color == that.color
-    case _ => false
-  }
-  $\ldots$
-}
-\end{lstlisting}
-
-Both definitions of \code{equals} are combined in the class
-below.
-\begin{lstlisting}
-trait BorderedColoredShape extends Shape with Bordered with Colored {
-  override def equals(other: Any) = 
-    super[Bordered].equals(that) && super[Colored].equals(that)
-}
-\end{lstlisting}
-
-\section{Function Applications}
-\label{sec:apply}
-
-\syntax\begin{lstlisting}
-  SimpleExpr    ::=  SimpleExpr ArgumentExprs
-\end{lstlisting}
-
-An application \lstinline@$f$($e_1 \commadots e_n$)@ applies the function $f$ to the
-argument expressions $e_1 \commadots e_n$. If $f$ has a method type
-\lstinline@($T_1 \commadots T_n$)U@, the type of each argument
-expression $e_i$ must conform to the corresponding parameter type
-$T_i$. If $f$ has some value type, the application is taken to be
-equivalent to \lstinline@$f$.apply($e_1 \commadots e_n$)@, i.e.\ the
-application of an \code{apply} method defined by $f$.
-
-%Class constructor functions
-%(\sref{sec:classes}) can only be applied in constructor invocations
-%(\sref{sec:constr-invoke}), never in expressions.
-
-Evaluation of \lstinline@$f$($e_1 \commadots e_n$)@ usually entails evaluation of
-$f$ and $e_1 \commadots e_n$ in that order. Each argument expression
-is converted to the type of its corresponding formal parameter.  After
-that, the application is rewritten to the function's right hand side,
-with actual arguments substituted for formal parameters.  The result
-of evaluating the rewritten right-hand side is finally converted to
-the function's declared result type, if one is given.
-
-The case of a formal parameter with a parameterless
-method type \lstinline@=> $T$@ is treated specially. In this case, the
-corresponding actual argument expression is not evaluated before the
-application. Instead, every use of the formal parameter on the
-right-hand side of the rewrite rule entails a re-evaluation of the
-actual argument expression. In other words, the evaluation order for
-\code{def}-parameters is {\em call-by-name} whereas the evaluation
-order for normal parameters is {\em call-by-value}.
-
-\section{Type Applications}
-\label{sec:type-app}
-\syntax\begin{lstlisting}
-  SimpleExpr    ::=  SimpleExpr `[' Types `]'
-\end{lstlisting}
-
-A type application \lstinline@$e$[$T_1 \commadots T_n$]@ instantiates a
-polymorphic value $e$ of type
-~\lstinline@[$a_1$ >: $L_1$ <: $U_1 \commadots a_n$ >: $L_n$ <: $U_n$]S@~ with
-argument types \lstinline@$T_1 \commadots T_n$@.  Every argument type
-$T_i$ must obey corresponding bounds $L_i$ and
-$U_i$.  That is, for each $i = 1 \commadots n$, we must
-have $L_i \sigma \conforms T_i \conforms U_i \sigma$, where $\sigma$ is the
-substitution $[a_1 := T_1 \commadots a_n := T_n]$.  The type
-of the application is \lstinline@S$\sigma$@.  
-
-The function part $e$ may also have some value type. In this case
-the type application is taken to be equivalent to
-~\lstinline@$e$.apply[$T_1 \commadots$ T$_n$]@, i.e.\ the
-application of an \code{apply} method defined by $e$.
-
-Type applications can be omitted if local type inference
-(\sref{sec:local-type-inf}) can infer best type parameters for a
-polymorphic functions from the types of the actual function arguments
-and the expected result type.
-
-\section{References to Overloaded Bindings}
-\label{sec:overloaded-refs}
-
-If a name $f$ referenced in an identifier or selection is
-overloaded (\sref{sec:overloaded-defs}), the context of the reference
-has to identify a unique alternative of the overloaded binding. The
-way this is done depends on whether or not $f$ is used as a
-function.  Let $\AA$ be the set of all type alternatives of
-$f$.
-
-Assume first that $f$ appears as a function in an application, as
-in \lstinline@$f$($\args\,$)@.  If there is precisely one alternative in
-$\AA$ which is a (possibly polymorphic) method type whose arity
-matches the number of arguments given, that alternative is chosen.
-
-Otherwise, let $\argtypes$ be the vector of types obtained by
-typing each argument with a missing expected type. One determines
-first the set of applicable alternatives. A method type alternative is
-{\em applicable} if each type in $\argtypes$ is compatible with
-the corresponding formal parameter type in the alternative, and, if 
-the expected type is defined, the method's result type is compatible to
-it.  A polymorphic method type is applicable if local type inference
-can determine type arguments so that the instantiated method type is
-applicable.
-
-Here, a type $T$ is {\em compatible} to a type $U$ if $T$
-conforms to $U$ after applying implicit conversions
-(\sref{sec:impl-conv}).
-
-Let $\BB$ be the set of applicable alternatives. It is an error if
-$\BB$ is empty. Otherwise, one chooses the {\em most specific}
-alternative among the alternatives in $\BB$, according to the
-following definition of being ``more specific''.
-\begin{itemize} 
-\item
-A method type \lstinline@($\Ts\,$)$U$@ is more specific than some other
-type $S$ if $S$ is applicable to arguments \lstinline@($ps\,$)@ of
-types $\Ts$.
-\item
-A polymorphic method type
-~\lstinline@[$a_1$ >: $L_1$ <: $U_1 \commadots a_n$ >: $L_n$ <: $U_n$]T@~ is
-more specific than some other type $S$ if $T$ is more
-specific than $S$ under the assumption that for
-$i = 1 \commadots n$ each $a_i$ is an abstract type name
-bounded from below by $L_i$ and from above by $U_i$.
-\item
-Any other type is always more specific than a parameterized method
-type or a polymorphic type.
-\end{itemize}
-It is an error if there is no unique alternative in $\BB$ which is
-more specific than all other alternatives in $\BB$.
-
-Assume next that $f$ appears as a function in a type
-application, as in \lstinline@$f$[$\targs\,$]@. Then we choose an alternative in
-$\AA$ which takes the same number of type parameters as there are
-type arguments in $\targs$. It is an error if no such alternative
-exists, or if it is not unique.
-
-Assume finally that $f$ does not appear as a function in either
-an application or a type application. If an expected type is given,
-let $\BB$ be the set of those alternatives in $\AA$ which are
-compatible to it. Otherwise, let $\BB$ be the same as $\AA$.
-We choose in this case the most specific alternative among all
-alternatives in $\BB$. It is an error if there is no unique
-alternative in $\BB$ which is more specific than all other
-alternatives in $\BB$.
-
-\example Consider the following definitions:
-
-\begin{lstlisting}
-  class A extends B {}
-  def f(x: B, y: B) = $\ldots$
-  def f(x: A, y: B) = $\ldots$
-  val a: A;
-  val b: B
-\end{lstlisting}
-Then the application \lstinline@f(b, b)@ refers to the first
-definition of $f$ whereas the application \lstinline@f(a, a)@
-refers to the second.  Assume now we add a third overloaded definition
-\begin{lstlisting}
-  def f(x: B, y: A) = $\ldots$
-\end{lstlisting}
-Then the application \lstinline@f(a, a)@ is rejected for being ambiguous, since
-no most specific applicable signature exists.
-
-\section{Instance Creation Expressions}
-\label{sec:inst-creation}
-
-\syntax\begin{lstlisting}
-  SimpleExpr     ::=  new Template
-\end{lstlisting}
-
-A simple instance creation expression is of the form ~\lstinline@new $c$@~ 
-where $c$ is a constructor invocation
-(\sref{sec:constr-invoke}).  Let $T$ be the type of $c$. Then $T$ must
-denote a (a type instance of) a non-abstract subclass of
-\lstinline@scala.AnyRef@ which conforms to its self type
-(\sref{sec:classes}). The expression is evaluated by creating a fresh
-object of type $T$ which is is initialized by evaluating $c$. The
-type of the expression is $T$'s self type (which might be less
-specific than $T\,$).
-
-A general instance creation expression is of the form
-\begin{lstlisting}
-new $sc$ with $mc_1$ with $\ldots$ with $mc_n$ {$\stats\,$}
-\end{lstlisting}
-where $n \geq 0$, $sc$ as well as $mc_1 \commadots mc_n$ are
-constructor invocations (of types $S, T_1 \commadots T_n$, say) and
-$\stats$ is a statement sequence containing initializer statements and
-member definitions (\sref{sec:members}). The type of such an instance
-creation expression is then the compound type
-\lstinline@$S$ with $T_1$ with $\ldots$ with $T_n$ {$R\,$}@,
-where \lstinline@{$R\,$}@ is
-a refinement (\sref{sec:compound-types}) which declares exactly those
-members of $\stats$ that override a member of $S$ or $T_1 \commadots
-T_n$. \todo{what about methods and overloaded defs?}  For this type to
-be well-formed, $R$ may not reference types defined in $\stats$ which
-do not themselves form part of $R$.
-
-The instance creation expression is evaluated by creating a fresh
-object, which is initialized by evaluating the expression template.
-
-\example Consider the class
-\begin{lstlisting}
-abstract class C {
-  type T; val x: T; def f(x: T): AnyRef
-}
-\end{lstlisting}
-and the instance creation expression
-\begin{lstlisting}
-C { type T = Int; val x: T = 1; def f(x: T): T = y; val y: T = 2 }
-\end{lstlisting}
-Then the created object's type is:
-\begin{lstlisting}
-C { type T = Int; val x: T; def f(x: T): T }
-\end{lstlisting}
-The value $y$ is missing from the type, since $y$ does not
-override a member of $C$.
-
-\section{Blocks}
-\label{sec:blocks}
-
-\syntax\begin{lstlisting}
-  BlockExpr   ::=  `{' Block `}'
-  Block       ::=  [{BlockStat `;'} ResultExpr]
-\end{lstlisting}
-
-A block expression ~\lstinline@{$s_1$; $\ldots$; $s_n$; $e\,$}@~ is constructed from a
-sequence of block statements $s_1 \commadots s_n$ and a final
-expression $e$. The final expression can be omitted, in which
-case the unit value \lstinline@()@ is assumed.
-
-%Whether or not the scope includes the statement itself
-%depends on the kind of definition.
-
-The expected type of the final expression $e$ is the expected
-type of the block. The expected type of all preceding statements is
-missing.
-
-The type of a block ~\lstinline@$s_1$; $\ldots$; $s_n$; $e$@~ is usually the type of
-$e$.  That type must be equivalent to a type which does not refer
-to an entity defined locally in the block. If this condition is
-violated, but a fully defined expected type is given, the type of the
-block is instead assumed to be the expected type.
-
-Evaluation of the block entails evaluation of its statement sequence,
-followed by an evaluation of the final expression $e$, which
-defines the result of the block.
-
-\example
-Written in isolation, 
-the block 
-\begin{lstlisting}
-{ class C extends B {$\ldots$} ; new C }
-\end{lstlisting}
-is illegal, since its type
-refers to class $C$, which is defined locally in the block.
-
-However, when used in a definition such as 
-\begin{lstlisting}
-val x: B = { class C extends B {$\ldots$} ; new C }
-\end{lstlisting}
-the block is well-formed, since the problematic type $C$ can be
-replaced by the expected type $B$.
-
-\section{Prefix, Infix, and Postfix Operations}
-\label{sec:infix-operations}
-
-\syntax\begin{lstlisting}
-  PostfixExpr     ::=  InfixExpr [id]
-  InfixExpr       ::=  PrefixExpr
-                    |  InfixExpr id PrefixExpr
-  PrefixExpr      ::=  [`-' | `+' | `!' | `~'] SimpleExpr 
-\end{lstlisting}
-
-Expressions can be constructed from operands and operators.  A prefix
-operation $op;e$ consists of a prefix operator $op$, which
-must be one of the identifiers `\lstinline@+@', `\lstinline@-@', `\lstinline@!@', or
-`\lstinline@~@', and a simple expression $e$.  The expression is
-equivalent to the postfix method application $e.op$.
-
-Prefix operators are different from normal function applications in
-that their operand expression need not be atomic. For instance, the
-input sequence \lstinline@-sin(x)@ is read as \lstinline@-(sin(x))@, whereas the
-function application \lstinline@negate sin(x)@ would be parsed as the
-application of the infix operator \code{sin} to the operands
-\code{negate} and \lstinline@(x)@.
-
-An infix or postfix operator can be an arbitrary identifier. Infix
-operators have precedence and associativity defined as follows:
-
-The {\em precedence} of an infix operator is determined by the operator's first
-character. Characters are listed below in increasing order of
-precedence, with characters on the same line having the same precedence.
-\begin{lstlisting}
-        $\mbox{\rm\sl(all letters)}$
-        |
-        ^
-        &
-        < >
-        = !
-        :
-        + -
-        * / %
-        $\mbox{\rm\sl(all other special characters)}$
-\end{lstlisting}
-That is, operators starting with a letter have lowest precedence,
-followed by operators starting with `\lstinline@|@', etc.
-
-The {\em associativity} of an operator is determined by the operator's
-last character.  Operators ending with a colon `\lstinline@:@' are
-right-associative. All other operators are left-associative.
-
-Precedence and associativity of operators determine the grouping of
-parts of an expression as follows.
-\begin{itemize}
-\item If there are several infix operations in an
-expression, then operators with higher precedence bind more closely
-than operators with lower precedence.
-\item If there are consecutive infix
-operations $e_0; \op_1; e_1; \op_2 \ldots \op_n; e_n$ 
-with operators $\op_1 \commadots \op_n$ of the same precedence, 
-then all these operators must
-have the same associativity. If all operators are left-associative,
-the sequence is interpreted as
-$(\ldots(e_0;\op_1;e_1);\op_2\ldots);\op_n;e_n$. 
-Otherwise, if all operators are right-associative, the
-sequence is interpreted as
-$e_0;\op_1;(e_1;\op_2;(\ldots \op_n;e_n)\ldots)$.
-\item
-Postfix operators always have lower precedence than infix
-operators. E.g.\ $e_1;\op_1;e_2;\op_2$ is always equivalent to
-$(e_1;\op_1;e_2);\op_2$.
-\end{itemize}
-A postfix operation $e;\op$ is interpreted as $e.\op$. A
-left-associative binary operation $e_1;\op;e_2$ is interpreted as
-$e_1.\op(e_2)$. If $\op$ is right-associative, the same operation is
-interpreted as ~\lstinline@(val $x$=$e_1$; $e_2$.$\op$($x\,$))@, 
-where $x$ is a fresh name.
-
-\section{Typed Expressions}
-
-\syntax\begin{lstlisting}
-  Expr1              ::=  PostfixExpr [`:' Type1]
-\end{lstlisting}
-
-The typed expression $e: T$ has type $T$. The type of
-expression $e$ is expected to conform to $T$. The result of
-the expression is the value of $e$ converted to type $T$.
-
-\example Here are examples of well-typed and illegally typed expressions.
-
-\begin{lstlisting}
-  1: int               // legal, of type int
-  1: long              // legal, of type long
-  // 1: string         // illegal
-\end{lstlisting}
-
-\section{Method closures}
-\syntax\begin{lstlisting}
-  MethodClosure   ::=  `.' Id {`.' Id | TypeArgs | ArgumentExprs}
-\end{lstlisting}
-
-A method closure $.id$ starts with a period and an identifier, which
-may be followed by selections and type- and value-arguments. This
-expression is equivalenet to an anonymous function
-\lstinline@$x$ => $x.id$@ where $x$ is a fresh parameter name. No type
-for $x$ is given; hence this type needs to be inferrable from the
-context of the expression.
-
-\example The following method returns the $n$'th column of a given
-list of row-lists $xss$, using methods \lstinline@map@,
-\lstinline@drop@ and \lstinline@head@ defined in class
-\lstinline@scala.List@.
-\begin{lstlisting}
-def column[T](xss: List[List[T]], n: int): List[T] = 
-  xss.map(.drop(i)).map(.head)
-\end{lstlisting}
- 
-\section{Assignments}
-
-\syntax\begin{lstlisting}
-  Expr1        ::=  Designator `=' Expr
-                 |  SimpleExpr ArgumentExprs `=' Expr
-\end{lstlisting}
-
-The interpretation of an assignment to a simple variable ~\lstinline@$x$ = $e$@~
-depends on the definition of $x$. If $x$ denotes a mutable
-variable, then the assignment changes the current value of $x$ to be
-the result of evaluating the expression $e$. The type of $e$ is
-expected to conform to the type of $x$. If $x$ is a parameterless
-function defined in some template, and the same template contains a
-setter function \lstinline@$x$_=@ as member, then the assignment
-~\lstinline@$x$ = $e$@~ is interpreted as the invocation
-~\lstinline@$x$_=($e\,$)@~ of that setter function.  Analogously, an
-assignment ~\lstinline@$f.x$ = $e$@~ to a parameterless function $x$
-is interpreted as the invocation ~\lstinline@$f.x$_=($e\,$)@.
-
-An assignment ~\lstinline@$f$($\args\,$) = $e$@~ with a function application to the
-left of the ``\lstinline@=@' operator is interpreted as 
-~\lstinline@$f.$update($\args$, $e\,$)@, i.e.\
-the invocation of an \code{update} function defined by $f$.
-
-\example \label{ex:imp-mat-mul}
-Here is the usual imperative code for matrix multiplication.
-
-\begin{lstlisting}
-def matmul(xss: Array[Array[double]], yss: Array[Array[double]]) = {
-  val zss: Array[Array[double]] = new Array(xss.length, yss.length);
-  var i = 0;
-  while (i < xss.length) {
-    var j = 0;
-    while (j < yss(0).length) {
-      var acc = 0.0;
-      var k = 0;
-      while (k < yss.length) {
-        acc = acc + xs(i)(k) * yss(k)(j);
-        k = k + 1
-      }
-      zss(i)(j) = acc;
-      j = j + 1
-    }
-    i = i + 1
-  }
-  zss
-}
-\end{lstlisting}
-Desugaring the array accesses and assignments yields the following
-expanded version:
-\begin{lstlisting}
-def matmul(xss: Array[Array[double]], yss: Array[Array[double]]) = {
-  val zss: Array[Array[double]] = new Array(xss.length, yss.length);
-  var i = 0;
-  while (i < xss.length) {
-    var j = 0;
-    while (j < yss(0).length) {
-      var acc = 0.0;
-      var k = 0;
-      while (k < yss.length) {
-        acc = acc + xss.apply(i).apply(k) * yss.apply(k).apply(j);
-        k = k + 1
-      }
-      zss.apply(i).update(j, acc);
-      j = j + 1
-    }
-    i = i + 1
-  }
-  zss
-}
-\end{lstlisting}
-
-\section{Conditional Expressions}
-
-\syntax\begin{lstlisting}
-  Expr1          ::=  if `(' Expr `)' Expr [[`;'] else Expr]
-\end{lstlisting}
-
-The conditional expression ~\lstinline@if ($e_1$) $e_2$ else $e_3$@~ chooses
-one of the values of $e_2$ and $e_3$, depending on the
-value of $e_1$. The condition $e_1$ is expected to
-conform to type \code{boolean}.  The then-part $e_2$ and the
-else-part $e_3$ are both expected to conform to the expected
-type of the conditional expression. The type of the conditional
-expression is the least upper bound of the types of $e_1$ and
-$e_2$.  A semicolon preceding the \code{else} symbol of a
-conditional expression is ignored.
-
-The conditional expression is evaluated by evaluating first
-$e_1$. If this evaluates to \code{true}, the result of
-evaluating $e_2$ is returned, otherwise the result of
-evaluating $e_3$ is returned.
-
-A short form of the conditional expression eliminates the
-else-part. The conditional expression ~\lstinline@if ($e_1$) $e_2$@~ is
-evaluated as if it was ~\lstinline@if ($e_1$) $e_2$ else ()@.  The type of
-this expression is \code{unit} and the then-part
-$e_2$ is also expected to conform to type \code{unit}.
-
-\section{While Loop Expressions}
-
-\syntax\begin{lstlisting}
-  Expr1          ::=  while `(' Expr ')' Expr
-\end{lstlisting}
-
-The while loop expression ~\lstinline@while ($e_1$) $e_2$@~ is typed and
-evaluated as if it was an application of ~\lstinline@whileLoop ($e_1$) ($e_2$)@~ where
-the hypothetical function \code{whileLoop} is defined as follows.
-
-\begin{lstlisting}
-  def whileLoop(cond: => Boolean)(body: => Unit): Unit  =
-    if (cond) { body ; while(cond)(body) } else {}
-\end{lstlisting}
-
-\example The loop 
-\begin{lstlisting}
-  while (x != 0) { y = y + 1/x ; x = x - 1 }
-\end{lstlisting}
-Is equivalent to the application
-\begin{lstlisting}
-  whileLoop (x != 0) { y = y + 1/x ; x = x - 1 }
-\end{lstlisting}
-Note that this application will never produce a division-by-zero 
-error at run-time, since the
-expression ~\lstinline@(y = 1/x)@~ will be evaluated in the body of
-\code{while} only if the condition parameter is false.
-
-\section{Do Loop Expressions}
-
-\syntax\begin{lstlisting}
-  Expr1          ::=  do Expr [`;'] while `(' Expr ')'
-\end{lstlisting}
-
-The do loop expression ~\lstinline@do $e_1$ while ($e_2$)@~ is typed and
-evaluated as if it was the expression ~\lstinline@($e_1$ ; while ($e_2$) $e_1$)@.
-A semicolon preceding the \code{while} symbol of a do loop expression is ignored.
-
-\section{Comprehensions}
-
-\syntax\begin{lstlisting}
-  Expr1          ::=  for `(' Enumerators `)' [yield] Expr
-  Enumerator     ::=  Generator {`;' Enumerator}
-  Enumerator     ::=  Generator
-                   |  Expr
-  Generator      ::=  val Pattern1 `<-' Expr
-\end{lstlisting}
-
-A comprehension ~\lstinline@for ($\enums\,$) yield $e$@~ evaluates
-expression $e$ for each binding generated by the enumerators
-$\enums$. Enumerators start with a generator, which can be followed by
-further generators or filters.  A {\em generator} 
-~\lstinline@val $p$ <- $e$@~ 
-produces bindings from an expression $e$ which is matched in
-some way against pattern $p$. A {\em filter} is an expressions which restricts
-enumerated bindings. The precise meaning of generators and filters is
-defined by translation to invocations of four methods: \code{map},
-\code{filter}, \code{flatMap}, and \code{foreach}. These methods can
-be implemented in different ways for different carrier types.  
-\comment{As an
-example, an implementation of these methods for lists is given in
-\sref{cls-list}.}
-
-The translation scheme is as follows. 
-In a first step, every generator ~\lstinline@val $p$ <- $e$@, where $p$ is not
-a pattern variable, is replaced by
-\begin{lstlisting}
-val $p$ <- $e$.filter { case $p$ => true; case _ => false }
-\end{lstlisting}
-Then, the following
-rules are applied repeatedly until all comprehensions have been eliminated.
-\begin{itemize}
-\item
-A generator ~\lstinline@val $p$ <- $e$@~ followed by a filter $f$ is translated to
-a single generator ~\lstinline@val $p$ <- $e$.filter($x_1 \commadots x_n$ => $f\,$)@~ where
-$x_1 \commadots x_n$ are the free variables of $p$.
-
-\item
-A for-comprehension 
-~\lstinline@for (val $p$ <- $e\,$) yield $e'$@~ 
-is translated to
-~\lstinline@$e$.map { case $p$ => $e'$ }@.
-
-\item
-A for-comprehension
-~\lstinline@for (val $p$ <- $e\,$) $e'$@~ 
-is translated to
-~\lstinline@$e$.foreach { case $p$ => $e'$ }@.
-
-\item
-A for-comprehension
-\begin{lstlisting}
-for (val $p$ <- $e$; val $p'$ <- $e'; \ldots$) yield $e''$ ,
-\end{lstlisting}
-where \lstinline@$\ldots$@ is a (possibly empty)
-sequence of generators or filters,
-is translated to
-\begin{lstlisting}
-$e$.flatmap { case $p$ => for (val $p'$ <- $e'; \ldots$) yield $e''$ } .
-\end{lstlisting}
-\item
-A for-comprehension
-\begin{lstlisting}
-for (val $p$ <- $e$; val $p'$ <- $e'; \ldots$) $e''$ .
-\end{lstlisting}
-where \lstinline@$\ldots$@ is a (possibly empty)
-sequence of generators or filters,
-is translated to
-\begin{lstlisting}
-$e$.foreach { case $p$ => for (val $p'$ <- $e'; \ldots$) $e''$ } .
-\end{lstlisting}
-\end{itemize}
-
-\example
-the following code produces all pairs of numbers
-between $1$ and $n-1$ whose sums are prime.
-\begin{lstlisting}
-for  { val i <- range(1, n);
-       val j <- range(1, i);
-       isPrime(i+j)
-} yield Pair (i, j)
-\end{lstlisting}
-The for-comprehension is translated to:
-\begin{lstlisting}
-range(1, n)
-  .flatMap {
-     case i => range(1, i)
-       .filter { j => isPrime(i+j) }
-       .map { case j => Pair(i, j) } }
-\end{lstlisting}
-
-\comment{
-\example
-\begin{lstlisting}
-package class List[a] {
-  def map[b](f: (a)b): List[b] = match {
-    case <> => <>
-    case x :: xs => f(x) :: xs.map(f)
-  }
-  def filter(p: (a)Boolean) = match {
-    case <> => <>
-    case x :: xs => if p(x) then x :: xs.filter(p) else xs.filter(p)
-  }
-  def flatMap[b](f: (a)List[b]): List[b] =
-    if (isEmpty) Nil
-    else f(head) ::: tail.flatMap(f);
-  def foreach(f: (a)Unit): Unit =
-    if (isEmpty) ()
-    else (f(head); tail.foreach(f));
-}
-\end{lstlisting}
-
-\example
-\begin{lstlisting}
-abstract class Graph[Node] {
-  type Edge = (Node, Node)
-  val nodes: List[Node]
-  val edges: List[Edge]
-  def succs(n: Node) = for ((p, s) <- g.edges, p == n) s
-  def preds(n: Node) = for ((p, s) <- g.edges, s == n) p
-}
-def topsort[Node](g: Graph[Node]): List[Node] = {
-  val sources = for (n <- g.nodes, g.preds(n) == <>) n
-  if (g.nodes.isEmpty) <>
-  else if (sources.isEmpty) new Error(``topsort of cyclic graph'') throw
-  else sources :+: topsort(new Graph[Node] {
-    val nodes = g.nodes diff sources
-    val edges = for ((p, s) <- g.edges, !(sources contains p)) (p, s)
-  })
-}
-\end{lstlisting}
-}
-
-\example For comprehensions can be used to express vector 
-and matrix algorithms concisely. 
-For instance, here is a function to compute the transpose of a given matrix:
-
-\begin{lstlisting}
-def transpose[a](xss: Array[Array[a]]) {
-  for (val i <- Array.range(0, xss(0).length)) yield
-    Array(for (val xs <- xss) yield xs(i))
-\end{lstlisting}
-
-Here is a function to compute the scalar product of two vectors:
-\begin{lstlisting}
-def scalprod(xs: Array[double], ys: Array[double]) {
-  var acc = 0.0;
-  for (val Pair(x, y) <- xs zip ys) acc = acc + x * y; 
-  acc
-}
-\end{lstlisting}
-
-Finally, here is a function to compute the product of two matrices. Compare with the imperative version of \ref{ex:imp-mat-mul}.
-\begin{lstlisting}
-def matmul(xss: Array[Array[double]], yss: Array[Array[double]]) = {
-  val ysst = transpose(yss);
-  for (val xs <- xs) yield
-    for (val yst <- ysst) yield 
-      scalprod(xs, yst)
-}
-\end{lstlisting}
-The code above makes use of the fact that \code{map}, \code{flatmap},
-\code{filter}, and \code{foreach} are defined for members of class
-\lstinline@scala.Array@.
-
-\section{Return Expressions}
-
-\syntax\begin{lstlisting}
-  Expr1      ::=  return [Expr]
-\end{lstlisting}
-
-A return expression ~\lstinline@return $e$@~ must occur inside the
-body of some enclosing named method or function $f$. This function
-must have an explicitly declared result type, and the type of $e$ must
-conform to it. The return expression evaluates the expression $e$ and
-returns its value as the result of $f$. The evaluation of any statements or
-expressions following the return expression is omitted. The type of 
-a return expression is \code{scala.All}.
-
-
-
-\section{Throw Expressions}
-
-\syntax\begin{lstlisting}
-  Expr1      ::=  throw Expr
-\end{lstlisting}
-
-A throw expression ~\lstinline@throw $e$@~ evaluates the expression
-$e$. The type of this expression must conform to
-\code{Throwable}.  If $e$ evaluates to an exception
-reference, evaluation is aborted with the thrown exception. If $e$
-evaluates to \code{null}, evaluation is instead aborted with a
-\code{NullPointerException}. If there is an active
-\code{try} expression (\sref{sec:try}) which handles the thrown
-exception, evaluation resumes with the handler; otherwise the thread
-executing the \code{throw} is aborted.  The type of a throw expression
-is \code{scala.All}.
-
-\section{Try Expressions}\label{sec:try}
-
-\syntax\begin{lstlisting}
-  Expr1       ::=  try `{' Block `}' [catch Expr] [finally Expr]
-\end{lstlisting}
-
-A try expression ~\lstinline@try { $b$ } catch $e$@~ evaluates the block
-$b$.  If evaluation of $b$ does not cause an exception to be
-thrown, the result of $b$ is returned. Otherwise the {\em
-handler} $e$ is applied to the thrown exception.  Let $\proto$
-be the expected type of the try expression.  The block $b$ is
-expected to conform to $\proto$.  The handler $e$ is expected
-conform to type ~\lstinline@scala.PartialFunction[scala.Throwable, $\proto\,$]@.
-The type of the try expression is the least upper bound of the type of
-$b$ and the result type of $e$.
-
-A try expression ~\lstinline@try { $b$ } finally $e$@~ evaluates the block
-$b$.  If evaluation of $b$ does not cause an exception to be
-thrown, the expression $e$ is evaluated. If an exception is thrown
-during evaluation of $e$, the evaluation of the try expression is
-aborted with the thrown exception. If no exception is thrown during
-evaluation of $e$, the result of $b$ is returned as the
-result of the try expression. 
-
-If an exception is thrown during
-evaluation of $b$, the finally block
-$e$ is also evaluated. If another exception $e$ is thrown
-during evaluation of $e$, evaluation of the try expression is
-aborted with the thrown exception. If no exception is thrown during
-evaluation of $e$, the original exception thrown in $b$ is
-re-thrown once evaluation of $e$ has completed.  The block
-$b$ is expected to conform to the expected type of the try
-expression. The finally expression $e$ is expected to conform to
-type \code{unit}.
-
-A try expression ~\lstinline@try { $b$ } catch $e_1$ finally $e_2$@~ is a shorthand
-for  ~\lstinline@try { try { $b$ } catch $e_1$ } finally $e_2$@.
-
-
-
-
-\section{Anonymous Functions}
-\label{sec:closures}
-
-\syntax\begin{lstlisting}
-  Expr1           ::=  Bindings `=>' Expr
-  ResultExpr      ::=  Bindings `=>' Block
-  Bindings        ::=  `(' Binding {`,' Binding `)'
-                    |  id [`:' Type1]
-  Binding         ::=  id [`:' Type]
-\end{lstlisting}
-
-The anonymous function ~\lstinline@($x_1$: $T_1 \commadots x_n$: $T_n$) => e@~ 
-maps parameters $x_i$ of types $T_i$ to a result given
-by expression $e$. The scope of each formal parameter
-$x_i$ is $e$. Formal parameters must have pairwise distinct names.
-
-If the expected type of the anonymous function is of the form
-~\lstinline@scala.Function$n$[$S_1 \commadots S_n$, $R\,$]@, the
-expected type of $e$ is $R$ and the type $T_i$ of any of the
-parameters $x_i$ can be omitted, in which
-case~\lstinline@$T_i$ = $S_i$@ is assumed.
-If the expected type of the anonymous function is
-some other type, all formal parameter types must be explicitly given,
-and the expected type of $e$ is missing. The type of the anonymous
-function
-is~\lstinline@scala.Function$n$[$S_1 \commadots S_n$, $T\,$]@,
-where $T$ is the type of $e$. $T$ must be equivalent to a
-type which does not refer to any of the formal parameters $x_i$.
-
-The anonymous function is evaluated as the instance creation expression
-\begin{lstlisting}
-scala.Function$n$[$T_1 \commadots T_n$, $T$] {
-  def apply($x_1$: $T_1 \commadots x_n$: $T_n$): $T$ = $e$
-}
-\end{lstlisting}
-In the case of a single formal parameter, ~\lstinline@($x$: $T\,$) => $e$@~ and ~\lstinline@($x\,$) => $e$@~ 
-can be abbreviated to ~\lstinline@$x$: $T$ => e@, and ~\lstinline@$x$ => $e$@, respectively.
-
-\example Examples of anonymous functions:
-
-\begin{lstlisting}
-  x => x                             // The identity function
-
-  f => g => x => f(g(x))             // Curried function composition
-
-  (x: Int,y: Int) => x + y           // A summation function
-
-  () => { count = count + 1; count } // The function which takes an
-                                     // empty parameter list $()$, 
-                                     // increments a non-local variable 
-                                     // `count' and returns the new value.
-\end{lstlisting}
-
-\section{Statements}
-\label{sec:statements}
-
-\syntax\begin{lstlisting}
-  BlockStat    ::=  Import
-                 |  Def
-                 |  {LocalModifier} TmplDef
-                 |  Expr
-                 | 
-  TemplateStat ::=  Import
-                 |  {AttributeClause} {Modifier} Def
-                 |  {AttributeClause} {Modifier} Dcl
-                 |  Expr
-                 | 
-\end{lstlisting}
-
-Statements occur as parts of blocks and templates.  A statement can be
-an import, a definition or an expression, or it can be empty.
-Statements used in the template of a class definition can also be
-declarations.  An expression that is used as a statement can have an
-arbitrary value type. An expression statement $e$ is evaluated by
-evaluating $e$ and discarding the result of the evaluation. 
-\todo{Generalize to implicit coercion?}
-
-Block statements may be definitions which bind local names in the
-block. The only modifiers allowed in block-local definitions are modifiers
-\code{abstract}, \code{final}, or \code{sealed} preceding a class or
-object definition.
-
-With the exception of overloaded definitions
-(\sref{sec:overloaded-defs}), a statement sequence making up a block
-or template may not contain two definitions or declarations that bind
-the same name in the same namespace.  Evaluation of a statement
-sequence entails evaluation of the statements in the order they are
-written.
-
-\chapter{Pattern Matching}
-
-\section{Patterns}
-
-% 2003 July - changed to new pattern syntax + semantic Burak
-%      Nov  - incorporated changes to grammar, avoiding empty patterns
-%             definitions for value and sequence patterns
-% 2004 Jan  - revert back to original version ?! move regexp to subsect
-%      May  - XmlPattern
-
-\label{sec:patterns}
-
-\syntax\begin{verbatim}
-  Pattern       ::=  SimplePattern {Id SimplePattern}
-                 |   varid `:' Type
-                 |   `_' `:' Type
-  SimplePattern ::=  varid
-                 |   `_'
-                 |   literal
-                 |   StableId {`(' [Patterns] `)'}
-                 |   XmlPattern
-  Patterns      ::=  Pattern {`,' Pattern}
-\end{verbatim}
-
-For clarity, this section deals with a subset of the Scala pattern language.
-The extended Scala pattern language, which is described below, adds more
-flexible variable binding and regular hedge expressions.
-
-A pattern is built from constants, constructors, variables and regular
-operators. Pattern matching tests whether a given value (or sequence
-of values) has the shape defined by a pattern, and, if it does, binds
-the variables in the pattern to the corresponding components of the
-value (or sequence of values).  The same variable name may not be
-bound more than once in a pattern.
-
-Pattern matching is always done in a context which supplies an
-expected type of the pattern. We distinguish the following kinds of
-patterns.
-
-A {\em variable pattern} $x$ is a simple identifier which starts with
-a lower case letter.  It matches any value, and binds the variable
-name to that value.  The type of $x$ is the expected type of the
-pattern as given from outside.  A special case is the wild-card
-pattern $\_$ which is treated as if it was a fresh variable.
-
-A {\em typed pattern} $x: T$ consists of a pattern variable $x$ and a
-simple type $T$. The type $T$ may be a class type or a compound type;
-it may not contain a refinement (\sref{sec:refinements}).  This
-pattern matches any value of type $T$ and binds the variable name to
-that value.  $T$ must conform to the pattern's expected type. The
-type of $x$ is $T$.
-
-A {\em pattern literal} $l$ matches any value that is equal (in terms
-of $==$) to it. It's type must conform to the expected type of the
-pattern.
-
-A {\em named pattern constant} $r$ is a stable identifier
-(\sref{sec:stable-ids}). To resolve the syntactic overlap with a
-variable pattern, a named pattern constant may not be a simple name
-starting with a lower-case letter. The type of $r$ must conform
-to the expected type of the pattern. The pattern matches any value $v$
-such that \verb@$r$ == $v$@ (\sref{sec:cls-object}).
-
-A {\em constructor pattern} $c(p_1) \ldots (p_n)$ where $n \geq 0$
-consists of an identifier $c$, followed by component patterns $p_1
-\commadots p_n$. The constructor $c$ is either a simple name
-or a qualified name $r.id$ where $r$ is a stable identifier. It refers
-to a (possibly overloaded) function which has one alternative of
-result type \verb@class C@, and which may not have other overloaded
-alternatives with a class constructor type as result type.
-Furthermore, the respective type parameters and value parameters of
-(said alternative of) $c$ and of the primary constructor function of
-class $C$ must be the same, after renaming corresponding type parameter
-names.  If $C$ is monomorphic, then
-\verb@C@ must conform to the expected type of the pattern, and the
-formal parameter types of $C$'s primary constructor are taken as the
-expected types of the component patterns $p_1 \commadots p_n$.  If $C$
-is polymorphic, then there must be a unique type application instance
-of it such that the instantiation of $C$ conforms to the expected type
-of the pattern. The instantiated formal parameter types of $C$'s
-primary constructor are then taken as the expected types of the
-component patterns $p_1\commadots p_n$.
-The pattern matches all objects created from
-constructor invocations $c(v_1)\ldots(v_n)$ where each component
-pattern $p_i$ matches the corresponding value $v_i$.
-
-An {\em infix operation pattern} \verb@p id p'@ is a shorthand for the
-constructor pattern \verb@id_class(p)(p')@.  The precedence and
-associativity of operators in patterns is the same as in expressions
-(\sref{sec:infix-operations}).
-
-\example Some examples of patterns are:
-\begin{enumerate}
-\item
-The pattern \verb@ex: IOException@ matches all instances of class
-\verb@IOException@, binding variable \verb@ex@ to the instance.
-\item
-The pattern \verb@(x, _)@ matches pairs of values, binding \verb@x@ to
-the first component of the pair. The second component is matched
-with a wildcard pattern.
-\item
-The pattern \verb@x :: y :: xs@ matches lists of length $\geq 2$,
-binding \verb@x@ to the lists's first element, \verb@y@ to the list's
-second element, and \verb@xs@ to the remainder.
-\end{enumerate}
-
-%%% new patterns
-
-\subsection{Regular Pattern Matching}
-
-\syntax\begin{lstlisting}
-  Pattern         ::=  Pattern1 { `|' Pattern1 }
-  Pattern1        ::=  varid `:' Type
-                    |  `_' `:' Type
-                    |  Pattern2
-  Pattern2        ::=  [varid `@'] Pattern3
-  Pattern3        ::=  SimplePattern [ '*' | '?' | '+' ]
-                    |  SimplePattern { id' SimplePattern }
-  SimplePattern   ::=  `_'
-                    |  varid
-                    |  Literal
-                    |  StableId [ `(' [Patterns] `)' ]
-                    |  `(' [Patterns] `)'
-  Patterns        ::=  Pattern {`,' Pattern}
-  id'             ::=  id $\textit{ but not }$ '*' | '?' | '+' | `@' | `|'
-\end{lstlisting}
-
-We distinguish between tree patterns and hedge patterns (hedges 
-are ordered sequences of trees). A {\em tree pattern} describes 
-a set of matching trees (like above). A {\em hedge pattern} describes 
-a set of matching hedges. Both kinds of patterns may contain {\em 
-variable bindings} which serve to extract constituents of a tree or hedge.
-
-The type of a patterns and the expected types of variables 
-within patterns are determined by the context and the structure of the
-patterns. The last case ensures that a variable bound 
-to a hedge pattern will have a sequence type.
-
-The following patterns are added:
-
-A {\em hedge pattern} $p_1 \commadots p_n$ where $n \geq 0$ is a
-sequence of patterns separated by commas and matching the hedge described
-by the components. Hedge patterns may appear as arguments to constructor 
-applications, or nested within a another hedge pattern if grouped with
-parentheses. Note that empty hedge patterns are allowed. The type of tree 
-patterns that appear in a hedge pattern is the expected type as 
-determined from the enclosing constructor.
-A {\em fixed-length argument pattern} is a special hedge pattern where 
-where all $p_i$ are tree patterns.
-
-A {\em choice pattern} $p_1 | \ldots | p_n$ is a choice among several
-alternatives, which may not contain variable-binding patterns. It
-matches every tree and every hedge matched by at least one of its 
-alternatives.  Note that the empty sequence may appear as an alternative.  
-An {\em option pattern} $p?$ is an abbreviation for $(p| )$. A choice is 
-a tree pattern if all its branches are tree patterns. In this case, all 
-branches must conform to the expected type and the type 
-of the choice is the least upper bound of the branches. Otherwise, 
-its type is determined by the enclosing hedge pattern it is part of.
-
-An {\em iterated pattern} $p*$ matches zero, one or more occurrences 
-of items matched by $p$, where $p$ may be either a tree pattern or a hedge pattern. $p$ may not 
-contain a variable-binding. A {\em non-empty iterated pattern} $p+$ is an 
-abbreviation for $(p,p*)$. 
-
-The treatment of the following patterns changes with to the 
-previous section:
-
-A {\em constructor pattern} $c ( p )$ consists of a simple type $c$
-followed by a pattern $p$.  If $c$ designates a monomorphic case
-class, then it must conform to the expected type of the pattern, the
-pattern must be a fixed length argument pattern $p_1 \commadots p_n$
-whose length corresponds to the number of arguments of $c$'s primary
-constructor. The expected types of the component patterns are then
-taken from the formal parameter types of (said) constructor.  If $c$
-designates a polymorphic case class, then there must be a unique type
-application instance of it such that the instantiation of $c$ conforms
-to the expected type of the pattern. The instantiated formal parameter
-types of $c$'s primary constructor are then taken as the expected
-types of the component patterns $p_1\commadots p_n$.  In both cases,
-the pattern matches all objects created from constructor invocations
-$c(v_1 \commadots v_n)$ where each component pattern $p_i$ matches the
-corresponding value $v_i$. If $c$ does not designate a case class, it
-must be a subclass of \lstinline@Seq[$T\,$]@. In that case $p$ may be an
-arbitrary sequence pattern. Value patterns in $p$ are expected to conform to
-type $T$, and the pattern matches all objects whose \lstinline@elements()@
-method returns a sequence that matches $p$.
-
-The pattern $(p)$ is regarded as equivalent to the pattern $p$, if $p$
-is a nonempty sequence pattern. The empty tuple $()$ is a shorthand
-for the constructor pattern \code{Unit}.
-
-A {\em variable-binding} $x @ p$ is a simple identifier $x$
-which starts with a lower case letter, together with a pattern $p$. It
-matches every item (tree or hedge) matched by $p$, and in addition binds 
-it to the variable name. If $p$ is a tree pattern of type $T$, the type 
-of $x$ is also $T$.
-If $p$ is a hedge pattern enclosed by constructor $c <: $\lstinline@Seq[$T\,$]@,
-then the type of $x$ is \lstinline@List[$T\,$]@
-where $T$ is the expected type as dictated by the constructor. 
-
-%A pattern consisting of only a variable $x$ is treated as the bound
-%value pattern $x @ \_$. A typed pattern $x:T$ is treated as $x @ (_:T)$.
-%
-Regular expressions that contain variable bindings may be ambiguous,
-i.e. there might be several ways to match a sequence against the
-pattern. In these cases, the \emph{right-longest policy} applies:
-patterns that appear more to the right than others in a sequence take
-precedence in case of overlaps.
-
-\example Some examples of patterns are:
-\begin{enumerate}
-\item
-The pattern ~\lstinline@ex: IOException@~ matches all instances of class
-\code{IOException}, binding variable \code{ex} to the instance.
-\item
-The pattern ~\lstinline@Pair(x, _)@~ matches pairs of values, binding \code{x} to
-the first component of the pair. The second component is matched
-with a wildcard pattern.
-\item
-The pattern \ \code{List( x, y, xs @ _ * )} matches lists of length $\geq 2$,
-binding \code{x} to the list's first element, \code{y} to the list's
-second element, and \code{xs} to the remainder, which may be empty.
-\item
-The pattern \ \code{List( 1, x@(( 'a' | 'b' )+),y,_ )} matches a list that
-contains 1 as its first element, continues with a non-empty sequence of 
-\code{'a'}s and \code{'b'}s, followed by two more elements. The sequence 'a's and 'b's
-is bound to \code{x}, and the next to last element is bound to \code{y}.
-\item
-The pattern \code{List( x@( 'a'* ), 'a'+ )} matches a non-empty list of
-\code{'a'}s. Because of the shortest match policy, \code{x} will always be bound to
-the empty sequence.
-\item
-The pattern \code{List( x@( 'a'+ ), 'a'* )} also matches a non-empty list of
-\code{'a'}s. Here, \code{x} will always be bound to
-the sequence containing one \code{'a'}
-\end{enumerate}
-
-
-\section{Pattern Matching Expressions}
-\label{sec:pattern-match}
-
-\syntax\begin{lstlisting}
-  BlockExpr       ::=  `{' CaseClause {CaseClause} `}'
-  CaseClause      ::=  case Pattern [`if' PostfixExpr] `=>' Block 
-\end{lstlisting}
-
-A pattern matching expression
-~\lstinline@case $p_1$ => $b_1$ $\ldots$ case $p_n$ => $b_n$@ \ consists of a number 
-$n \geq 1$ of cases. Each case consists of a (possibly guarded) pattern 
-$p_i$ and a block $b_i$.  The scope of the pattern variables in $p_i$ is 
-the corresponding block $b_i$.
-
-The expected type of a pattern matching expression must in part be
-defined. It must be either ~\lstinline@scala.Function1[$T_p$, $T_r$]@ \ or
-~\lstinline@scala.PartialFunction[$T_p$, $T_r$]@, where the argument type
-$T_p$ must be fully determined, but the result type
-$T_r$ may be undetermined.  All patterns are typed
-relative to the expected type $T_p$ (\sref{sec:patterns}).  The expected type of
-every block $b_i$ is $T_r$.
-Let $T_b$ be the least upper bound of the types of all blocks 
-$b_i$. The type of the pattern matching expression is
-then the required type with $T_r$ replaced by $T_b$
-(i.e. the type is either ~\lstinline@scala.Function[$T_p$, $T_b$]@~ or
-~\lstinline@scala.PartialFunction[$T_p$, $T_b$]@.
-
-When applying a pattern matching expression to a selector value,
-patterns are tried in sequence until one is found which matches the
-selector value (\sref{sec:patterns}). Say this case is $\CASE;p_i
-\Arrow b_i$.  The result of the whole expression is then the result of
-evaluating $b_i$, where all pattern variables of $p_i$ are bound to
-the corresponding parts of the selector value.  If no matching pattern
-is found, a \code{scala.MatchError} exception is thrown.
-
-The pattern in a case may also be followed by a guard suffix \ \code{if e}\ 
-with a boolean expression $e$.  The guard expression is evaluated if
-the preceding pattern in the case matches. If the guard expression
-evaluates to \code{true}, the pattern match succeeds as normal. If the
-guard expression evaluates to \code{false}, the pattern in the case
-is considered not to match and the search for a matching pattern
-continues.
-
-\comment{
-A case with several patterns $\CASE;p_1 \commadots p_n ;\IF; e \Arrow b$  is a
-shorthand for a sequence of single-pattern cases $\CASE;p_1;\IF;e \Arrow b
-;\ldots; \CASE;p_n ;\IF;e\Arrow b$. In this case none of the patterns
-$p_i$ may contain a named pattern variable (but the patterns may contain
-wild-cards).
-}
-
-In the interest of efficiency the evaluation of a pattern matching
-expression may try patterns in some other order than textual
-sequence. This might affect evaluation through
-side effects in guards. However, it is guaranteed that a guard
-expression is evaluated only if the pattern it guards matches.
-
-\example
-Often, pattern matching expressions are used as arguments
-of the \code{match} method, which is predefined in class \code{Any}
-(\sref{sec:cls-object}) and is implemented there by postfix function
-application. Here is an example:
-\begin{lstlisting}
-def length [a] (xs: List[a]) = xs match {
-  case Nil =>  0
-  case x :: xs1  =>  1 + length (xs1)
-}
-\end{lstlisting}
-
-In an application of \code{match} such as the one above, the expected
-type of all patterns is the type of the qualifier of \code{match}.
-In the example above, the expected type of the patterns \code{Nil} and
-\code{x :: xs1} would be \code{List[a]}, the type of \code{xs}.
-
-
-\chapter{Views}\label{sec:views}
-
-Views are user-defined, implicit coercions that are automatically
-inserted by the compiler. 
-
-\section{View Definition}
-
-A view definition is a normal function definition with one value
-parameter where the name of the defined function is \code{view}.
-
-\example 
-The following defines an implicit coercion function from strings to lists of
-characters.
-
-\begin{lstlisting}
-def view(xs: String): List[char] = 
-  if (xs.length() == 0) List()
-  else xs.charAt(0) :: xs.substring(1);
-\end{lstlisting}
-
-\section{View Application}
-
-View applications are inserted implicitly in two situations.
-\begin{enumerate}
-\item
-Around an expression $e$ of type $T$, if $T$ does not conform to the
-expression's expected type $PT$.
-\item
-In a selection $e.m$ with $e$ of type $T$, if the selector $m$ does not
-denote a member of $T$.
-\end{enumerate}
-In the first case, a view method \code{view} is searched which is
-applicable to $e$ and whose result type conforms to $PT$.
-If such a method is found, the expression $e$ is converted to 
-\lstinline@view($e$)@.
-
-In the second case, a view method \code{view} is searched which is
-applicable to $e$ and whose result contains a member named $m$.
-If such a method is found, the selection $e.m$ is converted to 
-\lstinline@view($e$).m@
-
-\section{Finding Views}\label{sec:finding-views}
-
-Searching a view which is applicable to an expression $e$ of type $T$
-is a three-step process.
-\begin{enumerate}
-\item
-First, the set $\AA$ of available views is determined. $\AA$ is the
-smallest set such that:
-\begin{enumerate}
-\item
-If a unary method called \code{view} is accessible without qualifier
-anywhere on the path of the program tree that leads from $e$ to the
-root of the tree (describing the whole compilation unit), then that
-method is in the set $\AA$. Methods are accessible without qualifier
-because they are locally defined in an enclosing scope, or imported
-into an enclosing scope, or inherited by an enclosing class.
-\item
-If a unary method called \code{view} is a member of an object $C$ such
-that there is a base class $C$ of $T$ with the same name as the object
-and defined in the same scope, then that method is in the set $\AA$.
-\end{enumerate}
-\item
-Then, among all the methods in $\AA$ the set of all applicable views
-$\BB$ is determined. A view method is applicable if it can be applied
-to values of type $T$, and another condition is satisfied which
-depends on the context of the view application:
-\begin{enumerate}
-\item
-If the view is a conversion to a given prototype $PT$, then the view's
-result type must conform to $PT$.
-\item
-If the view is a conversion in a selection with member $m$, then the
-view's result type must contain a member named $m$.
-\end{enumerate}
-Note that in the determining of view applicability, we do not permit
-further views to be inserted. I.e.\ a view is applicable to an
-expression $e$ of type $T$ if it can be applied to $e$, without a
-further view conversion of $e$ to the view's formal parameter type.
-Likewise, a view's result type must conform to a given prototype
-directly, no second view conversion is allowed.
-\item
-It is an error if the set of applicable views $\BB$ is empty.  For
-non-empty $\BB$, the view method which is most specific
-(\sref{sec:overloaded-refs}) in $\BB$ is selected.  It is an error if
-no most specific view exists, or if it is not unique.
-\end{enumerate}
-
-\example
-
-Consider the following situation.
-\begin{lstlisting}
-class A;
-class B extends A;
-class C;
-object B {
-  def view(x: B): C = ...
-}
-object Test with Application {
-  def view(x: A): C = ...
-  val x: C = new B;
-}
-\end{lstlisting}
-For the expression ~\code{new B}~ there are two available views. The
-view defined in object \code{B} is available since its associated
-class is (a superclass of) the expression's type \code{B}. The view
-defined in object \code{Test} is available since it is accessible
-without qualification at the point of the expression ~\code{new
-B}. Both views are also applicable since they map values of type
-\code{B} to results of type \code{C}. However, the view defined in
-object \code{B} is more specific than the view defined in object
-\code{Test}.  Hence, the last statement in the example above is
-implicitly augmented to
-\begin{lstlisting}
-val x: C = B.view(new B)
-\end{lstlisting}
-
-\section{View-Bounds}\label{sec:view-bounds}
-
-\syntax\begin{lstlisting}
-  TypeParam       ::=  id [>: Type] [<% Type]
-\end{lstlisting}
-
-A type parameter \code{a} may have a view bound \lstinline@a <% T@
-instead of a regular upper bound \lstinline@a <: T@. In that case the
-type parameter may be instantiated to any type \code{S} which is
-convertible by application of a view method to the view bound
-\code{T}. Here, we assume there exists an always available identity
-view method
-\begin{lstlisting}
-def view[a](x: a): a = x .
-\end{lstlisting}
-Hence, the type parameter \code{a} can always be instantiated to
-subtypes of the view bound \code{T}, just as if \code{T} was a regular
-upper bound.
-
-View bounds for type parameters behave analogously to upper bounds wrt
-to type conformance (\sref{sec:subtyping}), variance checking
-(\sref{sec:type-params}), and overriding (\sref{sec:overriding}).
-
-Methods or classes with view-bounded type parameters implicitly take
-view functions as parameters. For every view-bounded type parameter
-\lstinline@a <% T@ one adds an implicit value parameter
-\lstinline@view: a => T@. When instantiating the type parameter
-\code{a} to some type \code{S}, the most specific applicable view
-method from type \code{S} to type \code{T} is selected, according to
-the rules of \sref{sec:finding-views}. This method is then passed as
-actual argument to the corresponding view parameter.
-
-Implicit view parameters of a method or class are then taken as
-available view methods in its body.
-
-\example Consider the following definition of a trait
-\code{Comparable} and a view from strings to that trait.
-
-\begin{lstlisting}
-trait Comparable[a] {
-  def less(x: a): boolean
-}
-
-object StringsAreComparable {
-  def view(x: String): Comparable[String] = new Comparable[String] {
-    def less(y: String) = x.compareTo(y) < 0
-  }
-}
-\end{lstlisting}
-
-Now, define a binary tree with a method \code{insert} which inserts an
-element in the tree and a method \code{elements} which returns a
-sorted list of all elements of the tree. The tree is defined for all
-types of elements \code{a} that are viewable as \code{Comparable[a]}.
-
-\begin{lstlisting}
-trait Tree[a <% Comparable[a]] {
-  def insert(x: a): Tree[a] = this match {
-    case Empty() => new Node(x, Empty(), Empty())
-    case Node(elem, l, r) => 
-      if (x == elem) this
-      else if (x less elem) Node(elem, l insert x, r)
-      else Node(elem, l, r insert x);
-  }
-  def elements: List[a] = this match {
-    case Empty() => List()
-    case Node(elem, l, r) => 
-      l.elements ::: List(elem) ::: r.elements
-  }
-}
-case class Empty[a <% Comparable[a]]() 
-  extends Tree[a];
-case class Node[a <% Comparable[a]](elem: a, l: Tree[a], r: Tree[a])
-  extends Tree[a];
-\end{lstlisting}
-
-Finally, define a test program which builds a tree from all command
-line argument strings and then prints out the elements as a sorted
-sequence. 
-
-\begin{lstlisting}
-object Test {
-  import StringsAreComparable.view;
-
-  def main(args: Array[String]) = {
-    var t: Tree[String] = Empty();
-    for (val s <- args) { t = t insert s }
-    System.out.println(t.elements)
-  }
-}
-\end{lstlisting}
-Note that the definition ~\lstinline@var t: Tree[String] = Empty();@~
-is legal because at that point a view method from \code{String} to
-\code{Comparable[String]} has been imported and is therefore
-accessible without a prefix. The imported view method is passed as an
-implicit argument to the \code{Empty} constructor. 
-
-
-Here is the \code{Test} program again, this time with implicit views
-made visible:
-\begin{lstlisting}
-object Test {
-  import StringsAreComparable.view;
-
-  def main(args: Array[String]) = {
-    var t: Tree[String] = Empty($\mbox{\bf StringsAreComparable.view}$);
-    for (val s <- args) { t = t insert s }
-    System.out.println(t.elements)
-  }
-}
-\end{lstlisting}
-
-And here are the tree classes with implicit views added:
-
-\begin{lstlisting}
-trait Tree[a <% Comparable[a]]($\mbox{\bf view}$: a => Comparable[a]) {
-  def insert(x: a): Tree[a] = this match {
-    case Empty(_) => new Node(x, Empty($\mbox{\bf view}$), Empty($\mbox{\bf view}$))
-    case Node(_, elem, l, r) => 
-      if (x == elem) this
-      else if ($\mbox{\bf view}$(x) less elem) Node($\mbox{\bf view}$, elem, l insert x, r)
-      else Node($\mbox{\bf view}$, elem, l, r insert x);
-  }
-  def elements: List[a] = this match {
-    case Empty(_) => List()
-    case Node(_, elem, l, r) => 
-      l.elements ::: List(elem) ::: r.elements
-  }
-}
-case class Empty[a <% Comparable[a]]($\mbox{\bf view}$: a => Comparable[a]) 
-  extends Tree[a];
-case class Node[a <% Comparable[a]]($\mbox{\bf view}$: a => Comparable[a], 
-                                    elem: a, l: Tree[a], r: Tree[a])
-  extends Tree[a];
-\end{lstlisting}
-
-Note that views entail a certain run-time overhead because they need
-to be passed as additional arguments to view-bounded methods and
-classes. Furthermore, every application of a view entails the
-construction of an object which is often immediately discarded
-afterwards -- see for instance with the translation of \code{(x less elem)} 
-in the implementation of method \code{insert} above. It is
-expected that the latter cost can be absorbed largely or completely by
-compiler optimizations (which are, however, not yet implemented at the
-present stage).
-
-\section{Conditional Views}
-
-View methods might themselves have view-bounded type parameters; this
-allows the definition of conditional views.
-
-\example The following view makes lists comparable, {\em provided} the
-list element type is also comparable.
-
-\begin{lstlisting}
-def view[a <% Comparable[a]](xs: List[a]): Comparable[List[a]] = 
-  new Comparable[List[a]] {
-    def less (ys: List[a]): boolean = 
-      !ys.isEmpty 
-      && 
-      (xs.isEmpty || 
-       (xs.head less ys.head) || 
-       (xs.head == ys.head) && (xs.tail less ys.tail))
-  }
-\end{lstlisting}
-
-Note that the condition \code{(xs.head less ys.head)} invokes the
-\code{less} method of the list element type, which is unknown at the
-point of the definition of the view method. As usual, view-bounded
-type parameters are translated to implicit \code{view} arguments. In
-this case, the \code{view} method over lists would receive the
-\code{view} method over list elements as implicit parameter.
-
-\comment{
-This opens up the risk of infinite instantiations because view methods
-are be passed to themselves as parameters. For instance, one might try
-to define the following ``magic'' universal converter:
-\begin{lstlisting}
-def view[b, a <% b](x: a): b = x // illegal!
-\end{lstlisting}
-Application of this view would entail an inifinite expansion with view
-parameters. To prevent this situation, we impose the following
-restrictions on view definitions and applications.
-
-Suppose a view definition
-\begin{lstlisting}
-def view [$tps$](x: $T$): $S$
-\end{lstlisting}
-where the list of type parameters $tps$ might be empty.  The view
-definition is legal only if the result type $S$ is not a type variable
-in $tps$.  Furthermore, we say the view definition is {\em
-contractive} if the parameter type $T$ is not a type variable in
-$tps$.  Contractive views can never lead to infinite expansions, as
-the view argument type becomes strictly smaller for each nested view
-argument.
-
-For non-contractive views we require that every such view can be used
-only once on a path of implicit view parameters. That is, a
-non-contractive view may not be passed to itself as implicit view
-argument, either directly or indirectly.  On the other hand,
-contractive view methods may be passed to themselves as arguments. In the
-examples above this case arises if a list of lists of strings is seen
-as a \code{Comparable}.
-}
-
-\chapter{Top-Level Definitions}
-\label{sec:topdefs}
-
-\syntax\begin{lstlisting}
-  CompilationUnit  ::=  [package QualId `;'] {TopStat `;'} TopStat
-  TopStat          ::=  {AttributeClause} {Modifier} TmplDef
-                     |  Import
-                     |  Packaging
-                     |
-  QualId           ::=  id {`.' id}
-\end{lstlisting}
-
-A compilation unit consists of a sequence of packagings, import
-clauses, and class and object definitions, which may be preceded by a
-package clause.
-
-A compilation unit ~\lstinline@package $p$; $\stats$@~ starting with a package
-clause is equivalent to a compilation unit consisting of a single
-packaging ~\lstinline@package $p$ { $\stats$ }@.
-
-Implicitly imported into every compilation unit are, in that order :
-the package \code{java.lang}, the package \code{scala}, and the object
-\code{scala.Predef} (\sref{cls:predef}). Members of a later import in
-that order hide members of an earlier import.
-
-\section{Packagings}\label{sec:packagings}
-
-\syntax\begin{lstlisting}
-  Packaging       ::=  package QualId `{' {TopStat `;'} TopStat `}'
-\end{lstlisting}
-
-A package is a special object which defines a set of member classes,
-objects and packages.  Unlike other objects, packages are not introduced
-by a definition.  Instead, the set of members of a package is determined by
-packagings.
-
-A packaging \ \code{package p { ds }}\ injects all definitions in
-\code{ds} as members into the package whose qualified name is
-$p$. If a definition in \code{ds} is labeled \code{private}, it
-is visible only for other members in the package.
-
-Selections \code{p.m} from $p$ as well as imports from $p$
-work as for objects. However, unlike other objects, packages may not
-be used as values. It is illegal to have a package with the same fully
-qualified name as a module or a class.
-
-Top-level definitions outside a packaging are assumed to be injected
-into a special empty package. That package cannot be named and
-therefore cannot be imported. However, members of the empty package
-are visible to each other without qualification.
-
-\example The following example will create a hello world program as
-function \code{main} of module \code{test.HelloWorld}.
-\begin{lstlisting}
-package test;
-
-object HelloWord {
-  def main(args: Array[String]) = System.out.println("hello world")
-}
-\end{lstlisting}
-
-\chapter{Local Type Inference}
-\label{sec:local-type-inf}
-
-To be completed.
-
-\chapter{XML expressions and patterns}
-This chapter describes the syntactic structure of XML expressions and patterns.
-It follows as close as possible the XML 1.0 specification \cite{w3c:xml},
-changes being mandated by the possibility of embedding Scala code fragments.
-
-\section{XML expressions}
-XML expressions are expressions generated by the following production, where the 
-opening bracket `<' of the first element must be in a position to start the lexical
-XML mode (see \ref{sec::xmlMode}).
-
-\syntax\begin{lstlisting}
-XmlExpr ::= Element {Element}
-\end{lstlisting}
-Well-formedness constraints of the XML specification apply, which
-means for instance that start tags and end tags must match, and
-attributes may only be defined once, with the exception of constraints
-related to entity resolution.
-
-The following productions describe Scala's extensible markup language,
-designed as close as possible to the W3C extensible markup language
-standard. Only the productions for attribute values and character data
-are changed. Scala does not support neither declarations, CDATA
-sections nor processing instructions. Entity references are not
-resolved at runtime.
-
-\syntax\begin{lstlisting}
-Element       ::=    EmptyElemTag
-                |    STag Content ETag                                       
-
-EmptyElemTag  ::=    `<' Name {S Attribute} [S] `/>'                         
-
-STag          ::=    `<' Name {S Attribute} [S] `>'                          
-ETag          ::=    `</' Name [S] '>'                                        
-Content       ::=    [CharData] {Content1 [CharData]}
-Content1      ::=    Element
-                |    Reference
-                |    CDSect
-                |    PI
-                |    Comment
-                |    ScalaExpr
-\end{lstlisting}
-
-If an XML expression is a single element, its value is a runtime
-representation of an XML node (an instance of a subclass of 
-\lstinline@scala.xml.Node@). If the XML expression consists of more
-than one element, then its value is a runtime representation of a
-sequence of XML nodes (an instance of a subclass of 
-\lstinline@scala.Seq[scala.xml.Node]@).
-
-If an XML expression is an entity reference, CDATA section, processing 
-instructions or a comments, it is represented by an instance of the 
-corresponding Scala runtime class.
-
-By default, beginning and trailing whitespace in element content is removed, 
-and consecutive occurrences of whitespace are replaced by a single space
-character \U{0020}. This behaviour can be changed to preserve all whitespace
-with a compiler option.
-\syntax\begin{lstlisting}
-Attribute     ::=    Name Eq AttValue                                    
-
-AttValue      ::=    `"' {CharQ | CharRef} `"'
-                |    `'' {CharA | CharRef} `''
-                |    ScalaExp
-
-ScalaExpr     ::=    `{' expr `}'
-
-CharData      ::=   { CharNoRef } $\mbox{\rm\em without}$ {CharNoRef}`{'CharB {CharNoRef} 
-                                  $\mbox{\rm\em and without}$ {CharNoRef}`]]>'{CharNoRef}
-\end{lstlisting}
-XML expressions may contain Scala expressions as attribute values or
-within nodes. In the latter case, these are embedded using a single opening 
-brace `{' and ended by a closing brace `}'. To express a single opening braces 
-within XML text as generated by CharData, it must be doubled. Thus, `{{` 
-represents the XML text `{` and does not introduce an embedded Scala 
-expression.
-
-\syntax\begin{lstlisting}
-BaseChar, Char, Comment, CombiningChar, Ideographic, NameChar, S, Reference
-              ::=  $\mbox{\rm\em ``as in W3C XML''}$
-
-Char1         ::=  Char $\mbox{\rm\em without}$ `<' | `&'
-CharQ         ::=  Char1 $\mbox{\rm\em without}$ `"'
-CharA         ::=  Char1 $\mbox{\rm\em without}$ `''
-CharB         ::=  Char1 $\mbox{\rm\em without}$ '{'
-
-Name          ::=  XNameStart {NameChar}
-
-XNameStart    ::= `_' | BaseChar | Ideographic 
-                 $\mbox{\rm\em (as in W3C XML, but without }$ `:'
-
-\end{lstlisting}
-\section{XML patterns}
-XML patterns are patterns generated by the following production, where
-the opening bracket `<' of the element patterns must be in a position
-to start the lexical XML mode (see \ref{sec::xmlMode}).
-
-\syntax\begin{lstlisting}
-XmlPattern  ::= ElementPattern {ElementPattern}
-\end{lstlisting}
-Well-formedness constraints of the XML specification apply.
-
-If an XML pattern is a single element pattern, it expects the type of runtime
-representation of an XML tree, and matches exactly one instance of this type
-that has the same structure as described by the pattern. If an XML pattern 
-consists of more than one element, then it expects the type of sequences
-of runtime representations of XML trees, and matches every sequence whose 
-elements match the sequence described by the pattern.
-
-XML patterns may contain Scala patterns(\ref{sec:pattern-match}).
-
-Whitespace is treated the same way as in XML expressions. Patterns 
-that are entity references, CDATA sections, processing 
-instructions and comments match runtime representations which are the
-the same.
-
-By default, beginning and trailing whitespace in element content is removed, 
-and consecutive occurrences of whitespace are replaced by a single space
-character \U{0020}. This behaviour can be changed to preserve all whitespace
-with a compiler option.
-
-\syntax\begin{lstlisting}
-ElemPattern   ::=    EmptyElemTagP
-                |    STagP ContentP ETagP                                    
-
-EmptyElemTagP ::=    '<' Name [S] '/>'
-STagP         ::=    '<' Name [S] '>'                          
-ETagP         ::=    '</' Name [S] '>'                                        
-ContentP      ::=    [CharData] {(ElemPattern|ScalaPatterns) [CharData]}
-ContentP1     ::=    ElemPattern
-                |    Reference
-                |    CDSect
-                |    PI
-                |    Comment
-                |    ScalaPatterns
-ScalaPatterns ::=    '{' patterns '}'
-\end{lstlisting}
-
-
-\chapter{The Scala Standard Library}
-
-The Scala standard library consists of the package \code{scala} with a
-number of classes and modules. Some of these classes are described in
-the following.
-
-\section{Root Classes}
-\label{sec:cls-root}
-\label{sec:cls-any}
-\label{sec:cls-object}
-
-The root of the Scala class hierarchy is formed by class \code{Any}.
-Every class in a Scala execution environment inherits directly or
-indirectly from this class.  Class \code{Any} has two direct
-subclasses: \code{AnyRef} and\code{AnyVal}.
-
-The subclass \code{AnyRef} represents all values which are represented
-as objects in the underlying host system. Every user-defined Scala
-class inherits directly or indirectly from this class. Furthermore,
-every user-defined Scala class also inherits the trait
-\code{scala.ScalaObject}.  Classes written in other languages still
-inherit from \code{scala.AnyRef}, but not from
-\code{scala.ScalaObject}.
-
-The class \code{AnyVal} has a fixed number subclasses, which describe
-values which are not implemented as objects in the underlying host
-system.
-
-Classes \code{AnyRef} and \code{AnyVal} are required to provide only
-the members declared in class \code{Any}, but implementations may add
-host-specific methods to these classes (for instance, an
-implementation may identify class \code{AnyRef} with its own root
-class for objects).
-
-The standard interfaces of these root classes is described by the
-following definitions.
-
-\begin{lstlisting}
-package scala;
-abstract class Any {
-
-  /** Defined equality; abstract here */
-  def equals(that: Any): boolean;
-
-  /** Semantic equality between values of same type */
-  final def == (that: Any): boolean  =  this equals that
-
-  /** Semantic inequality between values of same type */
-  final def != (that: Any): boolean  =  !(this == that)
-
-  /** Hash code */
-  def hashCode(): Int = $\ldots$
-
-  /** Textual representation */
-  def toString(): String = $\ldots$
-
-  /** Type test */
-  def isInstanceOf[a]: Boolean = this match {
-    case x: a => true
-    case _ => false
-  }
-
-  /** Type cast */
-  def asInstanceOf[a]: a = this match {
-    case x: a => x
-    case _ => if (this eq null) this
-              else throw new ClassCastException()
-  }
-
-  /** Pattern match */
-  def match[a, b](cases: a => b): b = cases(this);
-}
-final class AnyVal extends Any;
-class AnyRef extends Any {
-  def equals(that: Any): boolean     = this eq that;
-  final def eq(that: Any): boolean   = $\ldots$; // reference equality
-}
-trait ScalaObject extends AnyRef;
-\end{lstlisting}
-
-\todo{isinstanceof not permitted on numeric types}
-
-The type cast operation \verb@asInstanceOf@ has a special meaning (not
-expressed in the code above) when its type parameter is a numeric
-type.  For any type \lstinline@T <: Double@, and any numeric value
-\verb@v@ \lstinline@v.asInstanceIf[T]@ converts \code{v} to type
-\code{T} using the rules of Java's numeric type cast operation.  The
-conversion might truncate the numeric value (as when going from
-\code{Long} to \code{Int} or from \code{Int} to \code{Byte}) or it
-might lose precision (as when going from \code{Double} to \code{Float}
-or when converting between \code{Long} and \code{Float}).
-
-\section{Value Classes}
-\label{cls:value}
-
-Value classes are classes whose instances are not represented as
-objects by the underlying host system.  All value classes inherit from
-class \code{AnyVal}. Scala implementations need to provide the
-value classes \code{Unit}, \code{Boolean}, \code{Double}, \code{Float},
-\code{Long}, \code{Int}, \code{Char}, \code{Short}, and \code{Byte}
-(but are free to provide others as well).
-The signatures of these classes are defined in the following.
-
-\subsection{Class \large{\code{Double}}}
-
-\begin{lstlisting}
-package scala;
-abstract sealed class Double extends AnyVal {
-  def + (that: Double): Double // double addition
-  def - (that: Double): Double // double subtraction
-  def * (that: Double): Double // double multiplication
-  def / (that: Double): Double // double division
-  def % (that: Double): Double // double remainder
-
-  def == (that: Double): Boolean // double equality
-  def != (that: Double): Boolean // double inequality
-  def < (that: Double): Boolean  // double less
-  def > (that: Double): Boolean  // double greater
-  def <= (that: Double): Boolean // double less or equals
-  def >= (that: Double): Boolean // double greater or equals
-
-  def - : Double = 0.0 - this    // double negation
-  def + : Double = this
-}
-\end{lstlisting}
-
-\subsection{Class \large{\code{Float}}}
-
-\begin{lstlisting}
-package scala;
-abstract sealed class Float extends AnyVal {
-  def coerce: Double              // convert to Double
-
-  def + (that: Double): Double;   // double addition
-  def + (that: Float): Double     // float addition
-  /* analogous for -, *, /, % */
-
-  def == (that: Double): Boolean; // double equality
-  def == (that: Float): Boolean;  // float equality
-  /* analogous for !=, <, >, <=, >= */
-
-  def - : Float;                  // float negation
-  def + : Float
-}
-\end{lstlisting}
-
-\subsection{Class \large{\code{Long}}}
-
-\begin{lstlisting}
-package scala;
-abstract sealed class Long extends AnyVal  {
-  def coerce: Double              // convert to Double
-  def coerce: Float               // convert to Float
-
-  def + (that: Double): Double;   // double addition
-  def + (that: Float): Double;    // float addition
-  def + (that: Long): Long =      // long addition
-  /* analogous for -, *, /, % */
-
-  def << (cnt: Int): Long         // long left shift
-  def >> (cnt: Int): Long         // long signed right shift
-  def >>> (cnt: Int): Long        // long unsigned right shift
-  def & (that: Long): Long        // long bitwise and
-  def | (that: Long): Long        // long bitwise or
-  def ^ (that: Long): Long        // long bitwise exclusive or
-
-  def == (that: Double): Boolean; // double equality
-  def == (that: Float): Boolean;  // float equality
-  def == (that: Long): Boolean    // long equality
-  /* analogous for !=, <, >, <=, >= */
-
-  def - : Long;                   // long negation
-  def + : Long;                   // long identity
-  def ~ : Long                    // long bitwise negation
-}
-\end{lstlisting}
-
-\subsection{Class \large{\code{Int}}}
-
-\begin{lstlisting}
-package scala;
-abstract sealed class Int extends AnyVal {
-  def coerce: Double              // convert to Double
-  def coerce: Float               // convert to Float
-  def coerce: Long                // convert to Long
-
-  def + (that: Double): Double;   // double addition
-  def + (that: Float): Double;    // float addtion
-  def + (that: Long): Long;       // long addition
-  def + (that: Int): Int;         // int addition
-  /* analogous for -, *, /, % */
-  
-  def << (cnt: Int): Int;         // int left shift
-  /* analogous for >>, >>> */
-
-  def & (that: Long): Long;       // long bitwise and
-  def & (that: Int): Int;         // int bitwise and
-  /* analogous for |, ^ */
-
-  def == (that: Double): Boolean; // double equality
-  def == (that: Float): Boolean;  // float equality
-  def == (that: Long): Boolean    // long equality
-  def == (that: Int): Boolean     // int equality
-  /* analogous for !=, <, >, <=, >= */
-
-  def - : Int;                    // int negation
-  def + : Int;                    // int identity
-  def ~ : Int;                    // int bitwise negation
-}
-\end{lstlisting}
-
-\subsection{Class \large{\code{Short}}}
-
-\begin{lstlisting}
-package scala;
-abstract sealed class Short extends AnyVal {
-  def coerce: Double              // convert to Double
-  def coerce: Float               // convert to Float
-  def coerce: Long                // convert to Long
-  def coerce: Int                 // convert to Int
-}
-\end{lstlisting}
-
-\subsection{Class \large{\code{Char}}}
-
-\begin{lstlisting}
-package scala;
-abstract sealed class Char extends AnyVal {
-  def coerce: Double              // convert to Double
-  def coerce: Float               // convert to Float
-  def coerce: Long                // convert to Long
-  def coerce: Int                 // convert to Int
-
-  def isDigit: Boolean;           // is this character a digit?
-  def isLetter: Boolean;          // is this character a letter?
-  def isLetterOrDigit: Boolean;   // is this character a letter or digit?
-  def isWhiteSpace                // is this a whitespace character?
-}
-\end{lstlisting}
-
-\subsection{Class \large{\code{Short}}}
-
-\begin{lstlisting}
-package scala;
-abstract sealed class Short extends AnyVal {
-  def coerce: Double              // convert to Double
-  def coerce: Float               // convert to Float
-  def coerce: Long                // convert to Long
-  def coerce: Int                 // convert to Int
-  def coerce: Short               // convert to Short
-}
-\end{lstlisting}
-
-\subsection{Class \large{\code{Boolean}}}
-\label{sec:cls-boolean}
-
-\begin{lstlisting}
-package scala;
-abstract sealed class Boolean extends AnyVal {
-  def && (def x: Boolean): Boolean; // boolean and
-  def || (def x: Boolean): Boolean; // boolean or
-  def &  (x: Boolean): Boolean;     // boolean strict and
-  def |  (x: Boolean): Boolean      // boolean strict or
-
-  def == (x: Boolean): Boolean      // boolean equality
-  def != (x: Boolean): Boolean      // boolean inequality
-
-  def !  (x: Boolean): Boolean      // boolean negation
-}
-\end{lstlisting}
-
-\subsection{Class \large{\code{Unit}}}
-
-\begin{lstlisting}
-package scala;
-abstract sealed class Unit extends AnyVal;
-\end{lstlisting}
-
-\section{Standard Reference Classes}
-\label{cls:reference}
-
-This section presents some standard Scala reference classes which are
-treated in a special way in Scala compiler -- either Scala provides
-syntactic sugar for them, or the Scala compiler generates special code
-for their operations. Other classes in the standard Scala library are
-documented by HTML pages elsewhere.
-
-\subsection{Class \large{\code{String}}}
-
-The \verb@String@ class is usually derived from the standard String
-class of the underlying host system (and may be identified with
-it). For Scala clients the class is taken to support in each case a
-method
-\begin{lstlisting}
-def + (that: Any): String 
-\end{lstlisting}
-which concatenates its left operand with the textual representation of its
-right operand.
-
-\subsection{The \large{\code{Tuple}} classes}
-
-Scala defines tuple classes \lstinline@Tuple$n$@ for $n = 2 \commadots 9$.
-These are defined as follows.
-
-\begin{lstlisting}
-package scala;
-case class Tuple$n$[+a_1, ..., +a_n](_1: a_1, ..., _$n$: a_$n$) {
-  def toString = "(" ++ _1 ++ "," ++ $\ldots$ ++ "," ++_$n$ ++ ")"
-}
-\end{lstlisting}
-
-The implicitly imported \code{Predef} object (\sref{cls:predef}) defines
-the names \code{Pair} as an alias of \code{Tuple2} and \code{Triple}
-as an alias for \code{Tuple3}.
-
-\subsection{The \large{\code{Function}} Classes}
-\label{sec:cls-function}
-
-Scala defines function classes \lstinline@Function$n$@ for $n = 1 \commadots 9$.
-These are defined as follows.
-
-\begin{lstlisting}
-package scala;
-class Function$n$[-a_1, ..., -a_$n$, +b] {
-  def apply(x_1: a_1, ..., x_$n$: a_$n$): b;
-  def toString = "<function>";
-}
-\end{lstlisting}
-
-\comment{
-There is also a module \code{Function}, defined as follows.
-\begin{lstlisting}
-package scala;
-module Function {
-  def compose[a](fs: List[(a)a]): (a)a  = {
-    x => fs match {
-      case Nil => x
-      case f :: fs1 => compose(fs1)(f(x))
-    }
-  }
-}
-\end{lstlisting}
-}
-
-A subclass of \lstinline@Function1@ represents partial functions,
-which are undefined on some points in their domain. In addition to the
-\code{apply} method of functions, partial functions also have a
-\code{isDefined} method, which tells whether the function is defined
-at the given argument:
-\begin{lstlisting}
-class PartialFunction[-a,+b] extends Function1[a, b] {
-  def isDefinedAt(x: a): Boolean
-}
-\end{lstlisting}
-
-The implicitly imported \code{Predef} object (\sref{cls:predef}) defines the name 
-\code{Function} as an alias of \code{Function1}.
-
-\subsection{Class \large{\code{Array}}}\label{cls:array}
-
-The class of generic arrays is given as follows.
-
-\begin{lstlisting}
-package scala;
-class Array[a](length: int) with Function[Int, a] {
-  def length: int;
-  def apply(i: Int): a;
-  def update(i: Int)(x: a): Unit;
-}
-\end{lstlisting}
-
-\comment{
-\begin{lstlisting}
-module Array {
-  def create[a](i1: Int): Array[a] = Array[a](i1)
-  def create[a](i1: Int, i2: Int): Array[Array[a]] = {
-    val x: Array[Array[a]] = create(i1)
-    0 to (i1 - 1) do { i => x(i) = create(i2) }
-    x
-  }
-  $\ldots$
-  def create[a](i1: Int, i2: Int, i3: Int, i4: Int, i5: Int,
-                i6: Int, i7: Int, i8: Int, i9: Int, i10: Int)
-    : Array[Array[Array[Array[Array[Array[Array[Array[Array[Array[a]]]]]]]]]] = {
-    val x: Array[Array[Array[Array[Array[Array[Array[Array[Array[a]]]]]]]]] = create(i1)
-    0 to (i1 - 1) do { i => x(i) = create(i2, i3, i4, i5, i6, i7, i8, i9, i10) }
-    x
-  }
-}
-\end{lstlisting}
-}
-
-\section{The \large{\code{Predef}} Object}\label{cls:predef}
-
-The \code{Predef} module defines standard functions and type aliases
-for Scala programs. It is always implicitly imported, so that all its
-defined members are available without qualification. Here is its
-definition for the JVM environment.
-
-\begin{lstlisting}
-package scala;
-object Predef {
-  type byte = scala.Byte;
-  type short = scala.Short;
-  type char = scala.Char;
-  type int = scala.Int;
-  type long = scala.Long;
-  type float = scala.Float;
-  type double = scala.Double;
-  type boolean = scala.Boolean;
-  type unit = scala.Unit;
-  
-  type String = java.lang.String;
-  type NullPointerException = java.lang.NullPointerException;
-  type Throwable = java.lang.Throwable;
-  // other aliases to be identified
-
-  /** Abort with error message */
-  def error(message: String): All = throw new Error(message);
-
-  /** Throw an error if given assertion does not hold. */
-  def assert(assertion: Boolean): Unit = 
-    if (!assertion) throw new Error("assertion failed");
-
-  /** Throw an error with given message if given assertion does not hold */
-  def assert(assertion: Boolean, message: Any): Unit = {
-    if (!assertion) throw new Error("assertion failed: " + message);
-
-  /** Create an array with given elements */
-  def Array[A](xs: A*): Array[A] = {
-    val array: Array[A] = new Array[A](xs.length);
-    var i = 0;
-    for (val x <- xs.elements) { array(i) = x; i = i + 1; }
-    array;
-  }
-
-  /** Aliases for pairs and triples */
-  type Pair[+p, +q] = Tuple2[p, q];
-  def Pair[a, b](x: a, y: b) = Tuple2(x, y);
-  type Triple[+a, +b, +c] = Tuple3[a, b, c];
-  def Triple[a, b, c](x: a, y: b, z: c) = Tuple3(x, y, z);
-
-  /** Alias for unary functions */
-  type Function = Function1;
-
-  /** Some standard simple functions */
-  def id[a](x: a): a = x;
-  def fst[a](x: a, y: Any): a = x;
-  def scd[a](x: Any, y: a): a = y;
-}
-\end{lstlisting}
-
-\section{Class Node}\label{cls:Node}
-\begin{lstlisting}
-package scala.xml;
-
-trait Node {
-
-  /** the label of this node */
-  def label: String;              
-
-  /** attribute axis */
-  def attribute: Map[String, String];
-
-  /** child axis (all children of this node) */
-  def child: Seq[Node];         
-
-  /** descendant axis (all descendants of this node) */
-  def descendant: Seq[Node] = child.toList.flatMap { 
-    x => x::x.descendant.asInstanceOf[List[Node]] 
-  };
-
-  /** descendant axis (all descendants of this node) */
-  def descendant_or_self: Seq[Node] = this::child.toList.flatMap { 
-    x => x::x.descendant.asInstanceOf[List[Node]] 
-  };
-
-  override def equals(x: Any): boolean = x match {
-    case that:Node => 
-      that.label == this.label && 
-        that.attribute.sameElements(this.attribute) && 
-          that.child.sameElements(this.child)
-    case _ => false
-  };
-
- /** XPath style projection function. Returns all children of this node
-  *  that are labelled with 'that. The document order is preserved.
-  */
-    def \(that: Symbol): NodeSeq = {
-      new NodeSeq({
-        that.name match {
-          case "_" => child.toList; 
-          case _ =>
-            var res:List[Node] = Nil;
-            for (val x <- child.elements; x.label == that.name) {
-              res = x::res;
-            }
-            res.reverse
-        }
-      });
-    }
-
- /** XPath style projection function. Returns all nodes labelled with the 
-  *  name 'that from the descendant_or_self axis. Document order is preserved.
-  */
-  def \\(that: Symbol): NodeSeq = {
-    new NodeSeq(
-      that.name match {
-        case "_" => this.descendant_or_self;
-        case _ => this.descendant_or_self.asInstanceOf[List[Node]].
-        filter(x => x.label == that.name);
-      })
-  }
-
-  /** hashcode for this XML node */
-  override def hashCode() = 
-    Utility.hashCode(label, attribute.toList.hashCode(), child);
-
-  /** string representation of this node */
-  override def toString() = Utility.toXML(this);
-
-}
-\end{lstlisting}
-
diff --git a/doc/reference/ReferencePartAppendix.tex b/doc/reference/ReferencePartAppendix.tex
deleted file mode 100644
index deaddf1a85..0000000000
--- a/doc/reference/ReferencePartAppendix.tex
+++ /dev/null
@@ -1,217 +0,0 @@
-\appendix
-\chapter{Scala Syntax Summary}
-
-The lexical syntax of Scala is given by the following grammar in EBNF
-form.
-
-\begin{lstlisting}
-  upper          ::=  `A' | $\ldots$ | `Z' | `$\Dollar$' | `_' $\mbox{\rm\em and Unicode Lu}$
-  lower          ::=  `a' | $\ldots$ | `z' $\mbox{\rm\em and Unicode Ll}$
-  letter         ::=  upper | lower $\mbox{\rm\em and Unicode categories Lo, Lt, Nl}$
-  digit          ::=  `0' | $\ldots$ | `9'
-  special        ::=  $\mbox{\rm\em ``all other characters in \U{0020-007F} and Unicode categories Sm, So}$
-                      $\mbox{\rm\em except parentheses ([{}]) and periods''}$
-
-  op             ::=  special {special} 
-  varid          ::=  lower {letter | digit} [`_' {digit} [id]]
-  id             ::=  upper {letter | digit} [`_' {digit} [id]]
-                   | varid
-                   | op
-                   | `\'stringLit
-
-  intLit         ::=  $\mbox{\rm\em ``as in Java''}$
-  floatLit       ::=  $\mbox{\rm\em ``as in Java''}$
-  charLit        ::=  $\mbox{\rm\em ``as in Java''}$
-  stringLit      ::=  $\mbox{\rm\em ``as in Java''}$
-  symbolLit      ::= `\'' id
-
-  comment        ::=  `/*' ``any sequence of characters'' `*/'
-                   |  `//' `any sequence of characters up to end of line''
-\end{lstlisting}
-
-The context-free syntax of Scala is given by the following EBNF
-grammar.
-
-\begin{lstlisting}
-  Literal        ::=  intLit
-                   |  floatLit
-                   |  charLit
-                   |  stringLit
-                   |  symbolLit
-                   |  true
-                   |  false
-                   |  null
-
-  StableId       ::=  id
-                   |  Path `.' id
-  Path           ::=  StableId
-                   |  [id `.'] this
-                   |  [id '.'] super [`[' id `]']`.' id
-
-  Type           ::=  Type1 `=>' Type
-                   |  `(' [Types] `)' `=>' Type
-                   |  Type1
-  Type1          ::=  SimpleType {with SimpleType} [Refinement]
-  SimpleType     ::=  SimpleType TypeArgs
-                   |  SimpleType `#' id
-                   |  StableId
-                   |  Path `.' type
-                   |  `(' Type ')'
-  TypeArgs        ::=  `[' Types `]'
-  Types           ::=  Type {`,' Type}
-  Refinement      ::=  `{' [RefineStat {`;' RefineStat}] `}'
-  RefineStat      ::=  Dcl
-                    |  type TypeDef
-                    |
-
-  Exprs           ::=  Expr {`,' Expr}
-  Expr            ::=  Bindings `=>' Expr
-                    |  Expr1
-  Expr1           ::=  if `(' Expr1 `)' Expr [[`;'] else Expr]
-                    |  try `{' Block `}' [catch Expr] [finally Expr]
-                    |  do Expr [`;'] while `(' Expr ')'
-                    |  for `(' Enumerators `)' [yield] Expr
-                    |  return [Expr]
-                    |  throw Expr
-                    |  [SimpleExpr `.'] id `=' Expr
-                    |  SimpleExpr ArgumentExprs `=' Expr
-                    |  PostfixExpr [`:' Type1]
-                    |  MethodClosure
-  PostfixExpr     ::=  InfixExpr [id]
-  InfixExpr       ::=  PrefixExpr
-                    |  InfixExpr id PrefixExpr
-  PrefixExpr      ::=  [`-' | `+' | `~' | `!'] SimpleExpr 
-  SimpleExpr      ::=  Literal
-                    |  Path
-                    |  `(' [Expr] `)'
-                    |  BlockExpr
-                    |  new Template 
-                    |  SimpleExpr `.' id 
-                    |  SimpleExpr TypeArgs
-                    |  SimpleExpr ArgumentExprs
-                    |  XmlExpr
-  ArgumentExprs   ::=  `(' [Exprs] ')'
-                    |  BlockExpr
-  MethodClosure   ::=  `.' Id {`.' Id | TypeArgs | ArgumentExprs}
-  BlockExpr       ::=  `{' CaseClause {CaseClause} `}'
-                    |  `{' Block `}'
-  Block           ::=  {BlockStat `;'} [ResultExpr]
-  BlockStat       ::=  Import
-                    |  Def
-                    |  {LocalModifier} TmplDef
-                    |  Expr1
-                    |
-  ResultExpr      ::=  Expr1
-                    |  Bindings `=>' Block
-
-  Enumerators     ::=  Generator {`;' Enumerator}
-  Enumerator      ::=  Generator
-                    |  Expr
-  Generator       ::=  val Pattern1 `<-' Expr
-
-  CaseClause      ::=  case Pattern [`if' PostfixExpr] `=>' Block 
-
-  Constr          ::=  StableId [TypeArgs] [`(' [Exprs] `)']  
-
-  Pattern         ::=  Pattern1 { `|' Pattern1 }
-  Pattern1        ::=  varid `:' Type
-                    |  `_' `:' Type
-                    |  Pattern2
-  Pattern2        ::=  [varid `@'] Pattern3
-  Pattern3        ::=  SimplePattern [ '*' | '?' | '+' ]
-                    |  SimplePattern { id SimplePattern }
-  SimplePattern   ::=  `_'
-                    |  varid
-                    |  Literal
-                    |  StableId [ `(' [Patterns] `)' ]
-                    |  `(' [Patterns] `)'
-                    |  XmlPattern
-  Patterns        ::=  Pattern {`,' Pattern}
-
-  TypeParamClause ::=  `[' VarTypeParam {`,' VarTypeParam} `]'
-  FunTypeParamClause ::=  `[' TypeParam {`,' TypeParam} `]'
-  VarTypeParam    ::=  [`+' | `-'] TypeParam
-  TypeParam       ::=  id [>: Type] [<: Type | <% Type]
-  ParamClause     ::=  `(' [Param {`,' Param}] `)'
-  ClassParamClause::=  `(' [ClassParam {`,' ClassParam}] `)'
-  Param           ::=  id `:' [`=>' Type [`*']
-  ClassParam      ::=  [{Modifier} `val'] Param
-  Bindings        ::=  id [`:' Type1]
-                    |  `(' Binding {`,' Binding `)'
-  Binding         ::=  id [`:' Type]
-
-  Modifier        ::=  LocalModifier
-                    |  private
-                    |  protected
-                    |  override 
-  LocalModifier   ::=  abstract
-                    |  final
-                    |  sealed
-
-  AttributeClause ::=  `[' Attribute {`,' Attribute} `]'
-  Attribute       ::=  Constr
-
-  Template        ::=  Constr {`with' Constr} [TemplateBody]
-  TemplateBody    ::=  `{' [TemplateStat {`;' TemplateStat}] `}'
-  TemplateStat    ::=   Import
-                    |  {AttributeClause} {Modifier} Def
-                    |  {AttributeClause} {Modifier} Dcl
-                    |  Expr
-                    |
-
-  Import          ::=  import ImportExpr {`,' ImportExpr}
-  ImportExpr      ::=  StableId `.' (id | `_' | ImportSelectors)
-  ImportSelectors ::=  `{' {ImportSelector `,'} 
-                       (ImportSelector | `_') `}'
-  ImportSelector  ::=  id [`=>' id | `=>' `_']
-
-  Dcl             ::=  val ValDcl
-                    |  var VarDcl
-                    |  def FunDcl
-                    |  type TypeDcl
-
-  ValDcl          ::=  id {`,' id} `:' Type
-  VarDcl          ::=  id {`,' id} `:' Type
-  FunDcl          ::=  FunSig {`,' FunSig} `:' Type
-  FunSig          ::=  id [FunTypeParamClause] {ParamClause}
-  TypeDcl         ::=  id [>: Type] [<: Type]
-
-  Def             ::=  val PatDef
-                    |  var VarDef
-                    |  def FunDef
-                    |  type TypeDef
-                    |  TmplDef
-  PatDef          ::=  Pattern2 {`,' Pattern2} [`:' Type] `=' Expr
-  VarDef          ::=  id {`,' id} [`:' Type] `=' Expr
-                    |  id {`,' id} `:' Type `=' `_'
-  FunDef          ::=  FunSig {`,' FunSig} `:' Type `=' Expr
-                    |  this ParamClause `=' ConstrExpr
-  TypeDef         ::=  id [TypeParamClause] `=' Type
-
-  TmplDef         ::=  ([case] class | trait) ClassDef
-                    |  [case] object ObjectDef
-  ClassDef        ::=  ClassSig {`,' ClassSig} [`:' SimpleType] ClassTemplate
-  ClassSig        ::=  id [TypeParamClause] [ClassParamClause]
-  ObjectDef       ::=  id {`,' id} [`:' SimpleType] ClassTemplate
-
-  ClassTemplate   ::=  extends Template
-                    |  TemplateBody
-                    |
-  ConstrExpr      ::=  this ArgumentExprs
-                    |  `{' this ArgumentExprs {`;' BlockStat} `}'
-
-  CompilationUnit ::=  [package QualId `;'] {TopStat `;'} TopStat
-  TopStat         ::=  {AttributeClause} {Modifier} TmplDef
-                    |  Import
-                    |  Packaging
-                    |
-  Packaging       ::=  package QualId `{' {TopStat `;'} TopStat `}'
-  QualId          ::=  id {`.' id}
-\end{lstlisting}
-
-\chapter{Implementation Status}
-
-\input{ImplementationStatus}
-
-\end{document}
-
diff --git a/doc/reference/Scala.bib b/doc/reference/Scala.bib
deleted file mode 100644
index ca253717fc..0000000000
--- a/doc/reference/Scala.bib
+++ /dev/null
@@ -1,101 +0,0 @@
-% $Id$
-
-
-%% Article
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-@article{milner:polymorphism, 
-  author	= {Robin Milner}, 
-  title		= {A Theory of Type Polymorphism in Programming}, 
-  journal	= {Journal of Computer and System Sciences}, 
-  year		= {1978}, 
-  month		= {Dec}, 
-  volume	= {17}, 
-  pages		= {348--375}, 
-  folder	= { 2-1}
-}
-
-@Article{wirth:ebnf,
-  author	= "Niklaus Wirth",
-  title		= "What can we do about the unecessary diversity of notation 
-for syntactic definitions?",
-  journal	= "Comm. ACM",
-  year		= 1977,
-  volume	= 20,
-  pages		= "822-823",
-  month		= nov
-}
-
-
-%% Book
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-@Book{abelson-sussman:structure,
-  author	= {Harold Abelson and Gerald Jay Sussman and Julie Sussman},
-  title		= {The Structure and Interpretation of Computer Programs, 2nd
-		  edition},
-  publisher	= {MIT Press},
-  address	= {Cambridge, Massachusetts},
-  year		= {1996},
-  url		= {http://mitpress.mit.edu/sicp/full-text/sicp/book/book.html}
-}
-
-@Book{goldberg-robson:smalltalk-language,
-  author	= "Adele Goldberg and David Robson",
-  title		= "{Smalltalk-80}; The Language and Its Implementation",
-  publisher	= "Addison-Wesley",
-  year		= "1983",
-  note		= "ISBN 0-201-11371-6"
-}
-
-@Book{matsumtoto:ruby,
-  author	= {Yukihiro Matsumoto},
-  title		= {{Ruby} in a Nutshell},
-  publisher	= {O'Reilly \& Associates},
-  year		= "2001",
-  month		= "nov",
-  note		= "ISBN 0-596-00214-9"
-}
-
-@Book{rossum:python,
-  author	= {Guido van Rossum and Fred L. Drake},
-  title		= {The {Python} Language Reference Manual},
-  publisher	= {Network Theory Ltd},
-  year		= "2003",
-  month		= "sep",
-  note		= {ISBN 0-954-16178-5\hspace*{\fill}\\
-		  \verb@http://www.python.org/doc/current/ref/ref.html@}
-}
-
-
-%% InProceedings
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-@InProceedings{odersky-et-al:fool10,
-  author	= {Martin Odersky and Vincent Cremet and Christine R\"ockl
-		  and Matthias Zenger},
-  title		= {A Nominal Theory of Objects with Dependent Types},
-  booktitle	= {Proc. FOOL 10},
-  year		= 2003,
-  month		= jan,
-  note		= {\hspace*{\fill}\\
-		  \verb@http://www.cis.upenn.edu/~bcpierce/FOOL/FOOL10.html@}		  
-}
-
-
-%% Misc
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-@Misc{w3c:dom,
-  author	= {W3C},
-  title		= {Document Object Model ({DOM})},
-  howpublished	= {\hspace*{\fill}\\
-		  \verb@http://www.w3.org/DOM/@}
-}
-
-@Misc{w3c:xml,
-  author	= {W3C},
-  title		= {Extensible Markup Language ({XML})},
-  howpublished	= {\hspace*{\fill}\\
-		  \verb@http://www.w3.org/TR/REC-xml@}
-}
diff --git a/doc/reference/ScalaByExample.tex b/doc/reference/ScalaByExample.tex
deleted file mode 100644
index 93fe411cb6..0000000000
--- a/doc/reference/ScalaByExample.tex
+++ /dev/null
@@ -1,620 +0,0 @@
-% $Id$
-
-\documentclass[a4paper,12pt,twoside,titlepage]{book}
-
-\usepackage{scaladoc}
-\usepackage{fleqn}
-\usepackage{modefs}
-\usepackage{math}
-\usepackage{scaladefs}
-\renewcommand{\todo}[1]{}
-
-
-
-\ifpdf
-    \pdfinfo {
-        /Author   (Martin Odersky)
-        /Title    (Scala by Example)
-        /Keywords (Scala)
-        /Subject  ()
-        /Creator  (TeX)
-        /Producer (PDFLaTeX)
-    }
-\fi
-
-\renewcommand{\doctitle}{Scala By Example\\[33mm]\ }
-\renewcommand{\docauthor}{Martin Odersky\\[53mm]\ }
-
-\begin{document}
-
-\frontmatter
-\makedoctitle
-\clearemptydoublepage
-\tableofcontents
-\mainmatter
-\sloppy
-
-\chapter{\label{chap:intro}Introduction}
-
-Scala smoothly integrates object-oriented and functional
-programming. It is designed to express common programming patterns in
-a consise, elegant, and type-safe way.  Scala introduces several
-innovative language constructs. For instance:
-\begin{itemize}
-\item
-Abstract types and mixin composition unify concepts from object and
-  module systems.
-\item
-Pattern matching over class hierarchies unifies functional and
-  object-oriented data access. It greatly simplifies the processing of
-  XML trees.
-\item
-A flexible syntax and type system enables the construction of advanced
-  libraries and new domain specific languages.
-\end{itemize}
-At the same time, Scala is compatible with Java.  Java libraries and
-frameworks can be used without glue code or additional declarations.
-
-This document introduces Scala in an informal way, through a sequence
-of examples.
-
-Chapters~\ref{chap:example-one} and \ref{chap:example-auction}
-highlight some of the features that make Scala interesting. The
-following chapters introduce the language constructs of Scala in a
-more thorough way, starting with simple expressions and functions, and
-working up through objects and classes, lists and streams, mutable
-state, pattern matching to more complete examples that show
-interesting programming techniques. The present informal exposition is
-meant to be complemented by the Scala Language Reference Manual which
-specifies Scala in a more detailed and precise way.
-
-\paragraph{Acknowledgment}
-We owe a great debt to Abelson's and Sussman's wonderful book
-``Structure and Interpretation of Computer
-Programs''\cite{abelson-sussman:structure}. Many of their examples and
-exercises are also present here. Of course, the working language has
-in each case been changed from Scheme to Scala. Furthermore, the
-examples make use of Scala's object-oriented constructs where
-appropriate.
-
-\input{ExamplesPart}
-\bibliographystyle{alpha}
-\bibliography{Scala}
-
-\end{document}
-
-
-
-\chapter{Implementing Abstract Types: Search Trees}
-
-This chapter presents unbalanced binary search trees, implemented in
-three different styles: algebraic, object-oriented, and imperative.
-In each case, a search tree package is seen as an implementation
-of a class {\em MapStruct}.
-\begin{lstlisting}
-  trait MapStruct[kt, vt] {
-    trait Map with Function1[kt, vt] {
-      def extend(key: kt, value: vt): Map;
-      def remove(key: kt): Map;
-      def domain: Stream[kt];
-      def range: Stream[vt];
-    }
-    type map <: Map;
-    val empty: map;
-  }
-\end{lstlisting}
-The \code{MapStruct} class is parameterized with a type of keys
-\code{kt} and a type of values \code{vt}. It
-specifies an abstract type \code{Map} and an abstract value
-\code{empty}, which represents empty maps.  Every implementation
-\code{Map} needs to conform to that abstract type, which
-extends the function type \code{kt => vt}
-with four new
-methods. The method \code{domain} yields a stream that enumerates the
-map's domain, i.e. the set of keys that are mapped to non-null values.
-The method \code{range} yields a stream that enumerates the function's
-range, i.e.\ the values obtained by applying the function to arguments
-in its domain.  The method
-\code{extend} extends the map with a given key/value binding, whereas
-\code{remove} removes a given key from the map's domain. Both
-methods yield a new map value as result, which has the same
-representation as the receiver object.
-
-\begin{figure}[t]
-\begin{lstlisting}
-class AlgBinTree[kt extends Ord, vt] extends MapStruct[kt, vt] {
-  private case
-    Empty extends Map,
-    Node(key: kt, value: vt, l: Map, r: Map) extends Map
-
-  final class Map extends kt => vt {
-    def apply(key: kt): vt = this match {
-      case Empty => null
-      case Node(k, v, l, r) =>
-        if (key < k) l.apply(key)
-        else if (key > k) r.apply(key)
-        else v
-    }
-
-    def extend(key: kt, value: vt): Map = this match {
-      case Empty => Node(k, v, Empty, Empty)
-      case Node(k, v, l, r) =>
-        if (key < k) Node(k, v, l.extend(key, value), r)
-        else if (key > k) Node(k, v, l, r.extend(key, value))
-        else Node(k, value, l, r)
-    }
-
-    def remove(key: kt): Map = this match {
-      case Empty => Empty
-      case Node(k, v, l, r) =>
-        if (key < k) Node(k, v, l.remove(key), r)
-        else if (key > k) Node(k, v, l, r.remove(key))
-        else if (l == Empty) r
-        else if (r == Empty) l
-        else {
-          val midKey = r.domain.head
-          Node(midKey, r.apply(midKey), l, r.remove(midKey))
-        }
-    }
-
-    def domain: Stream[kt] = this match {
-      case Empty => []
-      case Node(k, v, l, r) => Stream.concat([l.domain, [k], r.domain])
-    }
-    def range: Stream[vt] = this match {
-      case Empty => []
-      case Node(k, v, l, r) => Stream.concat([l.range, [v], r.range])
-    }
-  }
-  def empty: Map = Empty
-}
-\end{lstlisting}
-\caption{\label{fig:algbintree}Algebraic implementation of binary
-search trees}
-\end{figure}
-We now present three implementations of \code{Map}, which are all
-based on binary search trees. The \code{apply} method of a map is
-implemented in each case by the usual search function over binary
-trees, which compares a given key with the key stored in the topmost
-tree node, and depending on the result of the comparison, searches the
-left or the right hand sub-tree. The type of keys must implement the
-\code{Ord} class, which contains comparison methods
-(see Chapter~\ref{chap:classes} for a definition of class \code{Ord}).
-
-The first implementation, \code{AlgBinTree}, is given in
-Figure~\ref{fig:algbintree}. It represents a map with a
-data type \code{Map} with two cases, \code{Empty} and \code{Node}.
-
-Every method of \code{AlgBinTree[kt, vt].Map} performs a pattern
-match on the value of
-\code{this} using the \code{match} method which is defined as postfix
-function application in class \code{Object} (\sref{sec:class-object}).
-
-The functions \code{domain} and \code{range} return their results as
-lazily constructed lists. The \code{Stream} class is an alias of
-\code{List} which should be used to indicate the fact that its values
-are constructed lazily.
-
-\begin{figure}[thb]
-\begin{lstlisting}
-class OOBinTree[kt extends Ord, vt] extends MapStruct[kt, vt] {
-  abstract class Map extends kt => vt {
-    def apply(key: kt): v
-    def extend(key: kt, value: vt): Map
-    def remove(key: kt): Map
-    def domain: Stream[kt]
-    def range: Stream[vt]
-  }
-  module empty extends Map {
-    def apply(key: kt) = null
-    def extend(key: kt, value: vt) = Node(key, value, empty, empty)
-    def remove(key: kt) = empty
-    def domain = []
-    def range = []
-  }
-  private class Node(k: kt, v: vt, l: Map, r: Map) extends Map {
-    def apply(key: kt): vt =
-      if (key < k) l.apply(key)
-      else if (key > k) r.apply(key)
-      else v
-    def extend(key: kt, value: vt): Map =
-      if (key < k) Node(k, v, l.extend(key, value), r)
-      else if (key > k) Node(k, v, l, r.extend(key, value))
-      else Node(k, value, l, r)
-    def remove(key: kt): Map =
-      if (key < k) Node(k, v, l.remove(key), r)
-      else if (key > k) Node(k, v, l, r.remove(key))
-      else if (l == empty) r
-      else if (r == empty) l
-      else {
-        val midKey = r.domain.head
-        Node(midKey, r(midKey), l, r.remove(midKey))
-      }
-    def domain: Stream[kt] = Stream.concat([l.domain, [k], r.domain])
-    def range: Stream[vt] = Stream.concat([l.range, [v], r.range])
-  }
-}
-\end{lstlisting}
-\caption{\label{fig:oobintree}Object-oriented implementation of binary
-search trees}
-\end{figure}
-
-The second implementation of maps is given in
-Figure~\ref{fig:oobintree}.  Class \code{OOBinTree} implements the
-type \code{Map} with a module \code{empty} and a class
-\code{Node}, which define the behavior of empty and non-empty trees,
-respectively.
-
-Note the different nesting structure of \code{AlgBinTree} and
-\code{OOBinTree}. In the former, all methods form part of the base
-class \code{Map}. The different behavior of empty and non-empty trees
-is expressed using a pattern match on the tree itself. In the
-latter, each subclass of \code{Map} defines its own set of
-methods, which override the methods in the base class. The pattern
-matches of the algebraic implementation have been replaced by the
-dynamic binding that comes with method overriding.
-
-Which of the two schemes is preferable depends to a large degree on
-which extensions of the type are anticipated. If the type is later
-extended with a new alternative, it is best to keep methods in each
-alternative, the way it was done in \code{OOBinTree}.  On the other
-hand, if the type is extended with additional methods, then it is
-preferable to keep only one implementation of methods and to rely on
-pattern matching, since this way existing subclasses need not be
-modified.
-
-\begin{figure}
-\begin{lstlisting}
-class MutBinTree[kt extends Ord, vt] extends MapStruct[kt, vt] {
-  class Map(key: kt, value: vt) extends kt => vt {
-    val k = key
-    var v = value
-    var l = empty, r = empty
-
-    def apply(key: kt): vt =
-      if (this eq empty) null
-      else if (key < k) l.apply(key)
-      else if (key > k) r.apply(key)
-      else v
-
-    def extend(key: kt, value: vt): Map =
-      if (this eq empty) Map(key, value)
-      else {
-        if (key < k) l = l.extend(key, value)
-        else if (key > k) r = r.extend(key, value)
-        else v = value
-        this
-      }
-
-    def remove(key: kt): Map =
-      if (this eq empty) this
-      else if (key < k) { l = l.remove(key) ; this }
-      else if (key > k) { r = r.remove(key) ; this }
-      else if (l eq empty) r
-      else if (r eq empty) l
-      else {
-        var mid = r
-        while (!(mid.l eq empty)) { mid = mid.l }
-        mid.r = r.remove(mid.k)
-        mid.l = l
-        mid
-      }
-
-    def domain: Stream[kt] = Stream.concat([l.domain, [k], r.domain])
-    def range: Stream[vt] = Stream.concat([l.range, [v], r.range])
-  }
-  let empty = new Map(null, null)
-}
-\end{lstlisting}
-\caption{\label{fig:impbintree}Side-effecting implementation of binary
-search trees}
-\end{figure}
-
-The two versions of binary trees presented so far are {\em
-persistent}, in the sense that maps are values that cannot be changed
-by side effects. By contrast, in the next implementation of binary
-trees, the implementations of \code{extend} and
-\code{remove} do have an effect on the state of their receiver
-object. This corresponds to the way binary trees are usually
-implemented in imperative languages. The new implementation can lead
-to some savings in computing time and memory allocation, but care is
-required not to use the original tree after it has been modified by a
-side-effecting operation.
-
-In this implementation, \code{value}, \code{l} and \code{r} are
-variables that can be affected by method calls.  The
-class \code{MutBinTree[kt, vt].Map} takes two instance parameters
-which define the \code{key} value and the initial value of the
-\code{value} variable. Empty trees are represented by a
-value \code{empty}, which has \code{null} (signifying undefined) in
-both its key and value fields. Note that this value needs to be
-defined lazily using \code{let} since its definition involves the
-creation of a
-\code{Map} object,
-which accesses \code{empty} recursively as part of its initialization.
-All methods test first whether the current tree is empty using the
-reference equality operator \code{eq} (\sref{sec:class-object}).
-
-As a program using the \code{MapStruct} abstraction, consider a function
-which creates a map from strings to integers and then applies it to a
-key string:
-\begin{lstlisting}
-def mapTest(mapImpl: => MapStruct[String, int]): int = {
-  val map: mapImpl.Map = mapImpl.empty.extend("ab", 1).extend("bx", 3)
-  val x = map("ab")             // returns 1
-}
-\end{lstlisting}
-The function is parameterized with the particular implementation of
-\code{MapStruct}. It can be applied to any one of the three implementations
-described above. E.g.:
-\begin{lstlisting}
-mapTest(AlgBinTree[String, int])
-mapTest(OOBinTree[String, int])
-mapTest(MutBinTree[String, int])
-\end{lstlisting}
-}
- 
-
-
-
-
-\paragraph{Mixin Composition}
-We can now define a class of \code{Rational} numbers that
-support comparison operators.
-\begin{lstlisting}
-final class OrderedRational(n: int, d: int)
- extends Rational(n, d) with Ord {
-  override def ==(that: OrderedRational) =
-    numer == that.numer && denom == that.denom;
-  def <(that: OrderedRational): boolean =
-    numer * that.denom < that.numer * denom;
-}
-\end{lstlisting}
-Class \code{OrderedRational} redefines method \code{==}, which is
-defined as reference equality in class \code{Object}. It also
-implements the abstract method \code{<} from class \code{Ord}.  In
-addition, it inherits all members of class \code{Rational} and all
-non-abstract members of class \code{Ord}. The implementations of
-\code{==} and \code{<} replace the definition of \code{==} in class
-\code{Object} and the abstract declaration of \code{<} in class
-\code{Ord}. The other inherited comparison methods then refer to this
-implementation in their body.
-
-The clause ``\code{Rational(d, d) with Ord}'' is an instance of {\em
-mixin composition}. It describes a template for an object that is
-compatible with both \code{Rational} and \code{Ord} and that contains
-all members of either class. \code{Rational} is called the {\em
-superclass} of \code{OrderedRational} while \code{Ord} is called a
-{\em mixin class}. The type of this template is the {\em compound
-type} ``\code{Rational with Ord}''.
-
-On the surface, mixin composition looks much like multiple
-inheritance. The difference between the two becomes apparent if we
-look at superclasses of inherited classes. With multiple inheritance,
-both \code{Rational} and \code{Ord} would contribute a superclass
-\code{Object} to the template. We therefore have to answer some
-tricky questions, such as whether members of \code{Object} are present
-once or twice and whether the initializer of \code{Object} is called
-once or twice. Mixin composition avoids these complications.  In the
-mixin composition \code{Rational with Ord}, class
-\code{Rational} is treated as actual superclass of class \code{Ord}.
-A mixin composition \code{C with M} is well-formed as long as the
-first operand \code{C} conforms to the declared superclass of the
-second operand \code{M}. This holds in our example, because
-\code{Rational} conforms to \code{Object}. In a sense, mixin composition
-amounts to overriding the superclass of a class.
-
-\paragraph{Final Classes}
-Note that class \code{OrderedRational} was defined
-\code{final}. This means that no classes extending \code{OrderedRational}
-may be defined in other parts of the program.
-%Within final classes the
-%type \code{this} is an alias of the defined class itself. Therefore,
-%we could define our \code{<} method with an argument of type
-%\code{OrderedRational} as a well-formed implementation of the abstract class
-%\code{less(that: this)} in class \code{Ord}.
-
-\chapter{\label{sec:simple-examples}Pattern Matching}
-
-\todo{Complete}
-
-Consider binary trees whose leafs contain integer arguments. This can
-be described by a class for trees, with subclasses for leafs and
-branch nodes:
-\begin{lstlisting}
-abstract class Tree;
-case class Branch(left: Tree, right: Tree) extends Tree;
-case class Leaf(x: int) extends Tree;
-\end{lstlisting}
-Note that the class \code{Tree} is not followed by an extends
-clause or a body. This defines \code{Tree} to be an empty
-subclass of \code{Object}, as if we had written
-\begin{lstlisting}
-class Tree extends Object {}
-\end{lstlisting}
-Note also that the two subclasses of \code{Tree} have a \code{case}
-modifier.  That modifier has two effects. First, it lets us construct
-values of a case class by simply calling the constructor, without
-needing a preceding \code{new}. Example:
-\begin{lstlisting}
-val tree1 = Branch(Branch(Leaf(1), Leaf(2)), Branch(Leaf(3), Leaf(4)))
-\end{lstlisting}
-Second, it lets us use constructors for these classes in patterns, as
-is illustrated in the following example.
-\begin{lstlisting}
-def sumLeaves(t: Tree): int = t match {
-  case Branch(l, r) => sumLeaves(l) + sumLeaves(r)
-  case Leaf(x) => x
-}
-\end{lstlisting}
-The function \code{sumLeaves} sums up all the integer values in the
-leaves of a given tree \code{t}. It is is implemented by calling the
-\code{match} method of \code{t} with a {\em choice expression} as
-argument (\code{match} is a predefined method in class \code{Object}).
-The choice expression consists of two cases which botrelate a pattern with an expression. The pattern of the first case,
-\code{Branch(l, r)} matches all instances of class \code{Branch}
-and binds the {\em pattern variables} \code{l} and \code{r} to the
-constructor arguments, i.e.\ the left and right subtrees of the
-branch.  Pattern variables always start with a lower case letter; to
-avoid ambiguities, constructors in patterns should start with an upper
-case letter.
-
-The effect of the choice expression is to select the first alternative
-whose pattern matches the given select value, and to evaluate the body
-of this alternative in a context where pattern variables are bound to
-corresponding parts of the selector. For instance, the application
-\code{sumLeaves(tree1)} would select the first alternative with the
-\code{Branch(l,r)} pattern, and would evaluate the expression
-\code{sumLeaves(l) + sumLeaves(r)} with bindings
-\begin{lstlisting}
-l = Branch(Leaf(1), Leaf(2)), r = Branch(Leaf(3), Leaf(4)).
-\end{lstlisting}
-As another example, consider the following class
-\begin{lstlisting}
-abstract final class Option[+a];
-case object None extends Option[All];
-case class Some[a](item: a) extends Option[a];
-\end{lstlisting}
-...
-
-%\todo{Several simple and intermediate examples needed}.
-
-\begin{lstlisting}
-def find[a,b](it: Iterator[(a, b)], x: a): Option[b] = {
-  var result: Option[b] = None;
-  while (it.hasNext && result == None) {
-    val (x1, y) = it.next;
-    if (x == x1) result = Some(y)
-  }
-  result
-}
-find(xs, x) match {
-  case Some(y) => System.out.println(y)
-  case None => System.out.println("no match")
-}
-\end{lstlisting}
-
-\comment{
-
-
-class MaxCounter {
-  var maxVal: Option[int] = None;
-  def set(x: int) = maxVal match {
-    case None => maxVal = Some(x)
-    case Some(y) => maxVal = Some(Math.max(x, y))
-  }
-}
-\end{lstlisting}
-}
-\comment{
-\begin{lstlisting}
-class Stream[a] = List[a]
-
-module Stream {
-  def concat(xss: Stream[Stream[a]]): Stream[a] = {
-    let result: Stream[a] = xss match {
-      case [] => []
-      case [] :: xss1 => concat(xss1)
-      case (x :: xs) :: xss1 => x :: concat(xs :: xss1)
-    }
-    result
-  }
-}
-\end{lstlisting}
-}
-\comment{
-}
-%\todo{We also need some XML examples.}
-
-\end{document}
-
-
-
-  case ([], _) => ys
-  case (_, []) => xs
-  case (x :: xs1, y :: ys1) =>
-    if (x < y) x :: merge(xs1, ys) else y :: merge(xs, ys1)
-}
-
-def split (xs: List[a]): (List[a], List[a]) = xs match {
-  case [] => ([], [])
-  case [x] => (x, [])
-  case y :: z :: xs1 => val (ys, zs) = split(xs1) ; (y :: ys, z :: zs)
-}
-
-def sort(xs: List[a]): List[a] = {
-  val (ys, zs) = split(xs)
-  merge(sort(ys), sort(zs))
-}
-
-
-def sort(a:Array[String]): Array[String] = {
-  val pivot = a(a.length / 2)
-  sort(a.filter(x => x < pivot)) ++
-       a.filter(x => x == pivot) ++
-  sort(a.filter(x => x > pivot))
-}
-
-def sort(a:Array[String]): Array[String] = {
-
-  def swap (i: int, j: int): unit = {
-    val t = a(i) ; a(i) = a(j) ; a(j) = t
-  }
-
-  def sort1(l: int, r: int): unit = {
-    val pivot = a((l + r) / 2)
-    var i = l, j = r
-    while (i <= r) {
-      while (i < r && a(i) < pivot) { i = i + 1 }
-      while (j > l && a(j) > pivot) { j = j - 1 }
-      if (i <= j) {
-        swap(i, j)
-        i = i + 1
-        j = j - 1
-      }
-    }
-    if (l < j) sort1(l, j)
-    if (j < r) sort1(i, r)
-  }
-
-  sort1(0, a.length - 1)
-}
-
-class Array[a] {
-
-  def copy(to: Array[a], src: int, dst: int, len: int): unit
-  val length: int
-  val apply(i: int): a
-  val update(i: int, x: a): unit
-
-  def filter (p: a => boolean): Array[a] = {
-    val temp = new Array[a](a.length)
-    var i = 0, j = 0
-    for (i < a.length, i = i + 1) {
-      val x = a(i)
-      if (p(x)) { temp(j) = x; j = j + 1 }
-    }
-    val res = new Array[a](j)
-    temp.copy(res, 0, 0, j)
-  }
-
-  def ++ (that: Array[a]): Array[a] = {
-    val a = new Array[a](this.length + that.length)
-    this.copy(a, 0, 0, this.length)
-    that.copy(a, 0, this.length, that.length)
-  }
-
-static
-
-  def concat [a] (as: List[Array[a]]) = {
-    val l = (as map (a => a.length)).sum
-    val dst = new Array[a](l)
-    var j = 0
-    as forall {a => { a.copy(dst, j, a.length) ; j = j + a.length }}
-    dst
-  }
-
-}
-
-module ABT extends AlgBinTree[kt, vt]
-ABT.Map
diff --git a/doc/reference/ScalaRationale.tex b/doc/reference/ScalaRationale.tex
deleted file mode 100644
index 99ef99c1b5..0000000000
--- a/doc/reference/ScalaRationale.tex
+++ /dev/null
@@ -1,25 +0,0 @@
-% $Id$
-
-\documentclass[a4paper,11pt]{article}
-
-\usepackage{fleqn}
-\usepackage{modefs}
-\usepackage{math}
-\usepackage{scaladefs}
-
-\title{Scala Rationale}
-
-\author{
-Martin Odersky
-}
-
-\sloppy
-\begin{document}
-\maketitle
-
-\input{RationalePart}
-
-\bibliographystyle{alpha}
-\bibliography{Scala}
-
-\end{document}
\ No newline at end of file
diff --git a/doc/reference/ScalaReference.tex b/doc/reference/ScalaReference.tex
deleted file mode 100644
index 87be986e10..0000000000
--- a/doc/reference/ScalaReference.tex
+++ /dev/null
@@ -1,104 +0,0 @@
-% $Id$
-
-%%% ------------- how to edit this file: -----------------------------------------------------
-
-%%% o Do not use tabs, but spaces in grammars !
-
-%%% ------------- how to compile this file: --------------------------------------------------
-
-%%% you need to enable TeX to use the files ``ul9.map'' and ``fourier_v03.map''. Otherwise, the
-%%% resulting output will not include necessary font information. 
-
-%%% o how to make a TeX installation use these fonts
-
-%%% (1) Get root, go to /usr/share/texmf/dvips/config
-%%% (2) Edit the file ./updmap by adding two new lines to the
-%%%    extra_modules section. Initially it is empty, and should
-%%%    look like this after the modifications:
-%%%
-%%%    extra_modules="
-%%%      /<full-path-to>/ul9.map
-%%%      /<full-path-to>/fourier.map
-%%%    "
-%%%
-%%% (3) Execute ./updmap (still as root) to integrate the new fonts into
-%%%    "hundreds" of messy tex config files.
-%%% (4) Execute texhash (still as root) so that the kpsetools can find
-%%%    the new files. From now on, you do not have to be root anymore.
-%%%
-%%% in LAMP, you can find those files here 
-%%% /home/linuxsoft/share/texmf/dvips/config/ul9.map
-%%% /home/linuxsoft/share/texmf/dvips/fourier/fourier.map
-
-%%% o last step: get normal user again and enable your tex tools to find the fonts as well
-
-%%% Adjust your environment varables. In LAMP: 
-%%% (5)         setenv HOMETEXMF /home/linuxsoft/share/texmf
-
-%%% or, if you have a local texmf structure use
-
-%%% (5')        setenv TEXMF /home/myname/texmf,/home/linuxsoft/share/texmf,/usr/share/texmf
-
-%%% Please note that whenever you redefine TEXMF it will ignore HOMETEXMF
-%%% unless you specify it explicitly in the TEXMF initialization.
-
-\documentclass[a4paper,12pt,twoside,titlepage]{book}
-
-\usepackage{scaladoc}
-\usepackage{fleqn}
-\usepackage{modefs}
-\usepackage{math}
-\usepackage{scaladefs}
-
-\ifpdf
-    \pdfinfo {
-        /Author   (Martin Odersky)
-        /Title    (The Scala Language Specification)
-        /Keywords (Scala)
-        /Subject  ()
-        /Creator  (TeX)
-        /Producer (PDFLaTeX)
-    }
-\fi
-
-\newcommand{\exercise}{\paragraph{Exercise}}
-\newcommand{\rewriteby}[1]{\mbox{\tab\tab\rm(#1)}}
-
-\renewcommand{\doctitle}{Scala By Example\\[33mm]\ }
-\renewcommand{\docauthor}{Martin Odersky\\[53mm]\ }
-\renewcommand{\doctitle}{The Scala Language \\ Specification \\
-\Large  Version 1.0 \ }
-\renewcommand{\docauthor}{Martin Odersky \\
-Philippe Altherr \\
-Vincent Cremet \\
-Burak Emir \\ 
-St\'ephane Micheloud \\
-Nikolay Mihaylov \\
-Michel Schinz \\
-Erik Stenman \\
-Matthias Zenger \\[25mm]\ }
-
-\begin{document}
-\frontmatter
-\makedoctitle
-\clearemptydoublepage
-\tableofcontents
-\mainmatter
-\sloppy
-
-%\todo{`:' as synonym for $\EXTENDS$?}
-
-\part{Rationale}
-
-\input{RationalePart}
-
-\part{The Scala Language Specification}
-
-\input{ReferencePart}
-
-\bibliographystyle{alpha}
-\bibliography{Scala}
-
-\input{ReferencePartAppendix}
-
-\end{document}
diff --git a/doc/tutorial/Makefile b/doc/tutorial/Makefile
deleted file mode 100644
index f55675ef56..0000000000
--- a/doc/tutorial/Makefile
+++ /dev/null
@@ -1,37 +0,0 @@
-############################################################-*-Makefile-*-####
-# Scala Tutorial
-##############################################################################
-# $Id$
-
-##############################################################################
-# Configuration
-
-ROOT			 = ../..
-
-include $(ROOT)/Makefile.import
-
-##############################################################################
-# Variables
-
-# project
-PROJECT_SOURCES		+= $(LATEX_SOURCES)
-
-# latex
-LATEX_FORMATS		+= dvi
-LATEX_FORMATS		+= ps
-LATEX_FORMATS		+= pdf
-
-LATEX_TARGETS		+= $(LATEX_FORMATS:%=ScalaTutorial.%)
-
-LATEX_SOURCES		+= ScalaTutorial.tex
-
-# latex
-TEXINPUTS		:= $(PROJECT_SUPPORTDIR)/latex:$(TEXINPUTS):
-
-##############################################################################
-# Includes
-
-include $(PROJECT_SUPPORTDIR)/make/scalatex.mk
-include $(PROJECT_SUPPORTDIR)/make/latex.mk
-
-##############################################################################
diff --git a/doc/tutorial/ScalaTutorial.scala.tex b/doc/tutorial/ScalaTutorial.scala.tex
deleted file mode 100644
index 512417da0e..0000000000
--- a/doc/tutorial/ScalaTutorial.scala.tex
+++ /dev/null
@@ -1,778 +0,0 @@
-%% This file really contains -*- LaTeX -*- code, to be processed by
-%% the scalatex script.
-
-%% $Id$
-
-\documentclass[a4paper,12pt,twoside,titlepage]{article}
-
-\usepackage{scaladoc}
-\usepackage{xspace}
-
-\ifpdf
-    \pdfinfo {
-        /Author   (Michel Schinz)
-        /Title    (A Scala Tutorial)
-        /Keywords (Scala programming language tutorial)
-        /Subject  (Basic introduction to Scala, mostly for Java programmers)
-        /Creator  (TeX)
-        /Producer (PDFLaTeX)
-    }
-\fi
-
-\renewcommand{\doctitle}{A Scala Tutorial \\
-\large  for Java programmers \ }
-\renewcommand{\docsubtitle}{Version 1.0}
-\renewcommand{\docauthor}{Michel Schinz\\[65mm]}
-
-\newcommand{\langname}[1]{#1\xspace}
-
-\newcommand{\Scala}{\langname{Scala}}
-\newcommand{\Java}{\langname{Java}}
-
-\newcommand{\toolname}[1]{\texttt{#1}\xspace}
-
-\newcommand{\scalac}{\toolname{scalac}}
-\newcommand{\scala}{\toolname{scala}}
-\newcommand{\java}{\toolname{java}}
-
-\begin{document}
-\makedoctitle
-
-\section{Introduction}
-\label{sec:introduction}
-
-This document gives a quick introduction to the \Scala language and
-compiler. It is intended for people who already have some programming
-experience and want an overview of what they can do with \Scala. A
-basic knowledge of object-oriented programming, especially in \Java,
-is assumed.
-
-\section{A first example}
-\label{sec:first-example}
-
-As a first example, we will use the standard \emph{Hello world}
-program. It is not very fascinating but makes it easy to demonstrate
-the use of the \Scala tools without knowing too much about the
-language. Here is how it looks:
-\begin{scalaprogram}{HelloWorld}
-object HelloWorld {
-  def main(args: Array[String]): unit = {
-    System.out.println("Hello, world!");
-  }
-}
-\end{scalaprogram}
-
-The structure of this program should be familiar to Java programmers:
-it consists of one method called \code{main} which takes the command
-line arguments, an array of strings, as parameter; the body of this
-method consists of a single call to the \code{println} method of the
-object representing the standard output, with the friendly greeting as
-argument. The \code{main} method is declared as returning a value of
-type \code{unit}, which for now can be seen as similar to \Java's
-\code{void} type.
-
-What is less familiar to Java programmers is the \code{object}
-declaration containing the \code{main} method. Such a declaration
-introduces what is commonly known as a \emph{singleton object}, that
-is a class with a single instance. The declaration above thus declares
-both a class called \code{HelloWorld} and an instance of that class,
-also called \code{HelloWorld}. This instance is created on demand,
-the first time it is used.
-
-The astute reader might have noticed that the \code{main} method is
-not declared as \code{static} here. This is because static members
-(methods or fields) do not exist in \Scala. Rather than defining static
-members, the \Scala programmer declares these members in singleton
-objects.
-
-\subsection{Compiling the example}
-\label{sec:compiling-example}
-
-To compile the example, we use \scalac, the \Scala compiler. \scalac
-works like most compilers: it takes a source file as argument, maybe
-some options, and produces one or several object files. The object
-files it produces are standard \Java class files.
-
-If we save the above program in a file called
-\code{HelloWorld.scala}, we can compile it by issuing the following
-command (the greater-than sign `\verb|>|' represents the shell prompt
-and should not be typed):
-\begin{verbatim}
-> scalac HelloWorld.scala
-\end{verbatim}
-This will generate a few class files in the current directory. One of
-them will be called \code{HelloWorld.class}, and contains a class
-which can be directly executed using the \scala command, as the
-following section shows.
-
-\subsection{Running the example}
-\label{sec:running-example}
-
-Once compiled, a \Scala program can be run using the \scala command.
-Its usage is very similar to the \java command used to run \Java
-programs, and accepts the same options. The above example can be
-executed using the following command, which produces the expected
-output:
-\begin{verbatim}
-> scala -classpath . HelloWorld
-\end{verbatim}
-\scalaprogramoutput{HelloWorld}
-
-\section{Interaction with Java}
-\label{sec:inter-with-java}
-
-One of the strength of \Scala is that it makes it very easy to
-interact with \Java code. Actually, the example of the previous
-section showed this: to print the message on screen, we simply used a
-call to \Java's \code{println} method on the (\Java) object
-\code{System.out}.
-
-All \Java code is accessible as easily from \Scala. Like in \Java, all
-classes from the \code{java.lang} package are imported by default,
-while others need to be imported explicitly.
-
-Let's look at another example to see this. The aim of this example is
-to compute and print the factorial of 100 using \Java big integers
-(i.e. the class \code{BigInteger} in package \code{java.math}),
-since the result does not fit in a \Java integer. This program looks
-like this:
-\begin{scalaprogram}{BigFactorial}
-object BigFactorial {
-  import java.math.BigInteger, BigInteger._;
-
-  def fact(x: BigInteger): BigInteger =
-    if (x == ZERO) ONE
-    else x multiply fact(x subtract ONE);
-
-  def main(args: Array[String]): unit =
-    System.out.println("fact(100) = "
-                       + fact(new BigInteger("100")));
-}
-\end{scalaprogram}
-
-\Scala's \code{import} statement looks very similar to \Java's
-equivalent, but an important difference appears here: to import all
-the names of a package or class, one uses the underscore (\verb|_|)
-character instead of the asterisk (\verb|*|). That's because the
-asterisk is actually a valid \Scala identifier, as we will see later.
-
-The \code{import} statement above therefore starts by importing the
-class \code{BigInteger}, and then all the names it
-contains. This makes the static fields \code{ZERO} and \code{ONE}
-directly visible.
-
-While we're talking about \code{ZERO}, something must be said about
-the condition of the \code{if} expression in method \code{fact}. Is
-it really correct to check that \code{x} is zero by using the
-\code{==} operator? A \Java programmer would say no, because in that
-language the \code{==} operator compares objects by physical
-equality, and this is not what we want here. What we want to know is
-whether \code{x} is \emph{some} big integer object representing zero,
-and there might be several of them. So a \Java programmer would use
-the \code{equals} method to perform the comparison.
-
-The \Scala programmer, on the other hand, can use \code{==} here
-because that operator compares objects according to the \code{equals}
-method. Is \code{==} just an alias for \code{equals} then? Well,
-almost, but \code{==} has one advantage over \code{equals} in that
-it works also when the selector is the \code{null} constant.
-
-The \code{fact} method also shows some characteristics of \Scala's
-syntax. The first one is that the method body does not have to be
-surrounded by curly braces if it consists of a single expression.
-The second one is that methods taking one argument can be used with an
-infix syntax. That is, the expression
-\begin{lstlisting}
-x subtract ONE
-\end{lstlisting}
-is just another, slightly less verbose way of writing the expression
-\begin{lstlisting}
-x.subtract(ONE)
-\end{lstlisting}
-This might seem like a minor syntactic detail, but it has important
-consequences, one of which will be explored in the next section.
-
-To conclude this section about integration with \Java, it should be
-noted that it is also possible to inherit from \Java classes and
-implement \Java interfaces directly in \Scala.
-
-\section{Everything is an object}
-\label{sec:everything-an-object}
-
-\Scala is a pure object-oriented language in the sense that
-\emph{everything} is an object, including numbers or functions. It
-differs from \Java in that respect, since \Java distinguishes numeric
-types from objects, and does not enable one to manipulate functions as
-values.
-
-\subsection{Numbers are objects}
-\label{sec:numbers-are-objects}
-
-Since numbers are objects, they also have methods. And in fact, an
-arithmetic expression like the following:
-\begin{lstlisting}
-1 + 2 * 3 / x
-\end{lstlisting}
-consists exclusively of method calls, because it is equivalent to the
-following expression, as we saw in the previous section:
-\begin{lstlisting}
-1.+(2.*(3./(x)))
-\end{lstlisting}
-This also means that \code{+}, \code{*}, etc. are valid identifiers
-in \Scala.
-
-\subsection{Functions are objects}
-\label{sec:funct-are-objects}
-
-Perhaps more surprising for the \Java programmer, functions are also
-objects in \Scala. It is therefore possible to pass functions as
-arguments, to store them in variables, and to return them from other
-functions. This ability to manipulate functions as values is one of
-the cornerstone of a very interesting programming paradigm called
-\emph{functional programming}.
-
-As a very simple example of why it can be useful to use functions as
-values, let's consider a timer function whose aim is to perform some
-action every second. How do we pass it the action to perform? Quite
-logically, as a function. This very simple kind of function passing
-should be familiar to many programmers: it is often used in
-user-interface code, to register call-back functions which get called
-when some event occurs.
-
-In the following program, the timer function is called
-\code{oncePerSecond}, and it gets a call-back function as argument.
-The type of this function is written \verb|() => unit| and is the type
-of all functions which have no arguments and return a value of type
-\code{unit}. The main function of this program simply calls this
-timer function with a call-back which prints a sentence on the
-terminal. In other words, this program endlessly prints the sentence
-\emph{time flies like an arrow} every second.
-\begin{scalaprogram}{Timer}
-object Timer {
-  def oncePerSecond(callback: () => unit): unit =
-    while (true) { callback(); Thread sleep 1000 };
-
-  def timeFlies(): unit =
-    Console.println("time flies like an arrow...");
-
-  def main(args: Array[String]): unit =
-    oncePerSecond(timeFlies);
-}
-\end{scalaprogram}
-We note that in order to print the string, we used method
-\code{println} of class \code{Console} instead of using the one from
-\code{System.out}. For now, \code{Console} can be seen as a \Scala
-equivalent of \Java's \code{System.out}.
-
-\subsubsection{Anonymous functions}
-\label{sec:anonymous-functions}
-
-While this program is easy to understand, it can be refined a bit.
-First of all, notice that the function \code{timeFlies} is only
-defined in order to be passed later to the \code{oncePerSecond}
-function. Having to name that function, which is only used once, might
-seem unnecessary, and it would in fact be nice to be able to construct
-this function just as it is passed to \code{oncePerSecond}. This is
-possible in \Scala using \emph{anonymous functions}, which are exactly
-that: functions without a name. The revised version of our timer
-program using an anonymous function instead of \code{timeFlies} looks
-like that:
-\begin{scalaprogram}{TimerAnonymous}
-object TimerAnonymous {
-  def oncePerSecond(callback: () => unit): unit =
-    while (true) { callback(); Thread sleep 1000 };
-
-  def main(args: Array[String]): unit =
-    oncePerSecond(() =>
-      Console.println("time flies like an arrow..."));
-}
-\end{scalaprogram}
-The presence of an anonymous function in this example is revealed by
-the right arrow `\verb|=>|' which separates the function's argument
-list from its body. In this example, the argument list is empty, as
-witnessed by the empty pair of parenthesis on the left of the arrow.
-The body of the function is the same as the one of \code{timeFlies}
-above.
-
-% TODO fonctions avec environnement
-
-\section{Classes}
-\label{sec:classes}
-
-As we have seen above, \Scala is an object-oriented language, and as
-such it has a concept of class.\footnote{For the sake of completeness,
-  it should be noted that some object-oriented languages do not have
-  the concept of class, but \Scala is not one of them.}
-Classes in \Scala are declared using a syntax which is close to
-\Java's syntax. One important difference is that classes in \Scala can
-have parameters. This is illustrated in the following definition of
-complex numbers.
-\begin{scalaprogram}{Complex}
-class Complex(real: double, imaginary: double) {
-  def re() = real;
-  def im() = imaginary;
-}
-\end{scalaprogram}
-This complex class takes two arguments, which are the real and
-imaginary part of the complex. These arguments must be passed when
-creating an instance of class \code{Complex}, as follows: \code{new
-  Complex(1.5, 2.3)}. The class contains two methods, called \code{re}
-and \code{im}, which give access to these two parts.
-
-It should be noted that the return type of these two methods is not
-given explicitly. It will be inferred automatically by the compiler,
-which looks at the right-hand side of these methods and deduces that
-both return a value of type \code{double}.
-
-The compiler is not always able to infer types like it does here, and
-there is unfortunately no simple rule to know exactly when it will be,
-and when not. In practice, this is usually not a problem since the
-compiler complains when it is not able to infer a type which was not
-given explicitly. As a simple rule, beginner \Scala programmers should
-try to omit type declarations which seem to be easy to deduce from the
-context, and see if the compiler agrees. After some time, the
-programmer should get a good feeling about when to omit types, and
-when to specify them explicitly.
-
-\subsection{Methods without arguments}
-\label{sec:meth-wo-args}
-
-A small problem of the methods \code{re} and \code{im} is that, in
-order to call them, one has to put an empty pair of parenthesis after
-their name, as the following example shows:
-\begin{lstlisting}[escapechar=\#]
-val c = new Complex(1.2, 3.4);
-Console.println("imaginary part: " + c.im());
-\end{lstlisting}
-It would be nicer to be able to access the real and imaginary parts
-like if they were fields, without putting the empty pair of
-parenthesis. This is perfectly doable in \Scala, simply by defining
-them as methods \emph{without arguments}. Such methods differ from
-methods with zero arguments in that they don't have parenthesis after
-their name, neither in their definition nor in their use. Our
-\code{Complex} class can be rewritten as follows:
-\begin{scalaprogram}{Complex2}
-class Complex(real: double, imaginary: double) {
-  def re = real;
-  def im = imaginary;
-}
-\end{scalaprogram}
-
-\subsection{Inheritance and overriding}
-\label{sec:inheritance}
-
-All classes in \Scala inherit from a super-class. When no super-class
-is specified, as in the \code{Complex} example of previous section,
-\code{scala.Object} is implicitly used.
-
-It is possible to override methods inherited from a super-class in
-\Scala. It is however mandatory to explicitly specify that a method
-overrides another one using the \code{override} modifier, in order to
-avoid accidental overriding. As an example, our \code{Complex} class
-can be augmented with a redefinition of the \code{toString} method
-inherited from \code{Object}.
-\begin{scalaprogram}{Complex3}
-class Complex(real: double, imaginary: double) {
-  def re = real;
-  def im = imaginary;
-  override def toString() =
-    "" + re + (if (im < 0) "" else "+") + im + "i";
-}
-\end{scalaprogram}
-
-\section{Case classes and pattern matching}
-\label{sec:case-classes-pattern}
-
-A kind of data structure that often appears in programs is the tree.
-For example, interpreters and compilers usually represent programs
-internally as trees; XML documents are trees; and several kinds of
-containers are based on trees, like red-black trees.
-
-We will now examine how such trees are represented and manipulated in
-\Scala through a small calculator program. The aim of this program is
-to manipulate very simple arithmetic expressions composed of sums,
-integer constants and variables. Two examples of such expressions are
-$1+2$ and $(x+x)+(7+y)$.
-
-We first have to decide on a representation for such expressions. The
-most natural one is the tree, where nodes are operations (here, the
-addition) and leaves are values (here constants or variables).
-
-In \Java, such a tree would be represented using an abstract
-super-class for the trees, and one concrete sub-class per node or
-leaf. In a functional programming language, one would use an algebraic
-data-type for the same purpose. \Scala provides the concept of
-\emph{case classes} which is somewhat in between the two. Here is how
-they can be used to define the type of the trees for our example:
-\beginscalaprogram{Calculator}
-\begin{scalacode}
-abstract class Tree;
-case class Sum(l: Tree, r: Tree) extends Tree;
-case class Var(n: String) extends Tree;
-case class Const(v: int) extends Tree;
-\end{scalacode}
-The fact that classes \code{Sum}, \code{Var} and \code{Const} are
-declared as case classes means that they differ from standard classes
-in several respects:
-\begin{itemize}
-\item the \code{new} keyword is not mandatory to create instances of
-  these classes (i.e. one can write \code{Const(5)} instead of
-  \code{new Const(5)}),
-\item getter functions are automatically defined for the constructor
-  parameters (i.e. it is possible to get the value of the \code{v}
-  constructor parameter of some instance \code{c} of class
-  \code{Const} just by writing \code{c.v}),
-\item default definitions for methods \code{equals} and
-  \code{hashCode} are provided, which work on the \emph{structure} of
-  the instances and not on their identity,
-\item a default definition for method \code{toString} is provided, and
-  prints the value in a ``source form'' (e.g. the tree for expression
-  $x+1$ prints as \code{Sum(Var(x),Const(1))}),
-\item instances of these classes can be decomposed through
-  \emph{pattern matching} as we will see below.
-\end{itemize}
-
-Now that we have defined the data-type to represent our arithmetic
-expressions, we can start defining operations to manipulate them. We
-will start with a function to evaluate an expression in some
-\emph{environment}. The aim of the environment is to give values to
-variables. For example, the expression $x+1$ evaluated in an
-environment which associates the value $5$ to variable $x$, written
-\{$x\rightarrow 5$\}, gives $6$ as result.
-
-We therefore have to find a way to represent environments. We could of
-course use some associative data-structure like a hash table, but we
-can also directly use functions! An environment is really nothing more
-than a function which associates a value to a (variable) name. The
-environment \{$x\rightarrow 5$\} given above can simply be written as
-follows in \Scala:
-\begin{lstlisting}
-  { case "x" => 5 }
-\end{lstlisting}
-This notation defines a function which, when given the string
-\code{"x"} as argument, returns the integer 5, and fails with an
-exception otherwise.
-
-Before writing the evaluation function, let us give a name to the type
-of the environments. We could of course always use the type
-\code{String => int} for environments, but it simplifies the program
-if we introduce a name for this type, and makes future changes easier.
-This is accomplished in \Scala with the following notation:
-\begin{scalainvisiblecode}
-object Calculator {
-\end{scalainvisiblecode}
-\begin{scalacode}
-  type Environment = (String => int);
-\end{scalacode}
-From then on, the type \code{Environment} can be used as an alias of
-the type of functions from \code{String} to \code{int}.
-
-We can now give the definition of the evaluation function.
-Conceptually, it is very simple: the value of a sum of two expressions
-is simply the sum of the value of these expressions; the value of a
-variable is obtained directly from the environment; and the value of a
-constant is the constant itself. Expressing this in \Scala is not more
-difficult:
-\begin{scalacode}
-  def eval(t: Tree, env: Environment): int = t match {
-    case Sum(l, r) => eval(l, env) + eval(r, env)
-    case Var(n)    => env(n)
-    case Const(v)  => v
-  }
-\end{scalacode}
-This evaluation function works by performing \emph{pattern matching}
-on the tree \code{t}. Intuitively, the meaning of the above definition
-should be clear:
-\begin{enumerate}
-\item it first checks if the tree \code{t} is a \code{Sum}, and if it
-  is, it binds the left sub-tree to a new variable called \code{l} and
-  the right sub-tree to a variable called \code{r}, and then proceeds
-  with the evaluation of the expression following the arrow; this
-  expression can (and does) make use of the variables bound by the
-  pattern appearing on the left of the arrow, i.e. \code{l} and
-  \code{r},
-\item if the first check does not succeed, that is if the tree is not
-  a \code{Sum}, it goes on and checks if \code{t} is a \code{Var}; if
-  it is, it binds the name contained in the \code{Var} node to a
-  variable \code{n} and proceeds with the right-hand expression,
-\item if the second check also fails, that is if \code{t} is neither a
-  \code{Sum} nor a \code{Var}, it checks if it is a \code{Const}, and
-  if it is, it binds the value contained in the \code{Const} node to a
-  variable \code{v} and proceeds with the right-hand side,
-\item finally, if all checks fail, an exception is raised to signal
-  the failure of the pattern matching expression; this could happen
-  here only if more sub-classes of \code{Tree} were declared.
-\end{enumerate}
-We see that the basic idea of pattern matching is to attempt to match
-a value to a series of patterns, and as soon as a pattern matches,
-extract and name various parts of the value, to finally evaluate some
-code which typically makes use of these named parts.
-
-A seasoned object-oriented programmer might wonder why we did not
-define \code{eval} as a \emph{method} of class \code{Tree} and its
-subclasses. We could have done it actually, since \Scala allows method
-definitions in case classes just like in normal classes. Deciding
-whether to use pattern matching or methods is therefore a matter of
-taste, but it also has important implications on extensibility:
-\begin{itemize}
-\item when using methods, it is easy to add a new kind of node as this
-  can be done just by defining the sub-class of \code{Tree} for it; on
-  the other hand, adding a new operation to manipulate the tree is
-  tedious, as it requires modifications to all sub-classes of
-  \code{Tree},
-\item when using pattern matching, the situation is reversed: adding a
-  new kind of node requires the modification of all functions which do
-  pattern matching on the tree, to take the new node into account; on
-  the other hand, adding a new operation is easy, by just defining it
-  as an independent function.
-\end{itemize}
-
-To explore pattern matching further, let us define another operation
-on arithmetic expressions: symbolic derivation. The reader might
-remember the following rules regarding this operation:
-\begin{enumerate}
-\item the derivative of a sum is the sum of the derivatives,
-\item the derivative of some variable $v$ is one if $v$ is the
-  variable relative to which the derivation takes place, and zero
-  otherwise,
-\item the derivative of a constant is zero.
-\end{enumerate}
-These rules can be translated almost literally into \Scala code, to
-obtain the following definition:
-\begin{scalacode}
-  def derive(t: Tree, v: String): Tree = t match {
-    case Sum(l, r) => Sum(derive(l, v), derive(r, v))
-    case Var(n) if (v == n) => Const(1)
-    case _ => Const(0)
-  }
-\end{scalacode}
-This function introduces two new concepts related to pattern matching.
-First of all, the \code{case} expression for variables has a
-\emph{guard}, an expression following the \code{if} keyword. This
-guard prevents pattern matching from succeeding unless its expression
-is true. Here it is used to make sure that we return the constant 1
-only if the name of the variable being derived is the same as the
-derivation variable \code{v}. The second new feature of pattern
-matching used here is the \emph{wild-card}, written \code{_}, which is
-a pattern matching any value, without giving it a name.
-
-We did not explore the whole power of pattern matching yet, but we
-will stop here in order to keep this document short. We still want to
-see how the two functions above perform on a real example. For that
-purpose, let's write a simple \code{main} function which performs
-several operations on the expression $(x+x)+(7+y)$: it first computes
-its value in the environment $\{x\rightarrow 5, y\rightarrow 7\}$, then
-computes its derivative relative to $x$ and then $y$.
-\begin{scalacode}
-  def main(args: Array[String]): Unit = {
-    val exp: Tree = Sum(Sum(Var("x"),Var("x")),Sum(Const(7),Var("y")));
-    val env: Environment = { case "x" => 5 case "y" => 7 };
-    Console.println("Expression: " + exp);
-    Console.println("Evaluation with x=5, y=7: " + eval(exp, env));
-    Console.println("Derivative relative to x:\n " + derive(exp, "x"));
-    Console.println("Derivative relative to y:\n " + derive(exp, "y"));
-  }
-\end{scalacode}
-\begin{scalainvisiblecode}
-} // object Calculator
-\end{scalainvisiblecode}
-\endscalaprogram{Calculator}
-Executing this program, we get the expected output:
-\scalaprogramoutput{Calculator}
-By examining the output, we see that the result of the derivative
-should be simplified before being presented to the user. Defining a
-basic simplification function using pattern matching is an interesting
-(but surprisingly tricky) problem, left as an exercise for the reader.
-
-\section{Mixins}
-\label{sec:mixins}
-
-Apart from inheriting code from a super-class, a \Scala class can also
-import code from one or several \emph{mixins}.
-
-Maybe the easiest way for a \Java programmer to understand what mixins
-are is to view them as interfaces which can also contain code. In
-\Scala, when a class inherits from a mixin, it implements that mixin's
-interface, and inherits all the code contained in the mixin.
-
-To see the usefulness of mixins, let's look at a classical example:
-ordered objects. It is often useful to be able to compare objects of a
-given class among themselves, for example to sort them. In \Java,
-objects which are comparable implement the \code{Comparable}
-interface. In \Scala, we can do a bit better than in \Java by defining
-our equivalent of \code{Comparable} as a mixin, which we will call
-\code{Ord}.
-
-When comparing objects, six different predicates can be useful:
-smaller, smaller or equal, equal, not equal, greater or equal, and
-greater. However, defining all of them is fastidious, especially since
-four out of these six can be expressed using the remaining two. That
-is, given the equal and smaller predicates (for example), one can
-express the other ones. In \Scala, all these observations can be
-nicely captured by the following mixin declaration:
-\beginscalaprogram{Ord}
-\begin{scalacode}
-abstract class Ord {
-  def < (that: Any): boolean;
-  def <=(that: Any): boolean = (this < that) || (this == that);
-  def > (that: Any): boolean = !(this <= that);
-  def >=(that: Any): boolean = !(this < that);
-} 
-\end{scalacode}
-This definition both creates a new type called \code{Ord}, which
-plays the same role as \Java's \code{Comparable} interface, and
-default implementations of three predicates in terms of a fourth,
-abstract one. The predicates for equality and inequality do not appear
-here since they are by default present in all objects.
-
-The type \code{Any} which is used above is the type which is a
-super-type of all other types in \Scala. It can be seen as a more
-general version of \Java's \code{Object} type, since it is also a
-super-type of basic types like \code{int}, \code{float}, etc.
-
-To make objects of a class comparable, it is therefore sufficient to
-define the predicates which test equality and inferiority, and mix in
-the \code{Ord} class above. As an example, let's define a
-\code{Date} class representing dates in the Gregorian calendar. Such
-dates are composed of a day, a month and a year, which we will all
-represent as integers. We therefore start the definition of the
-\code{Date} class as follows:
-\begin{scalacode}
-class Date(y: int, m: int, d: int) with Ord {
-  def year = y;
-  def month = m;
-  def day = d;
-
-  override def toString(): String = year + "-" + month + "-" + day;
-\end{scalacode}
-The important part here is the \code{with Ord} declaration which
-follows the class name and parameters. It declares that the
-\code{Date} class inherits from the \code{Ord} class as a mixin.
-
-Then, we redefine the \code{equals} method, inherited from
-\code{Object}, so that it correctly compares dates by comparing their
-individual fields. The default implementation of \code{equals} is not
-usable, because as in \Java it compares object physically. We arrive
-at the following definition:
-\begin{scalacode}
-  override def equals(that: Any): boolean = {
-    that.isInstanceOf[Date] && {
-      val o = that.asInstanceOf[Date];
-      o.day == day && o.month == month && o.year == year
-    }
-  }
-\end{scalacode}
-This method makes use of the predefined methods \code{isInstanceOf}
-and \code{asInstanceOf}. The first one, \code{isInstanceOf},
-corresponds to \Java's \code{instanceof} operator, and returns true
-if and only if the object on which it is applied is an instance of the
-given type. The second one, \code{asInstanceOf}, corresponds to
-\Java's cast operator: If the object is an instance of the given type,
-it is viewed as such, otherwise a \code{ClassCastException} is
-thrown.
-
-Finally, the last method to define is the predicate which tests for
-inferiority, as follows. It makes use of another predefined method,
-\code{error}, which throws an exception with the given error message.
-\begin{scalacode}
-  def <(that: Any): boolean = {
-    if (!that.isInstanceOf[Date])
-      error("cannot compare " + that + " and a Date");
-
-    val o = that.asInstanceOf[Date];
-    (year < o.year)
-      || (year == o.year && (month < o.month
-                               || (month == o.month && day < o.day)))
-  }
-}
-\end{scalacode}
-\endscalaprogram{Ord}
-This completes the definition of the \code{Date} class. Instances of
-this class can be seen either as dates or as comparable objects.
-Moreover, they all define the six comparison predicates mentioned
-above: \code{equals} and \code{<} because they appear directly in
-the definition of the \code{Date} class, and the others because they
-are inherited from the \code{Ord} mixin.
-
-Mixins are useful in other situations than the one shown here, of
-course, but discussing their applications in length is outside the
-scope of this document.
-
-\section{Genericity}
-\label{sec:genericity}
-
-The last characteristic of \Scala we will explore in this tutorial is
-genericity. \Java programmers should be well aware of the problems
-posed by the lack of genericity in their language, a shortcoming which
-is addressed in \Java 1.5.
-
-Genericity is the ability to write code parametrised by types. For
-example, a programmer writing a library for linked lists faces the
-problem of deciding which type to give to the elements of the list.
-Since this list is meant to be used in many different contexts, it is
-not possible to decide that the type of the elements has to be, say,
-\code{int}. This would be completely arbitrary and overly
-restrictive.
-
-\Java programmers resort to using \code{Object}, which is the
-super-type of all objects. This solution is however far from being
-ideal, since it doesn't work for basic types (\code{int},
-\code{long}, \code{float}, etc.) and it implies that a lot of
-dynamic type casts have to be inserted by the programmer.
-
-\Scala makes it possible to define generic classes (and methods) to
-solve this problem. Let us examine this with an example of the
-simplest container class possible: a reference, which can either be
-empty or point to an object of some type.
-\beginscalaprogram{Reference}
-\begin{scalacode}
-class Reference[a] {
-  private var contents: a = _;
-
-  def set(value: a): Unit = { contents = value; }
-  def get: a = contents;
-}
-\end{scalacode}
-The class \code{Reference} is parametrised by a type, called \code{a},
-which is the type of its element. This type is used in the body of the
-class as the type of the \code{contents} variable, the argument of
-the \code{set} method, and the return type of the \code{get} method.
-
-The above code sample introduces variables in \Scala, which should not
-require further explanations. It is however interesting to see that
-the initial value given to that variable is \code{_}, which represents
-a default value. This default value is 0 for numeric types,
-\code{false} for the boolean type, \code{()} for the unit type and
-\code{null} for all object types.
-
-To use this \code{Reference} class, one needs to specify which type to use
-for the type parameter \code{a}, that is the type of the element
-contained by the cell. For example, to create and use a cell holding
-an integer, one could write the following:
-\begin{scalacode}
-object IntegerReference {
-  def main(args: Array[String]): Unit = {
-    val cell = new Reference[Int];
-    cell.set(13);
-    Console.print("Reference contains the half of " + (cell.get * 2));
-  }
-}
-\end{scalacode}
-\endscalaprogram{Reference}
-As can be seen in that example, it is not necessary to cast the value
-returned by the \code{get} method before using it as an integer. It
-is also not possible to store anything but an integer in that
-particular cell, since it was declared as holding an integer.
-
-\section{Conclusion}
-\label{sec:conclusion}
-
-This document gave a quick overview of the \Scala language and
-presented some basic examples. The interested reader can go on by
-reading the companion document \textit{Scala By Example\/}, which
-contains much more advanced examples, and consult the \textit{Scala
-  Language Specification\/} when needed.
-
-\end{document}
-
-% LocalWords:  mixins mixin mixin's genericity