- incorporated suggestions by Erik and Stephane.

1 files changed, 23 insertions, 26 deletions

diff --git a/doc/tutorial/ScalaTutorial.scala.tex b/doc/tutorial/ScalaTutorial.scala.tex
index f35b4cb793..085d947418 100644
--- a/doc/tutorial/ScalaTutorial.scala.tex
+++ b/doc/tutorial/ScalaTutorial.scala.tex
@@ -41,8 +41,8 @@
 \label{sec:introduction}
 
 This document gives a quick introduction to the \Scala language and
-compiler. It is intended for people who have already some experience
-at programming and want an overview of what they can do with \Scala. A
+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.
 
@@ -80,17 +80,17 @@ 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 define static
+(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 need to 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.
+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
@@ -126,10 +126,9 @@ 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. Of course, it is
-sometimes necessary to import classes, as one does in \Java, in order
-to be able to use them. All classes in the \code{java.lang} packages
-are imported by default, others need to be imported explicitly.
+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
@@ -153,9 +152,8 @@ object BigFactorial {
 \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|*|). This is due to the fact
-that, as we will see later, the asterisk is actually a valid \Scala
-identifier.
+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
@@ -329,12 +327,11 @@ 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 superfluous to them,
-because they are easily deduced from the context, and see whether the
-compiler agrees with them. After some time, they should get a good
-feeling about when to omit types, and when to specify them
-explicitly.
+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}
@@ -349,7 +346,7 @@ Console.println("imaginary part: " + c.im());
 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
-the methods as methods \emph{without arguments}. These differ from
+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:
@@ -393,12 +390,12 @@ 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. Examples of such expressions include
-$1+2$ or $(x+x)+(7+y)$.
+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 to use is the tree, where nodes are operations (here,
-the addition) and leaves are values (here constants or variables).
+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
@@ -430,7 +427,7 @@ in several respects:
 \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 \code{Tree} can be decomposed through
+\item instances of these classes can be decomposed through
   \emph{pattern matching} as we will see below.
 \end{itemize}