%% 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