Fixed some smaller typographic bugs.

5 files changed, 171 insertions, 19 deletions

diff --git a/doc/reference/Makefile b/doc/reference/Makefile
index dc47a23dd3..f0192974a8 100644
--- a/doc/reference/Makefile
+++ b/doc/reference/Makefile
@@ -21,15 +21,13 @@ LATEX_FORMATS		+= dvi
 LATEX_FORMATS		+= ps
 LATEX_FORMATS		+= pdf
 
-LATEX_TARGETS		+= $(LATEX_FORMATS:%=rationale.%)
-LATEX_TARGETS		+= $(LATEX_FORMATS:%=reference.%)
-LATEX_TARGETS		+= $(LATEX_FORMATS:%=examples.%)
-
-LATEX_SOURCES		+= examples.tex
-LATEX_SOURCES		+= examples.bib
-LATEX_SOURCES		+= rationale.tex
-LATEX_SOURCES		+= reference.tex
-LATEX_SOURCES		+= rationale-chapter.tex
+LATEX_TARGETS		+= $(LATEX_FORMATS:%=ScalaReference.%)
+LATEX_TARGETS		+= $(LATEX_FORMATS:%=ScalaByExample.%)
+
+LATEX_SOURCES		+= ScalaByExample.tex
+LATEX_SOURCES       += ScalaReference.tex
+LATEX_SOURCES		+= Scala.bib
+LATEX_SOURCES		+= Rationale.tex
 
 # latex
 TEXINPUTS		:= $(PROJECT_SUPPORTDIR)/latex:$(TEXINPUTS):
diff --git a/doc/reference/Rationale.tex b/doc/reference/Rationale.tex
new file mode 100644
index 0000000000..5187663f1e
--- /dev/null
+++ b/doc/reference/Rationale.tex
@@ -0,0 +1,125 @@
+%% $Id$
+
+There are hundreds of programming languages in active use, and many more are
+being designed each year. It is therefore very hard to justify the development
+of yet another language. Nevertheless, this is what I attempt to do here. My
+argument rests 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}
+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.
+
+To back up the second claim, one notes that today's object-oriented languages
+are not very good tools for analyzing and transforming the trees which
+conceptually model XML data. Because these 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 is to represent trees in a generic way, where all tree nodes are
+values of a common type.  This approach is used in DOM, for instance. It
+facilitates the implementation of generic traversal functions, but forces
+applications to operate on a very low conceptual level, which often loses
+important semantic distinctions that are present in the XML data. A
+semantically more precise alternative would be to use different internal types
+to 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.
+
+Web services can be constructed using such a transformation language
+together with some middleware framework such as Corba to handle
+distribution and an object-oriented language for the ``application
+logic''.  The downside of this approach is that the necessary amount
+of cross-language glue can make applications cumbersome to write,
+verify, and maintain.  Better productivity and trustworthiness is
+achievable using a single notation and conceptual framework that would
+express object-oriented, concurrent, as well as functional aspects of
+an application.  Hence, a case for so called ``multi-paradigm''
+languages can be made. But one needs to be careful not to simply
+replace cross-language glue by awkward interfaces between different
+paradigms within the language itself. The benefits of integration are
+realized fully only if the common language achieves a meaningful
+unification of concepts rather than being merely an agglutination of
+different programming paradigms.  This is what we try to achieve with
+Scala\footnote{Scala stands for ``Scalable Language''.}.
+
+Scala is both an 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 interact well 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}
+
+%The 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/Scala.bib b/doc/reference/Scala.bib
new file mode 100644
index 0000000000..a0bbd57115
--- /dev/null
+++ b/doc/reference/Scala.bib
@@ -0,0 +1,20 @@
+
+@Book{		  abelson-sussman:structure,
+  author	= {Harold Abelson and Gerald Jay Sussman and Julie Sussman},
+  title		= {The Structure and Interpretation of Computer Programs, 2nd
+		  edition},
+  year		= {1996},
+  publisher	= {MIT Press},
+  address	= {Cambridge, Massachusetts}
+}
+
+@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		= {\verb@http://www.cis.upenn.edu/~bcpierce/FOOL/FOOL10.html@}
+		  
+}
diff --git a/doc/reference/ScalaByExample.tex b/doc/reference/ScalaByExample.tex
index fdc2c60598..51877e0ed9 100644
--- a/doc/reference/ScalaByExample.tex
+++ b/doc/reference/ScalaByExample.tex
@@ -1,3 +1,4 @@
+% $Id$
 \documentclass[a4paper,12pt,twoside,titlepage]{book}
 
 \usepackage{scaladoc}
@@ -21,7 +22,7 @@
 \newcommand{\rewriteby}[1]{\mbox{\tab\tab\rm(#1)}}
 
 \renewcommand{\doctitle}{Scala By Example\\[33mm]\ }
-\renewcommand{\docauthor}{Martin Odersky}
+\renewcommand{\docauthor}{Martin Odersky\\[53mm]\ }
 
 \begin{document}
 
@@ -34,7 +35,7 @@
 
 \chapter{\label{chap:intro}Introduction}
 
-\input{rationale-chapter.tex}
+\input{Rationale}
 
 The rest of this document is structured as
 follows. Chapters~\ref{chap:example-one} and
@@ -5416,6 +5417,10 @@ class Bidder (auction: Process, minBid: int, maxBid: int)
 \end{lstlisting}
 }
 %\todo{We also need some XML examples.}
+
+\bibliographystyle{alpha}
+\bibliography{Scala}
+
 \end{document}
 
 
diff --git a/doc/reference/ScalaReference.tex b/doc/reference/ScalaReference.tex
index b564adbb21..e45bf98d64 100644
--- a/doc/reference/ScalaReference.tex
+++ b/doc/reference/ScalaReference.tex
@@ -2,7 +2,11 @@
 \documentclass[a4paper,12pt,twoside,titlepage]{book}
 
 \usepackage{scaladoc}
-\usepackage{fleqn,modefs,math,scaladefs}
+\usepackage{fleqn}
+\usepackage{modefs}
+\usepackage{math}
+\usepackage{scaladefs}
+
 \newcommand{\tps}{\mbox{\sl tps}}
 \newcommand{\psig}{\mbox{\sl psig}}
 \newcommand{\args}{\mbox{\sl args}}
@@ -14,9 +18,9 @@
 \ifpdf
     \pdfinfo {
         /Author   (Martin Odersky, Philippe Altherr, Vincent Cremet,
-    Burak Emir, St\'ephane Micheloud, Nikolay Mihaylov, Michel Schinz,
-    Erik Stenman, Matthias Zenger)
-        /Title    (Report on the Programming Language Scala)
+                   Burak Emir, Stephane Micheloud, Nikolay Mihaylov,
+                   Michel Schinz, Erik Stenman, Matthias Zenger)
+        /Title    (The Scala Language Specification)
         /Keywords (Scala)
         /Subject  ()
         /Creator  (TeX)
@@ -33,8 +37,8 @@
 \renewcommand{\todo}[1]{{$\clubsuit$\bf todo: #1$\spadesuit$}}
 \newcommand{\notyet}{\footnote{not yet implemented.}}
 
-\renewcommand{\doctitle}{\LARGE The Scala Language \\ Specification}
-\renewcommand{\docauthor}{\normalsize Martin Odersky \\
+\renewcommand{\doctitle}{The Scala Language \\ Specification \\ \ }
+\renewcommand{\docauthor}{Martin Odersky \\
 Philippe Altherr \\
 Vincent Cremet \\
 Burak Emir \\ 
@@ -42,7 +46,7 @@ St\'ephane Micheloud \\
 Nikolay Mihaylov \\
 Michel Schinz \\
 Erik Stenman \\
-Matthias Zenger}
+Matthias Zenger \\[25mm]\ }
 
 \begin{document}
 
@@ -58,7 +62,7 @@ Matthias Zenger}
 
 \chapter{Rationale}
 
-\input{rationale-chapter}
+\input{Rationale}
 
 \subsection*{Status of This Document}