\documentclass{article}+ −
\usepackage{../style}+ −
\usepackage{../langs}+ −
\usepackage{marvosym}+ −
+ −
%cheat sheet+ −
%http://worldline.github.io/scala-cheatsheet/+ −
+ −
\begin{document}+ −
+ −
\section*{A Crash-Course in Scala}+ −
+ −
\subsection*{The Very Basics}+ −
+ −
One advantage of Scala over Java is that it includes an interpreter (a+ −
REPL, or+ −
\underline{R}ead-\underline{E}val-\underline{P}rint-\underline{L}oop)+ −
with which you can run and test small code-snippets without the need+ −
of a compiler. This helps a lot with interactively developing+ −
programs. Once you installed Scala, you can start the interpreter by+ −
typing on the command line:+ −
+ −
\begin{lstlisting}[language={},numbers=none,basicstyle=\ttfamily\small]+ −
$ scala+ −
Welcome to Scala 2.12.4 (Java HotSpot(TM) 64-Bit Server VM, Java 9).+ −
Type in expressions for evaluation. Or try :help.+ −
+ −
scala>+ −
\end{lstlisting}%$+ −
+ −
\noindent The precise response may vary depending+ −
on the version and platform where you installed Scala. At the Scala+ −
prompt you can type things like \code{2 + 3}\;\keys{Ret} and+ −
the output will be+ −
+ −
\begin{lstlisting}[numbers=none]+ −
scala> 2 + 3+ −
res0: Int = 5+ −
\end{lstlisting}+ −
+ −
\noindent indicating that the result of the addition is of type+ −
\code{Int} and the actual result is 5; \code{res0} is a name that+ −
Scala gives automatically to the result. You can reuse this name later+ −
on. Another classic example you can try out is+ −
+ −
\begin{lstlisting}[numbers=none]+ −
scala> print("hello world")+ −
hello world+ −
\end{lstlisting}+ −
+ −
\noindent Note that in this case there is no result. The+ −
reason is that \code{print} does not actually produce a result+ −
(there is no \code{resX} and no type), rather it is a+ −
function that causes the \emph{side-effect} of printing out a+ −
string. Once you are more familiar with the functional+ −
programming-style, you will know what the difference is+ −
between a function that returns a result, like addition, and a+ −
function that causes a side-effect, like \code{print}. We+ −
shall come back to this point later, but if you are curious+ −
now, the latter kind of functions always has \code{Unit} as+ −
return type. It is just not printed.+ −
+ −
You can try more examples with the Scala interpreter, but try+ −
first to guess what the result is (not all answers by Scala are obvious):+ −
+ −
\begin{lstlisting}[numbers=none]+ −
scala> 2 + 2+ −
scala> 1 / 2+ −
scala> 1.0 / 2+ −
scala> 1 / 2.0+ −
scala> 1 / 0+ −
scala> 1.0 / 0.0+ −
scala> true == false+ −
scala> true && false+ −
scala> 1 > 1.0+ −
scala> "12345".length+ −
\end{lstlisting}+ −
+ −
\subsection*{Stand-Alone Scala Apps}+ −
+ −
If you want to write a stand-alone app in Scala, you can+ −
implement an object that is an instance of \code{App}, say+ −
+ −
\begin{lstlisting}[numbers=none]+ −
object Hello extends App {+ −
println("hello world")+ −
}+ −
\end{lstlisting}+ −
+ −
\noindent save it in a file, for example {\tt hello-world.scala}, and+ −
then run the compiler and runtime environment:+ −
+ −
\begin{lstlisting}[language={},numbers=none,basicstyle=\ttfamily\small]+ −
$ scalac hello-world.scala+ −
$ scala Hello+ −
hello world+ −
\end{lstlisting}+ −
+ −
\noindent+ −
Like Java, Scala targets the JVM and consequently+ −
Scala programs can also be executed by the bog-standard Java+ −
Runtime. This only requires the inclusion of {\tt+ −
scala-library.jar}, which on my computer can be done as+ −
follows:+ −
+ −
\begin{lstlisting}[language={},numbers=none,basicstyle=\ttfamily\small]+ −
$ scalac hello-world.scala+ −
$ java -cp /usr/local/src/scala/lib/scala-library.jar:. Hello+ −
hello world+ −
\end{lstlisting}+ −
+ −
\noindent You might need to adapt the path to where you have+ −
installed Scala.+ −
+ −
\subsection*{Values}+ −
+ −
In the lectures I will try to avoid as much as possible the term+ −
\emph{variables} familiar from other programming languages. The reason+ −
is that Scala has \emph{values}, which can be seen as abbreviations of+ −
larger expressions. For example+ −
+ −
\begin{lstlisting}[numbers=none]+ −
scala> val x = 42+ −
x: Int = 42+ −
+ −
scala> val y = 3 + 4+ −
y: Int = 7+ −
+ −
scala> val z = x / y+ −
z: Int = 6+ −
\end{lstlisting}+ −
+ −
\noindent+ −
Why the kerfuffle about values? Well, values are \emph{immutable}. You cannot+ −
change their value after you defined them. If you try to reassign+ −
\code{z} above, Scala will yell at you:+ −
+ −
\begin{lstlisting}[numbers=none]+ −
scala> z = 9+ −
error: reassignment to val+ −
z = 9+ −
^+ −
\end{lstlisting}+ −
+ −
\noindent+ −
So it would be a bit absurd to call values as variables...you cannot+ −
change them. You might think you can re-assign them like+ −
+ −
\begin{lstlisting}[numbers=none]+ −
scala> val x = 42+ −
scala> val z = x / 7+ −
scala> val x = 70+ −
scala> println(z) + −
\end{lstlisting}+ −
+ −
\noindent but try to guess what Scala will print out + −
for \code{z}? Will it be \code{6} or \code{10}? A final word about+ −
values: Try to stick to the convention that names of values should be+ −
lower case, like \code{x}, \code{y}, \code{foo41} and so on.+ −
+ −
+ −
\subsection*{Function Definitions}+ −
+ −
We do functional programming. So defining functions will be our main occupation.+ −
A function \code{f} taking a single argument of type \code{Int} can be defined in Scala+ −
as follows:+ −
+ −
\begin{lstlisting}[numbers=none]+ −
def f(x: Int) : String = EXPR+ −
\end{lstlisting} + −
+ −
\noindent+ −
This function returns the value resulting from evaluating the expression+ −
\code{EXPR} (whatever is substituted for this). The result will be+ −
of type \code{String}. It is a good habbit to include this information+ −
about the return type always. Simple examples of Scala functions are:+ −
+ −
\begin{lstlisting}[numbers=none]+ −
def incr(x: Int) : Int = x + 1+ −
def double(x: Int) : Int = x + x+ −
def square(x: Int) : Int = x * x+ −
\end{lstlisting}+ −
+ −
\noindent+ −
The general scheme for a function is+ −
+ −
\begin{lstlisting}[numbers=none]+ −
def fname(arg1: ty1, arg2: ty2,..., argn: tyn): rty = {+ −
BODY+ −
}+ −
\end{lstlisting}+ −
+ −
\noindent+ −
where each argument requires its type and the result type of the+ −
function, \code{rty}, should be given. If the body of the function is+ −
more complex, then it can be enclosed in braces, like above. If it it+ −
is just a simple expression, like \code{x + 1}, you can omit the+ −
braces. Very often functions are recursive (call themselves) like+ −
the venerable factorial function.+ −
+ −
\begin{lstlisting}[numbers=none]+ −
def fact(n: Int): Int = + −
if (n == 0) 1 else n * fact(n - 1)+ −
\end{lstlisting}+ −
+ −
\subsection*{Loops, or better the Absence thereof}+ −
+ −
Coming from Java or C++, you might be surprised that Scala does+ −
not really have loops. It has instead, what is in functional+ −
programming called, \emph{maps}. To illustrate how they work,+ −
let us assume you have a list of numbers from 1 to 8 and want to+ −
build the list of squares. The list of numbers from 1 to 8 + −
can be constructed in Scala as follows:+ −
+ −
\begin{lstlisting}[numbers=none]+ −
scala> (1 to 8).toList+ −
res1: List[Int] = List(1, 2, 3, 4, 5, 6, 7, 8)+ −
\end{lstlisting}+ −
+ −
\noindent Generating from this list, the list of squares in a+ −
programming language such as Java, you would assume the list+ −
is given as a kind of array. You would then iterate, or loop,+ −
an index over this array and replace each entry in the array+ −
by the square. Right? In Scala, and in other functional+ −
programming languages, you use maps to achieve the same. + −
+ −
A map essentially takes a function that describes how each+ −
element is transformed (for example squared) and a list over+ −
which this function should work. There are two forms to+ −
express such maps in Scala. The first way is called a+ −
\emph{for-comprehension}. Squaring the numbers from 1 to 8+ −
would look as follows:+ −
+ −
\begin{lstlisting}[numbers=none]+ −
scala> for (n <- (1 to 8).toList) yield n * n+ −
res2: List[Int] = List(1, 4, 9, 16, 25, 36, 49, 64)+ −
\end{lstlisting}+ −
+ −
\noindent The important keywords are \code{for} and+ −
\code{yield}. This for-comprehension roughly states that from+ −
the list of numbers we draw \code{n}s and compute the result+ −
of \code{n * n}. As you can see, we specified the list where+ −
each \code{n} comes from, namely \code{(1 to 8).toList}, and+ −
how each element needs to be transformed. This can also be+ −
expressed in a second way in Scala by using directly+ −
\code{map}s as follows:+ −
+ −
\begin{lstlisting}[numbers=none]+ −
scala> (1 to 8).toList.map(n => n * n)+ −
res3 = List(1, 4, 9, 16, 25, 36, 49, 64)+ −
\end{lstlisting}+ −
+ −
\noindent In this way, the expression \code{n => n * n} stands+ −
for the function that calculates the square (this is how the+ −
\code{n}s are transformed). This expression for functions+ −
might remind you of your lessons about the lambda-calculus+ −
where this would have been written as $\lambda n.\,n * n$. It+ −
might not be obvious, but for-comprehensions are just+ −
syntactic sugar: when compiling, Scala translates+ −
for-comprehensions into equivalent maps. This even works+ −
when for-comprehensions get more complicated (see below).+ −
+ −
The very charming feature of Scala is that such maps or+ −
for-comprehensions can be written for any kind of data+ −
collection, such as lists, sets, vectors, options and so on.+ −
For example if we instead compute the reminders modulo 3 of+ −
this list, we can write+ −
+ −
\begin{lstlisting}[numbers=none]+ −
scala> (1 to 8).toList.map(n => n % 3)+ −
res4 = List(1, 2, 0, 1, 2, 0, 1, 2)+ −
\end{lstlisting}+ −
+ −
\noindent If we, however, transform the numbers 1 to 8 not+ −
into a list, but into a set, and then compute the reminders+ −
modulo 3 we obtain+ −
+ −
\begin{lstlisting}[numbers=none]+ −
scala> (1 to 8).toSet[Int].map(n => n % 3)+ −
res5 = Set(2, 1, 0)+ −
\end{lstlisting}+ −
+ −
\noindent This is the correct result for sets, as there are+ −
only three equivalence classes of integers modulo 3. Note that+ −
in this example we need to ``help'' Scala to transform the+ −
numbers into a set of integers by explicitly annotating the+ −
type \code{Int}. Since maps and for-comprehensions are+ −
just syntactic variants of each other, the latter can also be+ −
written as+ −
+ −
\begin{lstlisting}[numbers=none]+ −
scala> for (n <- (1 to 8).toSet[Int]) yield n % 3+ −
res5 = Set(2, 1, 0)+ −
\end{lstlisting}+ −
+ −
For-comprehensions can also be nested and the selection of + −
elements can be guarded. For example if we want to pair up+ −
the numbers 1 to 4 with the letters a to c, we can write+ −
+ −
\begin{lstlisting}[numbers=none]+ −
scala> for (n <- (1 to 4).toList; + −
m <- ('a' to 'c').toList) yield (n, m)+ −
res6 = List((1,a), (1,b), (1,c), (2,a), (2,b), (2,c), + −
(3,a), (3,b), (3,c), (4,a), (4,b), (4,c))+ −
\end{lstlisting}+ −
+ −
\noindent + −
Or if we want to find all pairs of numbers between 1 and 3+ −
where the sum is an even number, we can write+ −
+ −
\begin{lstlisting}[numbers=none]+ −
scala> for (n <- (1 to 3).toList; + −
m <- (1 to 3).toList;+ −
if (n + m) % 2 == 0) yield (n, m)+ −
res7 = List((1,1), (1,3), (2,2), (3,1), (3,3))+ −
\end{lstlisting}+ −
+ −
\noindent The \code{if}-condition in the for-comprehension+ −
filters out all pairs where the sum is not even.+ −
+ −
While hopefully this all looks reasonable, there is one+ −
complication: In the examples above we always wanted to+ −
transform one list into another list (e.g.~list of squares),+ −
or one set into another set (set of numbers into set of+ −
reminders modulo 3). What happens if we just want to print out+ −
a list of integers? Then actually the for-comprehension+ −
needs to be modified. The reason is that \code{print}, you+ −
guessed it, does not produce any result, but only produces+ −
what is in the functional-programming-lingo called a+ −
side-effect. Printing out the list of numbers from 1 to 5+ −
would look as follows+ −
+ −
\begin{lstlisting}[numbers=none]+ −
scala> for (n <- (1 to 5).toList) print(n)+ −
12345+ −
\end{lstlisting}+ −
+ −
\noindent+ −
where you need to omit the keyword \code{yield}. You can+ −
also do more elaborate calculations such as+ −
+ −
\begin{lstlisting}[numbers=none]+ −
scala> for (n <- (1 to 5).toList) {+ −
val square_n = n * n+ −
println(s"$n * $n = $square_n") + −
}+ −
1 * 1 = 1+ −
2 * 2 = 4+ −
3 * 3 = 9+ −
4 * 4 = 16+ −
5 * 5 = 25+ −
\end{lstlisting}%$+ −
+ −
\noindent In this code I use a variable assignment (\code{val+ −
square_n = ...} ) and also what is called in Scala a+ −
\emph{string interpolation}, written \code{s"..."}. The latter+ −
is for printing out an equation. It allows me to refer to the+ −
integer values \code{n} and \code{square\_n} inside a string.+ −
This is very convenient for printing out ``things''. + −
+ −
The corresponding map construction for functions with + −
side-effects is in Scala called \code{foreach}. So you + −
could also write+ −
+ −
+ −
\begin{lstlisting}[numbers=none]+ −
scala> (1 to 5).toList.foreach(n => print(n))+ −
12345+ −
\end{lstlisting}+ −
+ −
+ −
\noindent or even just+ −
+ −
\begin{lstlisting}[numbers=none]+ −
scala> (1 to 5).toList.foreach(print)+ −
12345+ −
\end{lstlisting}+ −
+ −
\noindent Again I hope this reminds you a bit of your+ −
lambda-calculus lessons, where an explanation is given why+ −
both forms produce the same result.+ −
+ −
+ −
If you want to find out more about maps and functions with+ −
side-effects, you can ponder about the response Scala gives if+ −
you replace \code{foreach} by \code{map} in the expression+ −
above. Scala will still allow \code{map} with side-effect+ −
functions, but then reacts with a slightly interesting result.+ −
+ −
\subsection*{Types}+ −
+ −
In most functional programming languages, types play an+ −
important role. Scala is such a language. You have already+ −
seen built-in types, like \code{Int}, \code{Boolean},+ −
\code{String} and \code{BigInt}, but also user-defined ones,+ −
like \code{Rexp}. Unfortunately, types can be a thorny+ −
subject, especially in Scala. For example, why do we need to+ −
give the type to \code{toSet[Int]}, but not to \code{toList}?+ −
The reason is the power of Scala, which sometimes means it+ −
cannot infer all necessary typing information. At the+ −
beginning while getting familiar with Scala, I recommend a+ −
``play-it-by-ear-approach'' to types. Fully understanding+ −
type-systems, especially complicated ones like in Scala, can+ −
take a module on their own.\footnote{Still, such a study can+ −
be a rewarding training: If you are in the business of+ −
designing new programming languages, you will not be able to+ −
turn a blind eye to types. They essentially help programmers+ −
to avoid common programming errors and help with maintaining+ −
code.}+ −
+ −
In Scala, types are needed whenever you define an inductive+ −
datatype and also whenever you define functions (their+ −
arguments and their results need a type). Base types are types+ −
that do not take any (type)arguments, for example \code{Int}+ −
and \code{String}. Compound types take one or more arguments,+ −
which as seen earlier need to be given in angle-brackets, for+ −
example \code{List[Int]} or \code{Set[List[String]]} or + −
\code{Map[Int, Int]}.+ −
+ −
There are a few special type-constructors that fall outside+ −
this pattern. One is for tuples, where the type is written+ −
with parentheses. For example + −
+ −
\begin{lstlisting}[ numbers=none]+ −
(Int, Int, String)+ −
\end{lstlisting}+ −
+ −
\noindent is for a triple (a tuple with three components---two+ −
integers and a string). Tuples are helpful if you want to+ −
define functions with multiple results, say the function+ −
returning the quotient and reminder of two numbers. For this+ −
you might define:+ −
+ −
+ −
\begin{lstlisting}[ numbers=none]+ −
def quo_rem(m: Int, n: Int) : (Int, Int) = (m / n, m % n)+ −
\end{lstlisting}+ −
+ −
+ −
\noindent Since this function returns a pair of integers, its+ −
return type needs to be of type \code{(Int, Int)}.+ −
Incidentally, this is also the input type of this function.+ −
Notice this function takes \emph{two} arguments, namely+ −
\code{m} and \code{n}, both of which are integers. They are+ −
``packaged'' in a pair. Consequently the complete type of+ −
\code{quo_rem} is+ −
+ −
\begin{lstlisting}[ numbers=none]+ −
(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 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 {+ −
case 0 => "zero"+ −
case 1 => "one"+ −
case 2 => "two"+ −
case _ => "many" + −
} + −
\end{lstlisting}+ −
+ −
\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+ −
+ −
\begin{quote}+ −
\url{http://www.scala-lang.org/api/current/}+ −
\end{quote}+ −
+ −
The function arrow can also be iterated, as in + −
\code{Int => String => Boolean}. This is the type for a function+ −
taking an integer as first argument and a string as second,+ −
and the result of the function is a boolean. Though silly, a+ −
function of this type would be+ −
+ −
+ −
\begin{lstlisting}[numbers=none]+ −
def chk_string(n: Int)(s: String) : Boolean = + −
mk_string(n) == s+ −
\end{lstlisting}+ −
+ −
+ −
\noindent which checks whether the integer \code{n}+ −
corresponds to the name \code{s} given by the function+ −
\code{mk\_string}. Notice the unusual way of specifying the+ −
arguments of this function: the arguments are given one after+ −
the other, instead of being in a pair (what would be the type+ −
of this function then?). This way of specifying the arguments+ −
can be useful, for example in situations like this+ −
+ −
\begin{lstlisting}[numbers=none]+ −
scala> List("one", "two", "three", "many").map(chk_string(2))+ −
res4 = List(false, true, false, false)+ −
+ −
scala> List("one", "two", "three", "many").map(chk_string(3))+ −
res5 = List(false, false, false, true)+ −
\end{lstlisting}+ −
+ −
\noindent In each case we can give to \code{map} a specialised+ −
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 some of them.+ −
+ −
Coming back to the type \code{Int => String => Boolean}. The+ −
rule about such function types is that the right-most type+ −
specifies what the function returns (a boolean in this case).+ −
The types before that specify how many arguments the function+ −
expects and what their type is (in this case two arguments,+ −
one of type \code{Int} and another of type \code{String}).+ −
Given this rule, what kind of function has type+ −
\mbox{\code{(Int => String) => Boolean}}? Well, it returns a+ −
boolean. More interestingly, though, it only takes a single+ −
argument (because of the parentheses). The single argument+ −
happens to be another function (taking an integer as input and+ −
returning a string). Remember that \code{mk_string} is just + −
such a function. So how can we use it? For this define+ −
the somewhat silly function \code{apply_3}:+ −
+ −
\begin{lstlisting}[numbers=none]+ −
def apply_3(f: Int => String): Bool = f(3) == "many"+ −
+ −
scala> apply_3(mk_string)+ −
res6 = true+ −
\end{lstlisting}+ −
+ −
You might ask: Apart from silly functions like above, what is+ −
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}+ −
with either of them and thus changing how, for example, five+ −
numbers are printed.+ −
+ −
+ −
\begin{lstlisting}[numbers=none]+ −
scala> (1 to 5).toList.foreach(print)+ −
12345+ −
scala> (1 to 5).toList.foreach(println)+ −
1+ −
2+ −
3+ −
4+ −
5+ −
\end{lstlisting}+ −
+ −
+ −
\noindent This is actually one of the main design principles+ −
in functional programming. You have generic functions like+ −
\code{map} and \code{foreach} that can traverse data containers,+ −
like lists or sets. They then take a function to specify what+ −
should be done with each element during the traversal. This+ −
requires that the generic traversal functions can cope with+ −
any kind of function (not just functions that, for example,+ −
take as input an integer and produce a string like above).+ −
This means we cannot fix the type of the generic traversal+ −
functions, but have to keep them+ −
\emph{polymorphic}.\footnote{Another interestic topic about+ −
types, but we omit it here for the sake of brevity.} + −
+ −
There is one more type constructor that is rather special. It+ −
is called \code{Unit}. Recall that \code{Boolean} has two+ −
values, namely \code{true} and \code{false}. This can be used,+ −
for example, to test something and decide whether the test+ −
succeeds or not. In contrast the type \code{Unit} has only a+ −
single value, written \code{()}. This seems like a completely+ −
useless type and return value for a function, but is actually+ −
quite useful. It indicates when the function does not return+ −
any result. The purpose of these functions is to cause+ −
something being written on the screen or written into a file,+ −
for example. This is what is called they cause some effect on + −
the side, namely a new content displayed on the screen or some+ −
new data in a file. Scala uses the \code{Unit} type to indicate+ −
that a function does not have a result, but potentially causes+ −
some side-effect. Typical examples are the printing functions, + −
like \code{print}.+ −
+ −
+ −
% \subsection*{Cool Stuff}+ −
+ −
% The first wow-moment I had with Scala was when I came across+ −
% the following code-snippet for reading a web-page. + −
+ −
+ −
% \begin{lstlisting}[ numbers=none]+ −
% import io.Source+ −
% val url = """http://www.inf.kcl.ac.uk/staff/urbanc/"""+ −
% Source.fromURL(url)("ISO-8859-1").take(10000).mkString+ −
% \end{lstlisting}+ −
+ −
+ −
% \noindent These three lines return a string containing the+ −
% HTML-code of my webpage. It actually already does something+ −
% more sophisticated, namely only returns the first 10000+ −
% characters of a webpage in case it is too large. Why is that+ −
% code-snippet of any interest? Well, try implementing+ −
% reading-from-a-webpage in Java. I also like the possibility of+ −
% triple-quoting strings, which I have only seen in Scala so+ −
% far. The idea behind this is that in such a string all+ −
% characters are interpreted literally---there are no escaped+ −
% characters, like \verb|\n| for newlines.+ −
+ −
% My second wow-moment I had with a feature of Scala that other+ −
% functional programming languages do not have. This feature is+ −
% about implicit type conversions. If you have regular+ −
% expressions and want to use them for language processing you+ −
% often want to recognise keywords in a language, for example+ −
% \code{for},{} \code{if},{} \code{yield} and so on. But the+ −
% basic regular expression \code{CHAR} can only recognise a+ −
% single character. In order to recognise a whole string, like+ −
% \code{for}, you have to put many of those together using+ −
% \code{SEQ}:+ −
+ −
+ −
% \begin{lstlisting}[numbers=none]+ −
% SEQ(CHAR('f'), SEQ(CHAR('o'), CHAR('r')))+ −
% \end{lstlisting}+ −
+ −
% \noindent This gets quickly unreadable when the strings and+ −
% regular expressions get more complicated. In other functional+ −
% 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.+ −
+ −
% In Scala you can do better by ``hiding'' the conversion+ −
% functions. The keyword for doing this is \code{implicit} and+ −
% it needs a built-in library called + −
+ −
% \begin{lstlisting}[numbers=none]+ −
% scala.language.implicitConversions+ −
% \end{lstlisting}+ −
+ −
% \noindent+ −
% Consider the code+ −
+ −
+ −
% \begin{lstlisting}[language=Scala]+ −
% import scala.language.implicitConversions+ −
+ −
% def charlist2rexp(s: List[Char]) : Rexp = s match {+ −
% case Nil => EMPTY+ −
% case c::Nil => CHAR(c)+ −
% case c::s => SEQ(CHAR(c), charlist2rexp(s))+ −
% }+ −
+ −
% implicit def string2rexp(s: String) : Rexp = + −
% charlist2rexp(s.toList)+ −
% \end{lstlisting}+ −
+ −
+ −
% \noindent where the first seven lines implement a function+ −
% that given a list of characters generates the corresponding+ −
% regular expression. In Lines 9 and 10, this function is used+ −
% for transforming a string into a regular expression. Since the+ −
% \code{string2rexp}-function is declared as \code{implicit},+ −
% the effect will be that whenever Scala expects a regular+ −
% expression, but I only give it a string, it will automatically+ −
% insert a call to the \code{string2rexp}-function. I can now+ −
% write for example+ −
+ −
% \begin{lstlisting}[numbers=none]+ −
% scala> ALT("ab", "ac")+ −
% res9 = ALT(SEQ(CHAR(a),CHAR(b)),SEQ(CHAR(a),CHAR(c)))+ −
% \end{lstlisting}+ −
+ −
% \noindent Recall that \code{ALT} expects two regular+ −
% expressions as arguments, but I only supply two strings. The+ −
% implicit conversion function will transform the string into a+ −
% regular expression.+ −
+ −
% Using implicit definitions, Scala allows me to introduce+ −
% some further syntactic sugar for regular expressions:+ −
+ −
+ −
% \begin{lstlisting}[ numbers=none]+ −
% implicit def RexpOps(r: Rexp) = new {+ −
% def | (s: Rexp) = ALT(r, s)+ −
% def ~ (s: Rexp) = SEQ(r, s)+ −
% def % = STAR(r)+ −
% }+ −
+ −
% implicit def stringOps(s: String) = new {+ −
% def | (r: Rexp) = ALT(s, r)+ −
% def | (r: String) = ALT(s, r)+ −
% def ~ (r: Rexp) = SEQ(s, r)+ −
% def ~ (r: String) = SEQ(s, r)+ −
% def % = STAR(s)+ −
% }+ −
% \end{lstlisting}+ −
+ −
+ −
% \noindent This might seem a bit overly complicated, but its effect is+ −
% that I can now write regular expressions such as $ab + ac$ + −
% simply as+ −
+ −
+ −
% \begin{lstlisting}[numbers=none]+ −
% scala> "ab" | "ac"+ −
% res10 = ALT(SEQ(CHAR(a),CHAR(b)),SEQ(CHAR(a),CHAR(c)))+ −
% \end{lstlisting}+ −
+ −
+ −
% \noindent I leave you to figure out what the other+ −
% syntactic sugar in the code above stands for.+ −
+ −
% One more useful feature of Scala is the ability to define+ −
% functions with varying argument lists. This is a feature that+ −
% is already present in old languages, like C, but seems to have+ −
% been forgotten in the meantime---Java does not have it. In the+ −
% context of regular expressions this feature comes in handy:+ −
% Say you are fed up with writing many alternatives as+ −
+ −
+ −
% \begin{lstlisting}[numbers=none]+ −
% ALT(..., ALT(..., ALT(..., ...)))+ −
% \end{lstlisting}+ −
+ −
+ −
% \noindent To make it difficult, you do not know how deep such+ −
% alternatives are nested. So you need something flexible that+ −
% can take as many alternatives as needed. In Scala one can+ −
% achieve this by adding a \code{*} to the type of an argument.+ −
% Consider the code+ −
+ −
+ −
% \begin{lstlisting}[language=Scala]+ −
% def Alts(rs: List[Rexp]) : Rexp = rs match {+ −
% case Nil => NULL+ −
% case r::Nil => r+ −
% case r::rs => ALT(r, Alts(rs))+ −
% }+ −
+ −
% def ALTS(rs: Rexp*) = Alts(rs.toList)+ −
% \end{lstlisting}+ −
+ −
+ −
% \noindent The function in Lines 1 to 5 takes a list of regular+ −
% expressions and converts it into an appropriate alternative+ −
% regular expression. In Line 7 there is a wrapper for this+ −
% function which uses the feature of varying argument lists. The+ −
% effect of this code is that I can write the regular+ −
% expression for keywords as+ −
+ −
+ −
% \begin{lstlisting}[numbers=none]+ −
% ALTS("for", "def", "yield", "implicit", "if", "match", "case")+ −
% \end{lstlisting}+ −
+ −
+ −
% \noindent Again I leave it to you to find out how much this+ −
% simplifies the regular expression in comparison with if I had+ −
% to write this by hand using only the ``plain'' regular+ −
% expressions from the inductive datatype.+ −
+ −
\bigskip\noindent+ −
\textit{More TBD.}+ −
+ −
\subsection*{More Info}+ −
+ −
There is much more to Scala than I can possibly describe in+ −
this document. Fortunately there are a number of free books+ −
about Scala and of course lots of help online. For example+ −
+ −
\begin{itemize}+ −
\item \url{http://www.scala-lang.org/docu/files/ScalaByExample.pdf}+ −
\item \url{http://www.scala-lang.org/docu/files/ScalaTutorial.pdf}+ −
\item \url{https://www.youtube.com/user/ShadowofCatron}+ −
\item \url{http://docs.scala-lang.org/tutorials}+ −
\item \url{https://www.scala-exercises.org}+ −
\end{itemize}+ −
+ −
\noindent There is also a course at Coursera on Functional+ −
Programming Principles in Scala by Martin Odersky, the main+ −
developer of the Scala language. And a document that explains+ −
Scala for Java programmers+ −
+ −
\begin{itemize}+ −
\item \small\url{http://docs.scala-lang.org/tutorials/scala-for-java-programmers.html}+ −
\end{itemize}+ −
+ −
While I am quite enthusiastic about Scala, I am also happy to+ −
admit that it has more than its fair share of faults. The+ −
problem seen earlier of having to give an explicit type to+ −
\code{toSet}, but not \code{toList} is one of them. There are+ −
also many ``deep'' ideas about types in Scala, which even to+ −
me as seasoned functional programmer are puzzling. Whilst+ −
implicits are great, they can also be a source of great+ −
headaches, for example consider the code:+ −
+ −
\begin{lstlisting}[numbers=none]+ −
scala> List (1, 2, 3) contains "your mom"+ −
res1: Boolean = false+ −
\end{lstlisting}+ −
+ −
\noindent Rather than returning \code{false}, this code should+ −
throw a typing-error. There are also many limitations Scala+ −
inherited from the JVM that can be really annoying. For+ −
example a fixed stack size. One can work around this+ −
particular limitation, but why does one have to?+ −
More such `puzzles' can be found at+ −
+ −
\begin{center}+ −
\url{http://scalapuzzlers.com} and+ −
\url{http://latkin.org/blog/2017/05/02/when-the-scala-compiler-doesnt-help/}+ −
\end{center}+ −
+ −
Even if Scala has been a success in several high-profile+ −
companies, there is also a company (Yammer) that first used+ −
Scala in their production code, but then moved away from it.+ −
Allegedly they did not like the steep learning curve of Scala+ −
and also that new versions of Scala often introduced+ −
incompatibilities in old code. In the past two months+ −
there have also been two forks of the Scala compiler.+ −
It needs to be seen what the future brings for Scala.+ −
+ −
%So all in all, Scala might not be a great teaching language,+ −
%but I hope this is mitigated by the fact that I never require+ −
%you to write any Scala code. You only need to be able to read+ −
%it. In the coursework you can use any programming language you+ −
%like. If you want to use Scala for this, then be my guest; if+ −
%you do not want, stick with the language you are most familiar+ −
%with.+ −
+ −
+ −
+ −
\end{document}+ −
+ −
%%% Local Variables: + −
%%% mode: latex+ −
%%% TeX-master: t+ −
%%% End: + −