Binary file handouts/scala-ho.pdf has changed
--- a/handouts/scala-ho.tex Mon Sep 15 03:49:07 2014 +0100
+++ b/handouts/scala-ho.tex Mon Sep 15 04:16:28 2014 +0100
@@ -280,7 +280,7 @@
first tests whether \code{n} is equal to 1 in which case it
returns \code{true} and so on.
-Notice a quirk in Scala's syntax for \code{if}s: The condition
+Notice the quirk in Scala's syntax for \code{if}s: The condition
needs to be enclosed in parentheses and the then-case comes
right after the condition---there is no \code{then} keyword in
Scala.
@@ -606,10 +606,11 @@
(Int, Int) => (Int, Int)
\end{lstlisting}
-Another special type-constructor is for functions, written
-as the arrow \code{=>}. For example, the type
-\code{Int => String} is for a function that takes an integer as argument
-and produces a string. A function of this type is for instance
+Another special type-constructor is for functions, written as
+the arrow \code{=>}. For example, the type \code{Int =>
+String} is for a function that takes an integer as input
+argument and produces a string as result. A function of this
+type is for instance
\begin{lstlisting}[numbers=none]
def mk_string(n: Int) : String = n match {
@@ -620,7 +621,7 @@
}
\end{lstlisting}
-\noindent It takes an integer as argument and returns a
+\noindent It takes an integer as input argument and returns a
string. Unlike other functional programming languages, there
is in Scala no easy way to find out the types of existing
functions, except by looking into the documentation
@@ -662,7 +663,7 @@
version of \code{chk_string}---once specialised to 2 and once
to 3. This kind of ``specialising'' a function is called
\emph{partial application}---we have not yet given to this
-function all arguments it needs, but only one of them.
+function all arguments it needs, but only some of them.
Coming back to the type \code{Int => String => Boolean}. The
rule about such function types is that the right-most type
@@ -687,10 +688,13 @@
\end{lstlisting}
You might ask: Apart from silly functions like above, what is
-the point of having function as arguments to other functions?
-In Java there is indeed no need of this kind of feature. But
-in all functional programming languages, including Scala, it
-is really essential. Above you already seen \code{map} and
+the point of having functions as input arguments to other
+functions? In Java there is indeed no need of this kind of
+feature: at least in the past it did not allow such
+constructions. I think, the point of Java 8 is to lift this
+restriction. But in all functional programming languages,
+including Scala, it is really essential to allow functions as
+input argument. Above you already seen \code{map} and
\code{foreach} which need this. Consider the functions
\code{print} and \code{println}, which both print out strings,
but the latter adds a line break. You can call \code{foreach}
@@ -783,7 +787,7 @@
\noindent This gets quickly unreadable when the strings and
regular expressions get more complicated. In other functional
-programming language, you can explicitly write a conversion
+programming languages, you can explicitly write a conversion
function that takes a string, say \dq{\pcode{for}}, and
generates the regular expression above. But then your code is
littered with such conversion functions.