197
|
1 |
% !TEX program = xelatex
|
123
|
2 |
\documentclass{article}
|
|
3 |
\usepackage{../style}
|
|
4 |
\usepackage{../langs}
|
|
5 |
\usepackage{marvosym}
|
184
|
6 |
\usepackage{boxedminipage}
|
123
|
7 |
|
|
8 |
%cheat sheet
|
|
9 |
%http://worldline.github.io/scala-cheatsheet/
|
|
10 |
|
181
|
11 |
% case class, apply, unapply
|
170
|
12 |
% see https://medium.com/@thejasbabu/scala-pattern-matching-9c9e73ba9a8a
|
|
13 |
|
191
|
14 |
% the art of programming
|
|
15 |
% https://www.youtube.com/watch?v=QdVFvsCWXrA
|
|
16 |
|
|
17 |
% functional programming in Scala
|
|
18 |
%https://www.amazon.com/gp/product/1449311032/ref=as_li_ss_tl?ie=UTF8&tag=aleottshompag-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=1449311032
|
|
19 |
|
197
|
20 |
% functional programming in C
|
191
|
21 |
%https://www.amazon.com/gp/product/0201419505/ref=as_li_ss_tl?ie=UTF8&camp=1789&creative=390957&creativeASIN=0201419505&linkCode=as2&tag=aleottshompag-20
|
|
22 |
|
|
23 |
%speeding through haskell
|
|
24 |
%https://openlibra.com/en/book/download/speeding-through-haskell
|
|
25 |
|
|
26 |
% fp books --- ocaml
|
|
27 |
% http://courses.cms.caltech.edu/cs134/cs134b/book.pdf
|
|
28 |
% http://alexott.net/en/fp/books/
|
|
29 |
|
123
|
30 |
\begin{document}
|
180
|
31 |
\fnote{\copyright{} Christian Urban, King's College London, 2017, 2018}
|
123
|
32 |
|
125
|
33 |
\section*{A Crash-Course in Scala}
|
123
|
34 |
|
182
|
35 |
\mbox{}\hfill\textit{``Scala --- \underline{S}lowly \underline{c}ompiled
|
|
36 |
\underline{a}cademic \underline{la}nguage''}\smallskip\\
|
192
|
37 |
\mbox{}\hfill\textit{ --- a joke(?) found on Twitter}\bigskip
|
195
|
38 |
|
|
39 |
|
|
40 |
\subsection*{Introduction}
|
|
41 |
|
178
|
42 |
\noindent
|
170
|
43 |
Scala is a programming language that combines functional and
|
|
44 |
object-oriented programming-styles. It has received quite a bit of
|
181
|
45 |
attention in the last five or so years. One reason for this attention is
|
|
46 |
that, like the Java programming language, Scala compiles to the Java
|
|
47 |
Virtual Machine (JVM) and therefore Scala programs can run under MacOSX,
|
195
|
48 |
Linux and Windows. Because of this it has also access to
|
181
|
49 |
the myriads of Java libraries. Unlike Java, however, Scala often allows
|
186
|
50 |
programmers to write very concise and elegant code. Some therefore say
|
182
|
51 |
``Scala is the better Java''.\footnote{from
|
188
|
52 |
\url{https://www.slideshare.net/maximnovak/joy-of-scala}}
|
|
53 |
|
191
|
54 |
A number of companies---the Guardian, Twitter, Coursera, FourSquare,
|
|
55 |
Netflix, LinkedIn, ITV to name a few---either use Scala exclusively in
|
188
|
56 |
production code, or at least to some substantial degree. Scala seems
|
|
57 |
also useful in job-interviews (especially in data science) according to
|
|
58 |
this anecdotal report
|
170
|
59 |
|
181
|
60 |
\begin{quote}
|
|
61 |
\url{http://techcrunch.com/2016/06/14/scala-is-the-new-golden-child}
|
170
|
62 |
\end{quote}
|
|
63 |
|
|
64 |
\noindent
|
|
65 |
The official Scala compiler can be downloaded from
|
|
66 |
|
|
67 |
\begin{quote}
|
195
|
68 |
\url{http://www.scala-lang.org}\medskip
|
|
69 |
\end{quote}
|
170
|
70 |
|
|
71 |
\noindent
|
195
|
72 |
If you are interested there are also experimental backends of Scala
|
|
73 |
for producing code under Android (\url{http://scala-android.org}); for
|
|
74 |
generating JavaScript code (\url{https://www.scala-js.org}); and there
|
|
75 |
is work under way to have a native Scala compiler generating X86-code
|
|
76 |
(\url{http://www.scala-native.org}). Though be warned these backends
|
|
77 |
are still rather beta or even alpha.
|
|
78 |
|
|
79 |
\subsection*{VS Code and Scala}
|
|
80 |
|
184
|
81 |
I found a convenient IDE for writing Scala programs is Microsoft's
|
181
|
82 |
\textit{Visual Studio Code} (VS Code) which runs under MacOSX, Linux and
|
197
|
83 |
obviously Windows.\footnote{unlike \emph{Microsoft Visual Studio}---note
|
191
|
84 |
the minuscule difference in the name---which is a heavy-duty,
|
|
85 |
Windows-only IDE\ldots{}jeez, with all their money could they not come
|
|
86 |
up with a completely different name for a complete different project?
|
|
87 |
For the pedantic, Microsoft Visual Studio is an IDE, whereas Visual
|
197
|
88 |
Studio Code is considered as a source code editor. Anybody knows the what the
|
191
|
89 |
difference is?} It can be downloaded for free from
|
181
|
90 |
|
|
91 |
\begin{quote}
|
|
92 |
\url{https://code.visualstudio.com}
|
|
93 |
\end{quote}
|
|
94 |
|
|
95 |
\noindent
|
|
96 |
and should already come pre-installed in the Department (together with
|
195
|
97 |
the Scala compiler). Being a project that just started in 2015, VS Code is
|
189
|
98 |
relatively new and thus far from perfect. However it includes a
|
182
|
99 |
\textit{Marketplace} from which a multitude of extensions can be
|
184
|
100 |
downloaded that make editing and running Scala code a little easier (see
|
|
101 |
Figure~\ref{vscode} for my setup).
|
181
|
102 |
|
|
103 |
\begin{figure}[t]
|
184
|
104 |
\begin{boxedminipage}{\textwidth}
|
181
|
105 |
\begin{center}
|
|
106 |
\includegraphics[scale=0.15]{../pics/vscode.png}\\[-10mm]\mbox{}
|
|
107 |
\end{center}
|
195
|
108 |
\caption{My installation of VS Code includes the following
|
|
109 |
packages from Marketplace: \textbf{Scala Syntax (official)} 0.2.0,
|
|
110 |
\textbf{Code Runner} 0.9.5, \textbf{Code Spell Checker} 1.6.10,
|
|
111 |
\textbf{Rewrap} 1.9.1 and \textbf{Subtle Match
|
|
112 |
Brackets} 3.0.0. I have also bound the keys \keys{Ctrl} \keys{Ret} to the
|
|
113 |
action ``Run-Selected-Text-In-Active-Terminal'' in order to quickly
|
|
114 |
evaluate small code snippets in the Scala REPL.\label{vscode}}
|
184
|
115 |
\end{boxedminipage}
|
181
|
116 |
\end{figure}
|
|
117 |
|
184
|
118 |
What I like most about VS Code is that it provides easy access to the
|
186
|
119 |
Scala REPL. But if you prefer another editor for coding, it is also
|
|
120 |
painless to work with Scala completely on the command line (as you might
|
|
121 |
have done with \texttt{g++} in the earlier part of PEP). For the
|
195
|
122 |
lazybones among us, there are even online editors and environments for
|
197
|
123 |
developing and running Scala programs: \textit{ScalaFiddle}
|
|
124 |
and \textit{Scastie} are two of them. They require zero setup
|
|
125 |
(assuming you have a browser handy). You can access them at
|
181
|
126 |
|
|
127 |
\begin{quote}
|
195
|
128 |
\url{https://scalafiddle.io}\\
|
|
129 |
\url{https://scastie.scala-lang.org}\medskip
|
181
|
130 |
\end{quote}
|
|
131 |
|
195
|
132 |
\noindent
|
197
|
133 |
But you should be careful if you use them for your coursework: they
|
|
134 |
are meant to play around, not really for serious work.
|
|
135 |
|
183
|
136 |
Scala can be used with the heavy-duty IDEs Eclipse and IntelliJ.
|
182
|
137 |
A ready-made Scala bundle for Eclipse is available from
|
170
|
138 |
|
|
139 |
\begin{quote}
|
|
140 |
\url{http://scala-ide.org/download/sdk.html}
|
|
141 |
\end{quote}
|
|
142 |
|
|
143 |
\noindent
|
191
|
144 |
Also IntelliJ includes plugins for Scala. \underline{\textbf{BUT}},
|
|
145 |
I do \textbf{not} recommend the usage of either Eclipse or IntelliJ for PEP: these IDEs
|
182
|
146 |
seem to make your life harder, rather than easier, for the small
|
|
147 |
programs we will write in this module. They are really meant to be used
|
|
148 |
when you have a million-lines codebase, rather than our
|
|
149 |
``toy-programs''\ldots{}for example why on earth am I required to create a
|
|
150 |
completely new project with several subdirectories when I just want to
|
186
|
151 |
try out 20-lines of Scala code? Your mileage may vary though. ;o)
|
182
|
152 |
|
|
153 |
\subsection*{Why Functional Programming?}
|
|
154 |
|
186
|
155 |
Before we go on, let me explain a bit more why we want to inflict upon
|
|
156 |
you another programming language. You hopefully have mastered Java and
|
182
|
157 |
C++\ldots{}the world should be your oyster, no? Well, it is not that
|
186
|
158 |
easy. We do require Scala in PEP, but actually we do not religiously
|
|
159 |
care whether you learn Scala---after all it is just a programming
|
|
160 |
language (albeit a nifty one IMHO). What we do care about is that you
|
|
161 |
learn about \textit{functional programming}. Scala is just the vehicle
|
188
|
162 |
for that. Still, you need to learn Scala well enough to get good marks
|
186
|
163 |
in PEP, but functional programming could equally be taught with Haskell,
|
188
|
164 |
F\#, SML, Ocaml, Kotlin, Clojure, Scheme, Elm and many other functional
|
186
|
165 |
programming languages. %Your friendly lecturer just happens to like Scala
|
|
166 |
%and the Department agreed that it is a good idea to inflict Scala upon
|
|
167 |
%you.
|
182
|
168 |
|
|
169 |
Very likely writing programs in a functional programming language is
|
183
|
170 |
quite different from what you are used to in your study so far. It
|
|
171 |
might even be totally alien to you. The reason is that functional
|
|
172 |
programming seems to go against the core principles of
|
|
173 |
\textit{imperative programming} (which is what you do in Java and C++
|
|
174 |
for example). The main idea of imperative programming is that you have
|
191
|
175 |
some form of \emph{state} in your program and you continuously change this
|
|
176 |
state by issuing some commands---for example for updating a field in an
|
197
|
177 |
array or for adding one to a variable and so on. The classic
|
|
178 |
example for this style of programming are \texttt{for}-loops in C:
|
182
|
179 |
|
|
180 |
\begin{lstlisting}[language=C,numbers=none]
|
184
|
181 |
for (int i = 10; i < 20; i++) {
|
186
|
182 |
//...Do something interesting with i...
|
184
|
183 |
}
|
182
|
184 |
\end{lstlisting}
|
|
185 |
|
184
|
186 |
\noindent Here the integer variable \texttt{i} embodies the state, which
|
|
187 |
is first set to \texttt{10} and then increased by one in each
|
|
188 |
loop-iteration until it reaches \texttt{20} at which point the loop
|
|
189 |
exits. When this code is compiled and actually runs, there will be some
|
186
|
190 |
dedicated space reserved for \texttt{i} in memory. This space of
|
188
|
191 |
typically 32 bits contains \texttt{i}'s current value\ldots\texttt{10}
|
191
|
192 |
at the beginning, and then the content will be overwritten with some
|
|
193 |
new content in every iteration. The main point here is that this kind of
|
|
194 |
updating, or manipulating, memory is 25.806\ldots or \textbf{THE ROOT OF
|
|
195 |
ALL EVIL}!!
|
186
|
196 |
|
|
197 |
\begin{center}
|
|
198 |
\includegraphics[scale=0.25]{../pics/root-of-all-evil.png}
|
|
199 |
\end{center}
|
|
200 |
|
182
|
201 |
|
|
202 |
\noindent
|
|
203 |
\ldots{}Well, it is perfectly benign if you have a sequential program
|
|
204 |
that gets run instruction by instruction...nicely one after another.
|
|
205 |
This kind of running code uses a single core of your CPU and goes as
|
184
|
206 |
fast as your CPU frequency, also called clock-speed, allows. The problem
|
|
207 |
is that this clock-speed has not much increased over the past decade and
|
|
208 |
no dramatic increases are predicted for any time soon. So you are a bit
|
|
209 |
stuck, unlike previous generations of developers who could rely upon the
|
|
210 |
fact that every 2 years or so their code would run twice as fast (in
|
|
211 |
ideal circumstances) because the clock-speed of their CPUs got twice as
|
|
212 |
fast. This unfortunately does not happen any more nowadays. To get you
|
|
213 |
out of this dreadful situation, CPU producers pile more and more
|
|
214 |
cores into CPUs in order to make them more powerful and potentially make
|
|
215 |
software faster. The task for you as developer is to take somehow
|
|
216 |
advantage of these cores by running as much of your code as possible in
|
186
|
217 |
parallel on as many cores you have available (typically 4 in modern
|
184
|
218 |
laptops and sometimes much more on high-end machines). In this
|
|
219 |
situation, \textit{mutable} variables like \texttt{i} above are evil, or
|
|
220 |
at least a major nuisance: Because if you want to distribute some of the
|
183
|
221 |
loop-iterations over the cores that are currently idle in your system,
|
186
|
222 |
you need to be extremely careful about who can read and overwrite
|
|
223 |
the variable \texttt{i}.\footnote{If you are of the mistaken belief that nothing
|
183
|
224 |
nasty can happen to \texttt{i} inside the \texttt{for}-loop, then you
|
|
225 |
need to go back over the C++ material.} Especially the writing operation
|
|
226 |
is critical because you do not want that conflicting writes mess about
|
184
|
227 |
with \texttt{i}. Take my word: an untold amount of misery has arisen
|
|
228 |
from this problem. The catch is that if you try to solve this problem in
|
|
229 |
C++ or Java, and be as defensive as possible about reads and writes to
|
|
230 |
\texttt{i}, then you need to synchronise access to it. The result is that
|
183
|
231 |
your program more often than not waits more than it runs, thereby
|
|
232 |
defeating the point of trying to run the program in parallel in the
|
|
233 |
first place. If you are less defensive, then usually all hell breaks
|
|
234 |
loose by seemingly obtaining random results. And forget the idea of
|
|
235 |
being able to debug such code.
|
182
|
236 |
|
184
|
237 |
The central idea of functional programming is to eliminate any state
|
195
|
238 |
from programs---or at least from the ``interesting bits'' of the
|
|
239 |
programs. Because then it is easy to parallelise the resulting
|
|
240 |
programs: if you do not have any state, then once created, all memory
|
|
241 |
content stays unchanged and reads to such memory are absolutely safe
|
|
242 |
without the need of any synchronisation. An example is given in
|
|
243 |
Figure~\ref{mand} where in the absence of the annoying state, Scala
|
|
244 |
makes it very easy to calculate the Mandelbrot set on as many cores of
|
|
245 |
your CPU as possible. Why is it so easy in this example? Because each
|
|
246 |
pixel in the Mandelbrot set can be calculated independently and the
|
|
247 |
calculation does not need to update any variable. It is so easy in
|
|
248 |
fact that going from the sequential version of the Mandelbrot program
|
|
249 |
to the parallel version can be achieved by adding just eight
|
|
250 |
characters---in two places you have to add \texttt{.par}. Try the same
|
|
251 |
in C++ or Java!
|
182
|
252 |
|
|
253 |
\begin{figure}[p]
|
184
|
254 |
\begin{boxedminipage}{\textwidth}
|
187
|
255 |
|
191
|
256 |
A Scala program for generating pretty pictures of the Mandelbrot set.\smallskip\\
|
|
257 |
(See \url{https://en.wikipedia.org/wiki/Mandelbrot_set} or\\
|
|
258 |
\phantom{(See }\url{https://www.youtube.com/watch?v=aSg2Db3jF_4}):
|
184
|
259 |
\begin{center}
|
|
260 |
\begin{tabular}{c}
|
191
|
261 |
\includegraphics[scale=0.11]{../pics/mand1.png}\\[-8mm]\mbox{}
|
184
|
262 |
\end{tabular}
|
187
|
263 |
\end{center}
|
184
|
264 |
|
187
|
265 |
\begin{center}
|
|
266 |
\begin{tabular}{@{}p{0.45\textwidth}|p{0.45\textwidth}@{}}
|
191
|
267 |
\bf sequential version: & \bf parallel version on 4 cores:\smallskip\\
|
182
|
268 |
|
191
|
269 |
{\hfill\includegraphics[scale=0.11]{../pics/mand4.png}\hfill} &
|
|
270 |
{\hfill\includegraphics[scale=0.11]{../pics/mand3.png}\hfill} \\
|
187
|
271 |
|
|
272 |
{\footnotesize\begin{lstlisting}[xleftmargin=-1mm]
|
186
|
273 |
for (y <- (0 until H)) {
|
|
274 |
for (x <- (0 until W)) {
|
|
275 |
|
|
276 |
val c = start +
|
|
277 |
(x * d_x + y * d_y * i)
|
|
278 |
val iters = iterations(c, max)
|
191
|
279 |
val colour =
|
186
|
280 |
if (iters == max) black
|
|
281 |
else colours(iters % 16)
|
|
282 |
|
191
|
283 |
pixel(x, y, colour)
|
186
|
284 |
}
|
|
285 |
viewer.updateUI()
|
|
286 |
}
|
187
|
287 |
\end{lstlisting}}
|
|
288 |
&
|
|
289 |
{\footnotesize\begin{lstlisting}[xleftmargin=0mm]
|
188
|
290 |
for (y <- (0 until H)/*@\keys{\texttt{.par}}@*/) {
|
|
291 |
for (x <- (0 until W)/*@\keys{\texttt{.par}}@*/) {
|
187
|
292 |
|
|
293 |
val c = start +
|
|
294 |
(x * d_x + y * d_y * i)
|
|
295 |
val iters = iterations(c, max)
|
191
|
296 |
val colour =
|
187
|
297 |
if (iters == max) black
|
|
298 |
else colours(iters % 16)
|
|
299 |
|
191
|
300 |
pixel(x, y, colour)
|
187
|
301 |
}
|
|
302 |
viewer.updateUI()
|
|
303 |
}
|
191
|
304 |
\end{lstlisting}}\\[-2mm]
|
187
|
305 |
|
|
306 |
\centering\includegraphics[scale=0.5]{../pics/cpu2.png} &
|
188
|
307 |
\centering\includegraphics[scale=0.5]{../pics/cpu1.png}
|
184
|
308 |
\end{tabular}
|
|
309 |
\end{center}
|
195
|
310 |
\caption{The code of the ``main'' loops in my Mandelbrot program.
|
191
|
311 |
The parallel version differs only in \texttt{.par} being added to the
|
195
|
312 |
``ranges'' of the x and y coordinates. As can be seen from the CPU loads, in
|
|
313 |
the sequential version there is a lower peak for an extended period,
|
191
|
314 |
while in the parallel version there is a short sharp burst for
|
|
315 |
essentially the same workload\ldots{}meaning you get more work done
|
195
|
316 |
in a shorter amount of time. This easy \emph{parallelisation}
|
|
317 |
only works reliably with an immutable program.
|
188
|
318 |
\label{mand}}
|
184
|
319 |
\end{boxedminipage}
|
182
|
320 |
\end{figure}
|
|
321 |
|
188
|
322 |
But remember this easy parallelisation of code requires that we
|
|
323 |
have no state in our programs\ldots{}that is no counters like
|
186
|
324 |
\texttt{i} in \texttt{for}-loops. You might then ask, how do I write
|
|
325 |
loops without such counters? Well, teaching you that this is possible is
|
|
326 |
one of the main points of the Scala-part in PEP. I can assure you it is
|
|
327 |
possible, but you have to get your head around it. Once you have
|
|
328 |
mastered this, it will be fun to have no state in your programs (a side
|
|
329 |
product is that it much easier to debug state-less code and also more
|
188
|
330 |
often than not easier to understand). So have fun with
|
186
|
331 |
Scala!\footnote{If you are still not convinced about the function
|
|
332 |
programming ``thing'', there are a few more arguments: a lot of research
|
|
333 |
in programming languages happens to take place in functional programming
|
|
334 |
languages. This has resulted in ultra-useful features such as
|
191
|
335 |
pattern-matching, strong type-systems, laziness, implicits, algebraic
|
188
|
336 |
datatypes to name a few. Imperative languages seem to often lag behind
|
186
|
337 |
in adopting them: I know, for example, that Java will at some point in
|
191
|
338 |
the future support pattern-matching, which has been used for example
|
|
339 |
in SML for at
|
186
|
340 |
least 40(!) years. See
|
|
341 |
\url{http://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html}.
|
|
342 |
Also Rust, a C-like programming language that has been developed since
|
|
343 |
2010 and is gaining quite some interest, borrows many ideas from
|
|
344 |
functional programming from yesteryear.}
|
170
|
345 |
|
188
|
346 |
|
123
|
347 |
\subsection*{The Very Basics}
|
|
348 |
|
|
349 |
One advantage of Scala over Java is that it includes an interpreter (a
|
|
350 |
REPL, or
|
|
351 |
\underline{R}ead-\underline{E}val-\underline{P}rint-\underline{L}oop)
|
181
|
352 |
with which you can run and test small code snippets without the need
|
123
|
353 |
of a compiler. This helps a lot with interactively developing
|
188
|
354 |
programs. It is my preferred way of writing small Scala
|
123
|
355 |
programs. Once you installed Scala, you can start the interpreter by
|
|
356 |
typing on the command line:
|
|
357 |
|
|
358 |
\begin{lstlisting}[language={},numbers=none,basicstyle=\ttfamily\small]
|
|
359 |
$ scala
|
195
|
360 |
Welcome to Scala 2.12.7 (Java HotSpot(TM) 64-Bit Server VM, Java 9).
|
123
|
361 |
Type in expressions for evaluation. Or try :help.
|
|
362 |
|
|
363 |
scala>
|
|
364 |
\end{lstlisting}%$
|
|
365 |
|
|
366 |
\noindent The precise response may vary depending
|
|
367 |
on the version and platform where you installed Scala. At the Scala
|
|
368 |
prompt you can type things like \code{2 + 3}\;\keys{Ret} and
|
|
369 |
the output will be
|
|
370 |
|
|
371 |
\begin{lstlisting}[numbers=none]
|
|
372 |
scala> 2 + 3
|
|
373 |
res0: Int = 5
|
|
374 |
\end{lstlisting}
|
|
375 |
|
188
|
376 |
\noindent The answer means that he result of the addition is of type
|
124
|
377 |
\code{Int} and the actual result is 5; \code{res0} is a name that
|
125
|
378 |
Scala gives automatically to the result. You can reuse this name later
|
188
|
379 |
on, for example
|
181
|
380 |
|
|
381 |
\begin{lstlisting}[numbers=none]
|
|
382 |
scala> res0 + 4
|
|
383 |
res1: Int = 9
|
|
384 |
\end{lstlisting}
|
|
385 |
|
|
386 |
\noindent
|
|
387 |
Another classic example you can try out is
|
123
|
388 |
|
|
389 |
\begin{lstlisting}[numbers=none]
|
|
390 |
scala> print("hello world")
|
|
391 |
hello world
|
|
392 |
\end{lstlisting}
|
|
393 |
|
|
394 |
\noindent Note that in this case there is no result. The
|
|
395 |
reason is that \code{print} does not actually produce a result
|
124
|
396 |
(there is no \code{resX} and no type), rather it is a
|
123
|
397 |
function that causes the \emph{side-effect} of printing out a
|
|
398 |
string. Once you are more familiar with the functional
|
|
399 |
programming-style, you will know what the difference is
|
|
400 |
between a function that returns a result, like addition, and a
|
|
401 |
function that causes a side-effect, like \code{print}. We
|
|
402 |
shall come back to this point later, but if you are curious
|
|
403 |
now, the latter kind of functions always has \code{Unit} as
|
188
|
404 |
return type. It is just not printed by Scala.
|
123
|
405 |
|
181
|
406 |
You can try more examples with the Scala REPL, but feel free to
|
|
407 |
first guess what the result is (not all answers by Scala are obvious):
|
123
|
408 |
|
|
409 |
\begin{lstlisting}[numbers=none]
|
|
410 |
scala> 2 + 2
|
|
411 |
scala> 1 / 2
|
|
412 |
scala> 1.0 / 2
|
|
413 |
scala> 1 / 2.0
|
|
414 |
scala> 1 / 0
|
|
415 |
scala> 1.0 / 0.0
|
|
416 |
scala> true == false
|
|
417 |
scala> true && false
|
|
418 |
scala> 1 > 1.0
|
|
419 |
scala> "12345".length
|
181
|
420 |
scala> List(1,2,1).size
|
|
421 |
scala> Set(1,2,1).size
|
|
422 |
\end{lstlisting}\smallskip
|
123
|
423 |
|
181
|
424 |
\noindent
|
|
425 |
Please take the Scala REPL seriously: If you want to take advantage of my
|
|
426 |
reference implementation for the assignments, you will need to be
|
|
427 |
able to ``play around'' with it!
|
|
428 |
|
|
429 |
\subsection*{Standalone Scala Apps}
|
123
|
430 |
|
|
431 |
If you want to write a stand-alone app in Scala, you can
|
197
|
432 |
implement an object that is an instance of \code{App}. For example
|
|
433 |
write
|
123
|
434 |
|
|
435 |
\begin{lstlisting}[numbers=none]
|
|
436 |
object Hello extends App {
|
|
437 |
println("hello world")
|
|
438 |
}
|
|
439 |
\end{lstlisting}
|
|
440 |
|
197
|
441 |
\noindent save it in a file, say {\tt hello-world.scala}, and
|
188
|
442 |
then run the compiler (\texttt{scalac}) and start the runtime
|
181
|
443 |
environment (\texttt{scala}):
|
123
|
444 |
|
|
445 |
\begin{lstlisting}[language={},numbers=none,basicstyle=\ttfamily\small]
|
|
446 |
$ scalac hello-world.scala
|
|
447 |
$ scala Hello
|
|
448 |
hello world
|
|
449 |
\end{lstlisting}
|
|
450 |
|
124
|
451 |
\noindent
|
123
|
452 |
Like Java, Scala targets the JVM and consequently
|
|
453 |
Scala programs can also be executed by the bog-standard Java
|
|
454 |
Runtime. This only requires the inclusion of {\tt
|
|
455 |
scala-library.jar}, which on my computer can be done as
|
|
456 |
follows:
|
|
457 |
|
|
458 |
\begin{lstlisting}[language={},numbers=none,basicstyle=\ttfamily\small]
|
|
459 |
$ scalac hello-world.scala
|
|
460 |
$ java -cp /usr/local/src/scala/lib/scala-library.jar:. Hello
|
|
461 |
hello world
|
|
462 |
\end{lstlisting}
|
|
463 |
|
|
464 |
\noindent You might need to adapt the path to where you have
|
|
465 |
installed Scala.
|
|
466 |
|
|
467 |
\subsection*{Values}
|
|
468 |
|
124
|
469 |
In the lectures I will try to avoid as much as possible the term
|
|
470 |
\emph{variables} familiar from other programming languages. The reason
|
|
471 |
is that Scala has \emph{values}, which can be seen as abbreviations of
|
|
472 |
larger expressions. For example
|
123
|
473 |
|
|
474 |
\begin{lstlisting}[numbers=none]
|
|
475 |
scala> val x = 42
|
|
476 |
x: Int = 42
|
|
477 |
|
|
478 |
scala> val y = 3 + 4
|
|
479 |
y: Int = 7
|
|
480 |
|
|
481 |
scala> val z = x / y
|
|
482 |
z: Int = 6
|
|
483 |
\end{lstlisting}
|
|
484 |
|
|
485 |
\noindent
|
181
|
486 |
Why the kerfuffle about values? Well, values are \emph{immutable}. You
|
|
487 |
cannot change their value after you defined them. If you try to reassign
|
124
|
488 |
\code{z} above, Scala will yell at you:
|
123
|
489 |
|
|
490 |
\begin{lstlisting}[numbers=none]
|
|
491 |
scala> z = 9
|
|
492 |
error: reassignment to val
|
|
493 |
z = 9
|
|
494 |
^
|
|
495 |
\end{lstlisting}
|
|
496 |
|
|
497 |
\noindent
|
|
498 |
So it would be a bit absurd to call values as variables...you cannot
|
195
|
499 |
change them; they cannot vary. You might think you can reassign them like
|
123
|
500 |
|
|
501 |
\begin{lstlisting}[numbers=none]
|
|
502 |
scala> val x = 42
|
|
503 |
scala> val z = x / 7
|
|
504 |
scala> val x = 70
|
|
505 |
scala> println(z)
|
|
506 |
\end{lstlisting}
|
|
507 |
|
124
|
508 |
\noindent but try to guess what Scala will print out
|
123
|
509 |
for \code{z}? Will it be \code{6} or \code{10}? A final word about
|
|
510 |
values: Try to stick to the convention that names of values should be
|
188
|
511 |
lower case, like \code{x}, \code{y}, \code{foo41} and so on. Upper-case
|
|
512 |
names you should reserve for what is called \emph{constructors}.
|
123
|
513 |
|
|
514 |
|
|
515 |
\subsection*{Function Definitions}
|
|
516 |
|
181
|
517 |
We do functional programming! So defining functions will be our main occupation.
|
182
|
518 |
As an example, a function named \code{f} taking a single argument of type
|
181
|
519 |
\code{Int} can be defined in Scala as follows:
|
123
|
520 |
|
|
521 |
\begin{lstlisting}[numbers=none]
|
181
|
522 |
def f(x: Int) : String = ...EXPR...
|
123
|
523 |
\end{lstlisting}
|
|
524 |
|
|
525 |
\noindent
|
124
|
526 |
This function returns the value resulting from evaluating the expression
|
123
|
527 |
\code{EXPR} (whatever is substituted for this). The result will be
|
197
|
528 |
of type \code{String}. It is a good habit to always include this information
|
|
529 |
about the return type. Simple examples of Scala functions are:
|
123
|
530 |
|
|
531 |
\begin{lstlisting}[numbers=none]
|
|
532 |
def incr(x: Int) : Int = x + 1
|
|
533 |
def double(x: Int) : Int = x + x
|
|
534 |
def square(x: Int) : Int = x * x
|
|
535 |
\end{lstlisting}
|
|
536 |
|
|
537 |
\noindent
|
|
538 |
The general scheme for a function is
|
|
539 |
|
|
540 |
\begin{lstlisting}[numbers=none]
|
|
541 |
def fname(arg1: ty1, arg2: ty2,..., argn: tyn): rty = {
|
|
542 |
BODY
|
|
543 |
}
|
|
544 |
\end{lstlisting}
|
|
545 |
|
|
546 |
\noindent
|
197
|
547 |
where each argument, \texttt{arg1}, \texttt{arg2} and so on, requires
|
|
548 |
its type and the result type of the
|
|
549 |
function, \code{rty}, should also be given. If the body of the function is
|
124
|
550 |
more complex, then it can be enclosed in braces, like above. If it it
|
|
551 |
is just a simple expression, like \code{x + 1}, you can omit the
|
195
|
552 |
braces. Very often functions are recursive (that is call themselves),
|
|
553 |
like the venerable factorial function:
|
123
|
554 |
|
|
555 |
\begin{lstlisting}[numbers=none]
|
|
556 |
def fact(n: Int): Int =
|
|
557 |
if (n == 0) 1 else n * fact(n - 1)
|
|
558 |
\end{lstlisting}
|
188
|
559 |
|
|
560 |
\noindent
|
|
561 |
Note that Scala does not have a \code{then}-keyword in an \code{if}-statement.
|
123
|
562 |
|
|
563 |
\subsection*{Loops, or better the Absence thereof}
|
|
564 |
|
|
565 |
Coming from Java or C++, you might be surprised that Scala does
|
|
566 |
not really have loops. It has instead, what is in functional
|
|
567 |
programming called, \emph{maps}. To illustrate how they work,
|
|
568 |
let us assume you have a list of numbers from 1 to 8 and want to
|
|
569 |
build the list of squares. The list of numbers from 1 to 8
|
|
570 |
can be constructed in Scala as follows:
|
|
571 |
|
|
572 |
\begin{lstlisting}[numbers=none]
|
|
573 |
scala> (1 to 8).toList
|
|
574 |
res1: List[Int] = List(1, 2, 3, 4, 5, 6, 7, 8)
|
|
575 |
\end{lstlisting}
|
|
576 |
|
197
|
577 |
\noindent Generating from this list the list of corresponding
|
|
578 |
squares in a programming language such as Java, you would assume
|
|
579 |
the list is given as a kind of array. You would then iterate, or loop,
|
123
|
580 |
an index over this array and replace each entry in the array
|
|
581 |
by the square. Right? In Scala, and in other functional
|
|
582 |
programming languages, you use maps to achieve the same.
|
|
583 |
|
|
584 |
A map essentially takes a function that describes how each
|
|
585 |
element is transformed (for example squared) and a list over
|
|
586 |
which this function should work. There are two forms to
|
|
587 |
express such maps in Scala. The first way is called a
|
|
588 |
\emph{for-comprehension}. Squaring the numbers from 1 to 8
|
|
589 |
would look as follows:
|
|
590 |
|
|
591 |
\begin{lstlisting}[numbers=none]
|
|
592 |
scala> for (n <- (1 to 8).toList) yield n * n
|
|
593 |
res2: List[Int] = List(1, 4, 9, 16, 25, 36, 49, 64)
|
|
594 |
\end{lstlisting}
|
|
595 |
|
|
596 |
\noindent The important keywords are \code{for} and
|
|
597 |
\code{yield}. This for-comprehension roughly states that from
|
197
|
598 |
the list of numbers we draw elements that are given the name
|
|
599 |
\code{n} and compute the result
|
|
600 |
of \code{n * n}. This is a simple example---what comes after
|
|
601 |
\code{yield} can be a complex expression enclosed in \texttt{\{...\}}.
|
|
602 |
As you can see, we specified the list where
|
123
|
603 |
each \code{n} comes from, namely \code{(1 to 8).toList}, and
|
|
604 |
how each element needs to be transformed. This can also be
|
|
605 |
expressed in a second way in Scala by using directly
|
|
606 |
\code{map}s as follows:
|
|
607 |
|
|
608 |
\begin{lstlisting}[numbers=none]
|
|
609 |
scala> (1 to 8).toList.map(n => n * n)
|
|
610 |
res3 = List(1, 4, 9, 16, 25, 36, 49, 64)
|
|
611 |
\end{lstlisting}
|
|
612 |
|
|
613 |
\noindent In this way, the expression \code{n => n * n} stands
|
|
614 |
for the function that calculates the square (this is how the
|
|
615 |
\code{n}s are transformed). This expression for functions
|
|
616 |
might remind you of your lessons about the lambda-calculus
|
|
617 |
where this would have been written as $\lambda n.\,n * n$. It
|
|
618 |
might not be obvious, but for-comprehensions are just
|
|
619 |
syntactic sugar: when compiling, Scala translates
|
|
620 |
for-comprehensions into equivalent maps. This even works
|
|
621 |
when for-comprehensions get more complicated (see below).
|
|
622 |
|
|
623 |
The very charming feature of Scala is that such maps or
|
|
624 |
for-comprehensions can be written for any kind of data
|
|
625 |
collection, such as lists, sets, vectors, options and so on.
|
|
626 |
For example if we instead compute the reminders modulo 3 of
|
|
627 |
this list, we can write
|
|
628 |
|
|
629 |
\begin{lstlisting}[numbers=none]
|
|
630 |
scala> (1 to 8).toList.map(n => n % 3)
|
|
631 |
res4 = List(1, 2, 0, 1, 2, 0, 1, 2)
|
|
632 |
\end{lstlisting}
|
|
633 |
|
|
634 |
\noindent If we, however, transform the numbers 1 to 8 not
|
|
635 |
into a list, but into a set, and then compute the reminders
|
|
636 |
modulo 3 we obtain
|
|
637 |
|
|
638 |
\begin{lstlisting}[numbers=none]
|
|
639 |
scala> (1 to 8).toSet[Int].map(n => n % 3)
|
|
640 |
res5 = Set(2, 1, 0)
|
|
641 |
\end{lstlisting}
|
|
642 |
|
|
643 |
\noindent This is the correct result for sets, as there are
|
|
644 |
only three equivalence classes of integers modulo 3. Note that
|
|
645 |
in this example we need to ``help'' Scala to transform the
|
|
646 |
numbers into a set of integers by explicitly annotating the
|
|
647 |
type \code{Int}. Since maps and for-comprehensions are
|
|
648 |
just syntactic variants of each other, the latter can also be
|
|
649 |
written as
|
|
650 |
|
|
651 |
\begin{lstlisting}[numbers=none]
|
|
652 |
scala> for (n <- (1 to 8).toSet[Int]) yield n % 3
|
|
653 |
res5 = Set(2, 1, 0)
|
|
654 |
\end{lstlisting}
|
|
655 |
|
|
656 |
For-comprehensions can also be nested and the selection of
|
|
657 |
elements can be guarded. For example if we want to pair up
|
|
658 |
the numbers 1 to 4 with the letters a to c, we can write
|
|
659 |
|
|
660 |
\begin{lstlisting}[numbers=none]
|
|
661 |
scala> for (n <- (1 to 4).toList;
|
|
662 |
m <- ('a' to 'c').toList) yield (n, m)
|
|
663 |
res6 = List((1,a), (1,b), (1,c), (2,a), (2,b), (2,c),
|
|
664 |
(3,a), (3,b), (3,c), (4,a), (4,b), (4,c))
|
|
665 |
\end{lstlisting}
|
|
666 |
|
|
667 |
\noindent
|
|
668 |
Or if we want to find all pairs of numbers between 1 and 3
|
|
669 |
where the sum is an even number, we can write
|
|
670 |
|
|
671 |
\begin{lstlisting}[numbers=none]
|
|
672 |
scala> for (n <- (1 to 3).toList;
|
|
673 |
m <- (1 to 3).toList;
|
|
674 |
if (n + m) % 2 == 0) yield (n, m)
|
|
675 |
res7 = List((1,1), (1,3), (2,2), (3,1), (3,3))
|
|
676 |
\end{lstlisting}
|
|
677 |
|
|
678 |
\noindent The \code{if}-condition in the for-comprehension
|
|
679 |
filters out all pairs where the sum is not even.
|
|
680 |
|
|
681 |
While hopefully this all looks reasonable, there is one
|
|
682 |
complication: In the examples above we always wanted to
|
|
683 |
transform one list into another list (e.g.~list of squares),
|
|
684 |
or one set into another set (set of numbers into set of
|
|
685 |
reminders modulo 3). What happens if we just want to print out
|
|
686 |
a list of integers? Then actually the for-comprehension
|
|
687 |
needs to be modified. The reason is that \code{print}, you
|
|
688 |
guessed it, does not produce any result, but only produces
|
|
689 |
what is in the functional-programming-lingo called a
|
197
|
690 |
\emph{side-effect}. Printing out the list of numbers from 1 to 5
|
123
|
691 |
would look as follows
|
|
692 |
|
|
693 |
\begin{lstlisting}[numbers=none]
|
|
694 |
scala> for (n <- (1 to 5).toList) print(n)
|
|
695 |
12345
|
|
696 |
\end{lstlisting}
|
|
697 |
|
|
698 |
\noindent
|
|
699 |
where you need to omit the keyword \code{yield}. You can
|
|
700 |
also do more elaborate calculations such as
|
|
701 |
|
|
702 |
\begin{lstlisting}[numbers=none]
|
|
703 |
scala> for (n <- (1 to 5).toList) {
|
197
|
704 |
val square = n * n
|
|
705 |
println(s"$n * $n = $square")
|
123
|
706 |
}
|
|
707 |
1 * 1 = 1
|
|
708 |
2 * 2 = 4
|
|
709 |
3 * 3 = 9
|
|
710 |
4 * 4 = 16
|
|
711 |
5 * 5 = 25
|
|
712 |
\end{lstlisting}%$
|
|
713 |
|
|
714 |
\noindent In this code I use a variable assignment (\code{val
|
197
|
715 |
square = ...} ) and also what is called in Scala a
|
123
|
716 |
\emph{string interpolation}, written \code{s"..."}. The latter
|
|
717 |
is for printing out an equation. It allows me to refer to the
|
|
718 |
integer values \code{n} and \code{square\_n} inside a string.
|
|
719 |
This is very convenient for printing out ``things''.
|
|
720 |
|
|
721 |
The corresponding map construction for functions with
|
|
722 |
side-effects is in Scala called \code{foreach}. So you
|
|
723 |
could also write
|
|
724 |
|
|
725 |
|
|
726 |
\begin{lstlisting}[numbers=none]
|
|
727 |
scala> (1 to 5).toList.foreach(n => print(n))
|
|
728 |
12345
|
|
729 |
\end{lstlisting}
|
|
730 |
|
|
731 |
|
|
732 |
\noindent or even just
|
|
733 |
|
|
734 |
\begin{lstlisting}[numbers=none]
|
|
735 |
scala> (1 to 5).toList.foreach(print)
|
|
736 |
12345
|
|
737 |
\end{lstlisting}
|
|
738 |
|
|
739 |
\noindent Again I hope this reminds you a bit of your
|
|
740 |
lambda-calculus lessons, where an explanation is given why
|
|
741 |
both forms produce the same result.
|
|
742 |
|
|
743 |
|
|
744 |
If you want to find out more about maps and functions with
|
|
745 |
side-effects, you can ponder about the response Scala gives if
|
|
746 |
you replace \code{foreach} by \code{map} in the expression
|
|
747 |
above. Scala will still allow \code{map} with side-effect
|
|
748 |
functions, but then reacts with a slightly interesting result.
|
|
749 |
|
|
750 |
\subsection*{Types}
|
|
751 |
|
|
752 |
In most functional programming languages, types play an
|
|
753 |
important role. Scala is such a language. You have already
|
|
754 |
seen built-in types, like \code{Int}, \code{Boolean},
|
|
755 |
\code{String} and \code{BigInt}, but also user-defined ones,
|
195
|
756 |
like \code{Rexp} (see coursework). Unfortunately, types can be a thorny
|
123
|
757 |
subject, especially in Scala. For example, why do we need to
|
|
758 |
give the type to \code{toSet[Int]}, but not to \code{toList}?
|
|
759 |
The reason is the power of Scala, which sometimes means it
|
|
760 |
cannot infer all necessary typing information. At the
|
195
|
761 |
beginning, while getting familiar with Scala, I recommend a
|
123
|
762 |
``play-it-by-ear-approach'' to types. Fully understanding
|
|
763 |
type-systems, especially complicated ones like in Scala, can
|
|
764 |
take a module on their own.\footnote{Still, such a study can
|
|
765 |
be a rewarding training: If you are in the business of
|
|
766 |
designing new programming languages, you will not be able to
|
|
767 |
turn a blind eye to types. They essentially help programmers
|
|
768 |
to avoid common programming errors and help with maintaining
|
|
769 |
code.}
|
|
770 |
|
|
771 |
In Scala, types are needed whenever you define an inductive
|
|
772 |
datatype and also whenever you define functions (their
|
|
773 |
arguments and their results need a type). Base types are types
|
|
774 |
that do not take any (type)arguments, for example \code{Int}
|
|
775 |
and \code{String}. Compound types take one or more arguments,
|
|
776 |
which as seen earlier need to be given in angle-brackets, for
|
|
777 |
example \code{List[Int]} or \code{Set[List[String]]} or
|
|
778 |
\code{Map[Int, Int]}.
|
|
779 |
|
|
780 |
There are a few special type-constructors that fall outside
|
|
781 |
this pattern. One is for tuples, where the type is written
|
|
782 |
with parentheses. For example
|
|
783 |
|
|
784 |
\begin{lstlisting}[ numbers=none]
|
|
785 |
(Int, Int, String)
|
|
786 |
\end{lstlisting}
|
|
787 |
|
|
788 |
\noindent is for a triple (a tuple with three components---two
|
|
789 |
integers and a string). Tuples are helpful if you want to
|
|
790 |
define functions with multiple results, say the function
|
|
791 |
returning the quotient and reminder of two numbers. For this
|
|
792 |
you might define:
|
|
793 |
|
|
794 |
|
|
795 |
\begin{lstlisting}[ numbers=none]
|
|
796 |
def quo_rem(m: Int, n: Int) : (Int, Int) = (m / n, m % n)
|
|
797 |
\end{lstlisting}
|
|
798 |
|
|
799 |
|
|
800 |
\noindent Since this function returns a pair of integers, its
|
|
801 |
return type needs to be of type \code{(Int, Int)}.
|
|
802 |
Incidentally, this is also the input type of this function.
|
|
803 |
Notice this function takes \emph{two} arguments, namely
|
|
804 |
\code{m} and \code{n}, both of which are integers. They are
|
|
805 |
``packaged'' in a pair. Consequently the complete type of
|
|
806 |
\code{quo_rem} is
|
|
807 |
|
|
808 |
\begin{lstlisting}[ numbers=none]
|
|
809 |
(Int, Int) => (Int, Int)
|
|
810 |
\end{lstlisting}
|
|
811 |
|
|
812 |
Another special type-constructor is for functions, written as
|
|
813 |
the arrow \code{=>}. For example, the type \code{Int =>
|
|
814 |
String} is for a function that takes an integer as input
|
|
815 |
argument and produces a string as result. A function of this
|
|
816 |
type is for instance
|
|
817 |
|
|
818 |
\begin{lstlisting}[numbers=none]
|
|
819 |
def mk_string(n: Int) : String = n match {
|
|
820 |
case 0 => "zero"
|
|
821 |
case 1 => "one"
|
|
822 |
case 2 => "two"
|
|
823 |
case _ => "many"
|
|
824 |
}
|
|
825 |
\end{lstlisting}
|
|
826 |
|
|
827 |
\noindent It takes an integer as input argument and returns a
|
|
828 |
string. Unlike other functional programming languages, there
|
|
829 |
is in Scala no easy way to find out the types of existing
|
|
830 |
functions, except by looking into the documentation
|
|
831 |
|
|
832 |
\begin{quote}
|
|
833 |
\url{http://www.scala-lang.org/api/current/}
|
|
834 |
\end{quote}
|
|
835 |
|
|
836 |
The function arrow can also be iterated, as in
|
|
837 |
\code{Int => String => Boolean}. This is the type for a function
|
|
838 |
taking an integer as first argument and a string as second,
|
|
839 |
and the result of the function is a boolean. Though silly, a
|
|
840 |
function of this type would be
|
|
841 |
|
|
842 |
|
|
843 |
\begin{lstlisting}[numbers=none]
|
|
844 |
def chk_string(n: Int)(s: String) : Boolean =
|
|
845 |
mk_string(n) == s
|
|
846 |
\end{lstlisting}
|
|
847 |
|
|
848 |
|
|
849 |
\noindent which checks whether the integer \code{n}
|
|
850 |
corresponds to the name \code{s} given by the function
|
|
851 |
\code{mk\_string}. Notice the unusual way of specifying the
|
|
852 |
arguments of this function: the arguments are given one after
|
|
853 |
the other, instead of being in a pair (what would be the type
|
|
854 |
of this function then?). This way of specifying the arguments
|
|
855 |
can be useful, for example in situations like this
|
|
856 |
|
|
857 |
\begin{lstlisting}[numbers=none]
|
|
858 |
scala> List("one", "two", "three", "many").map(chk_string(2))
|
|
859 |
res4 = List(false, true, false, false)
|
|
860 |
|
|
861 |
scala> List("one", "two", "three", "many").map(chk_string(3))
|
|
862 |
res5 = List(false, false, false, true)
|
|
863 |
\end{lstlisting}
|
|
864 |
|
|
865 |
\noindent In each case we can give to \code{map} a specialised
|
|
866 |
version of \code{chk_string}---once specialised to 2 and once
|
|
867 |
to 3. This kind of ``specialising'' a function is called
|
|
868 |
\emph{partial application}---we have not yet given to this
|
|
869 |
function all arguments it needs, but only some of them.
|
|
870 |
|
|
871 |
Coming back to the type \code{Int => String => Boolean}. The
|
|
872 |
rule about such function types is that the right-most type
|
|
873 |
specifies what the function returns (a boolean in this case).
|
|
874 |
The types before that specify how many arguments the function
|
|
875 |
expects and what their type is (in this case two arguments,
|
|
876 |
one of type \code{Int} and another of type \code{String}).
|
|
877 |
Given this rule, what kind of function has type
|
|
878 |
\mbox{\code{(Int => String) => Boolean}}? Well, it returns a
|
|
879 |
boolean. More interestingly, though, it only takes a single
|
|
880 |
argument (because of the parentheses). The single argument
|
|
881 |
happens to be another function (taking an integer as input and
|
|
882 |
returning a string). Remember that \code{mk_string} is just
|
|
883 |
such a function. So how can we use it? For this define
|
|
884 |
the somewhat silly function \code{apply_3}:
|
|
885 |
|
|
886 |
\begin{lstlisting}[numbers=none]
|
|
887 |
def apply_3(f: Int => String): Bool = f(3) == "many"
|
|
888 |
|
|
889 |
scala> apply_3(mk_string)
|
|
890 |
res6 = true
|
|
891 |
\end{lstlisting}
|
|
892 |
|
|
893 |
You might ask: Apart from silly functions like above, what is
|
|
894 |
the point of having functions as input arguments to other
|
|
895 |
functions? In Java there is indeed no need of this kind of
|
|
896 |
feature: at least in the past it did not allow such
|
197
|
897 |
constructions. I think, the point of Java 8 and successors was to lift this
|
123
|
898 |
restriction. But in all functional programming languages,
|
|
899 |
including Scala, it is really essential to allow functions as
|
|
900 |
input argument. Above you already seen \code{map} and
|
|
901 |
\code{foreach} which need this. Consider the functions
|
|
902 |
\code{print} and \code{println}, which both print out strings,
|
|
903 |
but the latter adds a line break. You can call \code{foreach}
|
|
904 |
with either of them and thus changing how, for example, five
|
|
905 |
numbers are printed.
|
|
906 |
|
|
907 |
|
|
908 |
\begin{lstlisting}[numbers=none]
|
|
909 |
scala> (1 to 5).toList.foreach(print)
|
|
910 |
12345
|
|
911 |
scala> (1 to 5).toList.foreach(println)
|
|
912 |
1
|
|
913 |
2
|
|
914 |
3
|
|
915 |
4
|
|
916 |
5
|
|
917 |
\end{lstlisting}
|
|
918 |
|
|
919 |
|
|
920 |
\noindent This is actually one of the main design principles
|
|
921 |
in functional programming. You have generic functions like
|
|
922 |
\code{map} and \code{foreach} that can traverse data containers,
|
|
923 |
like lists or sets. They then take a function to specify what
|
|
924 |
should be done with each element during the traversal. This
|
|
925 |
requires that the generic traversal functions can cope with
|
|
926 |
any kind of function (not just functions that, for example,
|
|
927 |
take as input an integer and produce a string like above).
|
|
928 |
This means we cannot fix the type of the generic traversal
|
|
929 |
functions, but have to keep them
|
181
|
930 |
\emph{polymorphic}.\footnote{Another interesting topic about
|
123
|
931 |
types, but we omit it here for the sake of brevity.}
|
|
932 |
|
|
933 |
There is one more type constructor that is rather special. It
|
|
934 |
is called \code{Unit}. Recall that \code{Boolean} has two
|
|
935 |
values, namely \code{true} and \code{false}. This can be used,
|
|
936 |
for example, to test something and decide whether the test
|
|
937 |
succeeds or not. In contrast the type \code{Unit} has only a
|
|
938 |
single value, written \code{()}. This seems like a completely
|
|
939 |
useless type and return value for a function, but is actually
|
|
940 |
quite useful. It indicates when the function does not return
|
|
941 |
any result. The purpose of these functions is to cause
|
|
942 |
something being written on the screen or written into a file,
|
|
943 |
for example. This is what is called they cause some effect on
|
|
944 |
the side, namely a new content displayed on the screen or some
|
|
945 |
new data in a file. Scala uses the \code{Unit} type to indicate
|
|
946 |
that a function does not have a result, but potentially causes
|
|
947 |
some side-effect. Typical examples are the printing functions,
|
|
948 |
like \code{print}.
|
|
949 |
|
|
950 |
|
143
|
951 |
% \subsection*{Cool Stuff}
|
123
|
952 |
|
143
|
953 |
% The first wow-moment I had with Scala was when I came across
|
|
954 |
% the following code-snippet for reading a web-page.
|
123
|
955 |
|
|
956 |
|
143
|
957 |
% \begin{lstlisting}[ numbers=none]
|
|
958 |
% import io.Source
|
|
959 |
% val url = """http://www.inf.kcl.ac.uk/staff/urbanc/"""
|
|
960 |
% Source.fromURL(url)("ISO-8859-1").take(10000).mkString
|
|
961 |
% \end{lstlisting}
|
123
|
962 |
|
|
963 |
|
143
|
964 |
% \noindent These three lines return a string containing the
|
|
965 |
% HTML-code of my webpage. It actually already does something
|
|
966 |
% more sophisticated, namely only returns the first 10000
|
|
967 |
% characters of a webpage in case it is too large. Why is that
|
|
968 |
% code-snippet of any interest? Well, try implementing
|
|
969 |
% reading-from-a-webpage in Java. I also like the possibility of
|
|
970 |
% triple-quoting strings, which I have only seen in Scala so
|
|
971 |
% far. The idea behind this is that in such a string all
|
|
972 |
% characters are interpreted literally---there are no escaped
|
|
973 |
% characters, like \verb|\n| for newlines.
|
123
|
974 |
|
143
|
975 |
% My second wow-moment I had with a feature of Scala that other
|
|
976 |
% functional programming languages do not have. This feature is
|
|
977 |
% about implicit type conversions. If you have regular
|
|
978 |
% expressions and want to use them for language processing you
|
|
979 |
% often want to recognise keywords in a language, for example
|
|
980 |
% \code{for},{} \code{if},{} \code{yield} and so on. But the
|
|
981 |
% basic regular expression \code{CHAR} can only recognise a
|
|
982 |
% single character. In order to recognise a whole string, like
|
|
983 |
% \code{for}, you have to put many of those together using
|
|
984 |
% \code{SEQ}:
|
123
|
985 |
|
|
986 |
|
143
|
987 |
% \begin{lstlisting}[numbers=none]
|
|
988 |
% SEQ(CHAR('f'), SEQ(CHAR('o'), CHAR('r')))
|
|
989 |
% \end{lstlisting}
|
123
|
990 |
|
143
|
991 |
% \noindent This gets quickly unreadable when the strings and
|
|
992 |
% regular expressions get more complicated. In other functional
|
|
993 |
% programming languages, you can explicitly write a conversion
|
|
994 |
% function that takes a string, say \dq{\pcode{for}}, and
|
|
995 |
% generates the regular expression above. But then your code is
|
|
996 |
% littered with such conversion functions.
|
123
|
997 |
|
143
|
998 |
% In Scala you can do better by ``hiding'' the conversion
|
|
999 |
% functions. The keyword for doing this is \code{implicit} and
|
|
1000 |
% it needs a built-in library called
|
123
|
1001 |
|
143
|
1002 |
% \begin{lstlisting}[numbers=none]
|
|
1003 |
% scala.language.implicitConversions
|
|
1004 |
% \end{lstlisting}
|
123
|
1005 |
|
143
|
1006 |
% \noindent
|
|
1007 |
% Consider the code
|
123
|
1008 |
|
|
1009 |
|
143
|
1010 |
% \begin{lstlisting}[language=Scala]
|
|
1011 |
% import scala.language.implicitConversions
|
123
|
1012 |
|
143
|
1013 |
% def charlist2rexp(s: List[Char]) : Rexp = s match {
|
|
1014 |
% case Nil => EMPTY
|
|
1015 |
% case c::Nil => CHAR(c)
|
|
1016 |
% case c::s => SEQ(CHAR(c), charlist2rexp(s))
|
|
1017 |
% }
|
123
|
1018 |
|
143
|
1019 |
% implicit def string2rexp(s: String) : Rexp =
|
|
1020 |
% charlist2rexp(s.toList)
|
|
1021 |
% \end{lstlisting}
|
123
|
1022 |
|
|
1023 |
|
143
|
1024 |
% \noindent where the first seven lines implement a function
|
|
1025 |
% that given a list of characters generates the corresponding
|
|
1026 |
% regular expression. In Lines 9 and 10, this function is used
|
|
1027 |
% for transforming a string into a regular expression. Since the
|
|
1028 |
% \code{string2rexp}-function is declared as \code{implicit},
|
|
1029 |
% the effect will be that whenever Scala expects a regular
|
|
1030 |
% expression, but I only give it a string, it will automatically
|
|
1031 |
% insert a call to the \code{string2rexp}-function. I can now
|
|
1032 |
% write for example
|
123
|
1033 |
|
143
|
1034 |
% \begin{lstlisting}[numbers=none]
|
|
1035 |
% scala> ALT("ab", "ac")
|
|
1036 |
% res9 = ALT(SEQ(CHAR(a),CHAR(b)),SEQ(CHAR(a),CHAR(c)))
|
|
1037 |
% \end{lstlisting}
|
123
|
1038 |
|
143
|
1039 |
% \noindent Recall that \code{ALT} expects two regular
|
|
1040 |
% expressions as arguments, but I only supply two strings. The
|
|
1041 |
% implicit conversion function will transform the string into a
|
|
1042 |
% regular expression.
|
123
|
1043 |
|
143
|
1044 |
% Using implicit definitions, Scala allows me to introduce
|
|
1045 |
% some further syntactic sugar for regular expressions:
|
123
|
1046 |
|
|
1047 |
|
143
|
1048 |
% \begin{lstlisting}[ numbers=none]
|
|
1049 |
% implicit def RexpOps(r: Rexp) = new {
|
|
1050 |
% def | (s: Rexp) = ALT(r, s)
|
|
1051 |
% def ~ (s: Rexp) = SEQ(r, s)
|
|
1052 |
% def % = STAR(r)
|
|
1053 |
% }
|
123
|
1054 |
|
143
|
1055 |
% implicit def stringOps(s: String) = new {
|
|
1056 |
% def | (r: Rexp) = ALT(s, r)
|
|
1057 |
% def | (r: String) = ALT(s, r)
|
|
1058 |
% def ~ (r: Rexp) = SEQ(s, r)
|
|
1059 |
% def ~ (r: String) = SEQ(s, r)
|
|
1060 |
% def % = STAR(s)
|
|
1061 |
% }
|
|
1062 |
% \end{lstlisting}
|
123
|
1063 |
|
|
1064 |
|
143
|
1065 |
% \noindent This might seem a bit overly complicated, but its effect is
|
|
1066 |
% that I can now write regular expressions such as $ab + ac$
|
|
1067 |
% simply as
|
123
|
1068 |
|
|
1069 |
|
143
|
1070 |
% \begin{lstlisting}[numbers=none]
|
|
1071 |
% scala> "ab" | "ac"
|
|
1072 |
% res10 = ALT(SEQ(CHAR(a),CHAR(b)),SEQ(CHAR(a),CHAR(c)))
|
|
1073 |
% \end{lstlisting}
|
123
|
1074 |
|
|
1075 |
|
143
|
1076 |
% \noindent I leave you to figure out what the other
|
|
1077 |
% syntactic sugar in the code above stands for.
|
123
|
1078 |
|
143
|
1079 |
% One more useful feature of Scala is the ability to define
|
|
1080 |
% functions with varying argument lists. This is a feature that
|
|
1081 |
% is already present in old languages, like C, but seems to have
|
|
1082 |
% been forgotten in the meantime---Java does not have it. In the
|
|
1083 |
% context of regular expressions this feature comes in handy:
|
|
1084 |
% Say you are fed up with writing many alternatives as
|
123
|
1085 |
|
|
1086 |
|
143
|
1087 |
% \begin{lstlisting}[numbers=none]
|
|
1088 |
% ALT(..., ALT(..., ALT(..., ...)))
|
|
1089 |
% \end{lstlisting}
|
123
|
1090 |
|
|
1091 |
|
143
|
1092 |
% \noindent To make it difficult, you do not know how deep such
|
|
1093 |
% alternatives are nested. So you need something flexible that
|
|
1094 |
% can take as many alternatives as needed. In Scala one can
|
|
1095 |
% achieve this by adding a \code{*} to the type of an argument.
|
|
1096 |
% Consider the code
|
123
|
1097 |
|
|
1098 |
|
143
|
1099 |
% \begin{lstlisting}[language=Scala]
|
|
1100 |
% def Alts(rs: List[Rexp]) : Rexp = rs match {
|
|
1101 |
% case Nil => NULL
|
|
1102 |
% case r::Nil => r
|
|
1103 |
% case r::rs => ALT(r, Alts(rs))
|
|
1104 |
% }
|
123
|
1105 |
|
143
|
1106 |
% def ALTS(rs: Rexp*) = Alts(rs.toList)
|
|
1107 |
% \end{lstlisting}
|
123
|
1108 |
|
|
1109 |
|
143
|
1110 |
% \noindent The function in Lines 1 to 5 takes a list of regular
|
|
1111 |
% expressions and converts it into an appropriate alternative
|
|
1112 |
% regular expression. In Line 7 there is a wrapper for this
|
|
1113 |
% function which uses the feature of varying argument lists. The
|
|
1114 |
% effect of this code is that I can write the regular
|
|
1115 |
% expression for keywords as
|
123
|
1116 |
|
|
1117 |
|
143
|
1118 |
% \begin{lstlisting}[numbers=none]
|
|
1119 |
% ALTS("for", "def", "yield", "implicit", "if", "match", "case")
|
|
1120 |
% \end{lstlisting}
|
123
|
1121 |
|
|
1122 |
|
143
|
1123 |
% \noindent Again I leave it to you to find out how much this
|
|
1124 |
% simplifies the regular expression in comparison with if I had
|
|
1125 |
% to write this by hand using only the ``plain'' regular
|
|
1126 |
% expressions from the inductive datatype.
|
|
1127 |
|
197
|
1128 |
%\bigskip\noindent
|
|
1129 |
%\textit{More TBD.}
|
123
|
1130 |
|
197
|
1131 |
%\subsection*{Coursework}
|
181
|
1132 |
|
195
|
1133 |
|
|
1134 |
|
123
|
1135 |
\subsection*{More Info}
|
|
1136 |
|
|
1137 |
There is much more to Scala than I can possibly describe in
|
197
|
1138 |
this document and teach in the lectures. Fortunately there are a
|
|
1139 |
number of free books
|
123
|
1140 |
about Scala and of course lots of help online. For example
|
|
1141 |
|
|
1142 |
\begin{itemize}
|
|
1143 |
\item \url{http://www.scala-lang.org/docu/files/ScalaByExample.pdf}
|
|
1144 |
\item \url{http://www.scala-lang.org/docu/files/ScalaTutorial.pdf}
|
|
1145 |
\item \url{https://www.youtube.com/user/ShadowofCatron}
|
|
1146 |
\item \url{http://docs.scala-lang.org/tutorials}
|
|
1147 |
\item \url{https://www.scala-exercises.org}
|
188
|
1148 |
\item \url{https://twitter.github.io/scala_school}
|
123
|
1149 |
\end{itemize}
|
188
|
1150 |
|
197
|
1151 |
\noindent There is also an online course at Coursera on Functional
|
123
|
1152 |
Programming Principles in Scala by Martin Odersky, the main
|
|
1153 |
developer of the Scala language. And a document that explains
|
|
1154 |
Scala for Java programmers
|
|
1155 |
|
|
1156 |
\begin{itemize}
|
|
1157 |
\item \small\url{http://docs.scala-lang.org/tutorials/scala-for-java-programmers.html}
|
|
1158 |
\end{itemize}
|
|
1159 |
|
|
1160 |
While I am quite enthusiastic about Scala, I am also happy to
|
|
1161 |
admit that it has more than its fair share of faults. The
|
|
1162 |
problem seen earlier of having to give an explicit type to
|
|
1163 |
\code{toSet}, but not \code{toList} is one of them. There are
|
|
1164 |
also many ``deep'' ideas about types in Scala, which even to
|
|
1165 |
me as seasoned functional programmer are puzzling. Whilst
|
|
1166 |
implicits are great, they can also be a source of great
|
|
1167 |
headaches, for example consider the code:
|
|
1168 |
|
|
1169 |
\begin{lstlisting}[numbers=none]
|
|
1170 |
scala> List (1, 2, 3) contains "your mom"
|
|
1171 |
res1: Boolean = false
|
|
1172 |
\end{lstlisting}
|
|
1173 |
|
|
1174 |
\noindent Rather than returning \code{false}, this code should
|
|
1175 |
throw a typing-error. There are also many limitations Scala
|
|
1176 |
inherited from the JVM that can be really annoying. For
|
|
1177 |
example a fixed stack size. One can work around this
|
|
1178 |
particular limitation, but why does one have to?
|
|
1179 |
More such `puzzles' can be found at
|
|
1180 |
|
|
1181 |
\begin{center}
|
|
1182 |
\url{http://scalapuzzlers.com} and
|
|
1183 |
\url{http://latkin.org/blog/2017/05/02/when-the-scala-compiler-doesnt-help/}
|
|
1184 |
\end{center}
|
191
|
1185 |
|
|
1186 |
Even if Scala has been a success in several high-profile companies,
|
|
1187 |
there is also a company (Yammer) that first used Scala in their
|
|
1188 |
production code, but then moved away from it. Allegedly they did not
|
|
1189 |
like the steep learning curve of Scala and also that new versions of
|
|
1190 |
Scala often introduced incompatibilities in old code. Also the Java
|
197
|
1191 |
language is lately developing at lightening speed (in comparison to the past)
|
|
1192 |
taking on many
|
191
|
1193 |
features of Scala and other languages, and it seems even it introduces
|
|
1194 |
new features on its own.
|
123
|
1195 |
|
152
|
1196 |
%So all in all, Scala might not be a great teaching language,
|
|
1197 |
%but I hope this is mitigated by the fact that I never require
|
|
1198 |
%you to write any Scala code. You only need to be able to read
|
|
1199 |
%it. In the coursework you can use any programming language you
|
|
1200 |
%like. If you want to use Scala for this, then be my guest; if
|
|
1201 |
%you do not want, stick with the language you are most familiar
|
|
1202 |
%with.
|
123
|
1203 |
|
|
1204 |
|
191
|
1205 |
\subsection*{Conclusion}
|
|
1206 |
|
197
|
1207 |
I hope you like the short journey in the Scala World: remember we
|
|
1208 |
like you to take on board the functional programming point of view,
|
|
1209 |
rather than just learning another language. If you moan about all the
|
|
1210 |
idiotic features of Scala, well that is part of the packaged according
|
|
1211 |
to this quote:\bigskip
|
|
1212 |
|
|
1213 |
%\begin{itemize}
|
|
1214 |
%\item no exceptions....there two kinds, one ``global'' exceptions, like
|
|
1215 |
%out of memory (not much can be done about this by the ``individual''
|
|
1216 |
%programmer); and ``local one'' open a file that might not exists - in
|
|
1217 |
%the latter you do not want to use exceptions, but Options
|
|
1218 |
%\end{itemize}
|
123
|
1219 |
|
182
|
1220 |
\begin{flushright}\it
|
|
1221 |
There are only two kinds of languages: the ones people complain
|
|
1222 |
about\\ and the ones nobody uses.\smallskip\\
|
|
1223 |
\mbox{}\hfill\small{}---Bjarne Stroustrup (the inventor of C++)
|
|
1224 |
\end{flushright}
|
|
1225 |
|
123
|
1226 |
\end{document}
|
|
1227 |
|
|
1228 |
%%% Local Variables:
|
|
1229 |
%%% mode: latex
|
|
1230 |
%%% TeX-master: t
|
|
1231 |
%%% End:
|