197
+ − 1
% !TEX program = xelatex
123
+ − 2
\documentclass{article}
426
+ − 3
\usepackage{../styles/style}
+ − 4
\usepackage{../styles/langs}
272
+ − 5
\usepackage{tikz}
+ − 6
\usepackage{pgf}
123
+ − 7
\usepackage{marvosym}
184
+ − 8
\usepackage{boxedminipage}
123
+ − 9
352
+ − 10
\lstset{escapeinside={/*!}{!*/}}
+ − 11
\newcommand{\annotation}[1]{\hfill\footnotesize{}#1}
272
+ − 12
352
+ − 13
\usepackage{menukeys}
471
+ − 14
\usepackage{emoji}
335
+ − 15
123
+ − 16
%cheat sheet
+ − 17
%http://worldline.github.io/scala-cheatsheet/
+ − 18
181
+ − 19
% case class, apply, unapply
170
+ − 20
% see https://medium.com/@thejasbabu/scala-pattern-matching-9c9e73ba9a8a
+ − 21
191
+ − 22
% the art of programming
+ − 23
% https://www.youtube.com/watch?v=QdVFvsCWXrA
+ − 24
+ − 25
% functional programming in Scala
+ − 26
%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
+ − 27
197
+ − 28
% functional programming in C
191
+ − 29
%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
+ − 30
+ − 31
%speeding through haskell
+ − 32
%https://openlibra.com/en/book/download/speeding-through-haskell
+ − 33
+ − 34
% fp books --- ocaml
+ − 35
% http://courses.cms.caltech.edu/cs134/cs134b/book.pdf
+ − 36
% http://alexott.net/en/fp/books/
+ − 37
257
+ − 38
%John Hughes’ simple words:
+ − 39
%A combinator is a function which builds program fragments
+ − 40
%from program fragments.
+ − 41
+ − 42
301
+ − 43
%explain graph colouring program (examples from)
264
+ − 44
%https://www.metalevel.at/prolog/optimization
+ − 45
+ − 46
% nice example for map and reduce using Harry potter characters
+ − 47
% https://www.matthewgerstman.com/map-filter-reduce/
+ − 48
333
+ − 49
% interesting talk about differences in Java and Scala
+ − 50
% Goto'19 conference ; about differences in type-system
+ − 51
% https://www.youtube.com/watch?v=e6n-Ci8V2CM
264
+ − 52
329
+ − 53
% Timing
+ − 54
%
+ − 55
% xs.map(x => (x, xs.count(_==x)))
+ − 56
%
+ − 57
% vs xs.groupBy(identity)
+ − 58
%
+ − 59
% first is quadratic, while second is linear.
+ − 60
+ − 61
% contrast map with a for loop in imperative languages
+ − 62
%
+ − 63
% Let’s use a simple example of calculating sales tax on an array of
+ − 64
% prices.
+ − 65
%
+ − 66
% const prices = [19.99, 4.95, 25, 3.50];
+ − 67
% let new_prices = [];
+ − 68
%
+ − 69
% for(let i=0; i < prices.length; i++) {
+ − 70
% new_prices.push(prices[i] * 1.06);
+ − 71
% }
+ − 72
%
+ − 73
% We can achieve the same results using .map():
+ − 74
%
492
+ − 75
% const prices = [19.99, 4.95, 25, 3.50];
329
+ − 76
% let new_prices = prices.map(price => price * 1.06);
+ − 77
%
+ − 78
% The syntax above is condensed so let’s walk through it a bit. The
+ − 79
% .map() method takes a callback, which can be thought of as a function.
+ − 80
% That’s what is between the parentheses. The variable price is the name
+ − 81
% that will be used to identify each value. Since there’s only one
+ − 82
% input, we can omit the usual parentheses around the parameters.
+ − 83
+ − 84
% potentially a worked example? Tetris in scala.js
492
+ − 85
%
329
+ − 86
% https://medium.com/@michael.karen/learning-modern-javascript-with-tetris-92d532bcd057
+ − 87
%
+ − 88
% Scala videos
+ − 89
% https://www.youtube.com/user/DrMarkCLewis
+ − 90
334
+ − 91
+ − 92
%% https://alvinalexander.com/downloads/HelloScala-FreePreview.pdf
492
+ − 93
%%
334
+ − 94
%% Section 10 about strings; interpolations and multiline strings
+ − 95
343
+ − 96
% Easy installation
+ − 97
%https://alexarchambault.github.io/posts/2020-09-21-cs-setup.html
+ − 98
426
+ − 99
% scala libraries
+ − 100
%https://index.scala-lang.org
+ − 101
+ − 102
+ − 103
% Learning functional programming is an opportunity to discover a new
+ − 104
% way to represent programs, to approach problems, and to think about
+ − 105
% languages. While programming with a functional language is still
+ − 106
% fundamentally similar to programming with any other type of language
+ − 107
% (examples of others being imperative or logic), it represents
+ − 108
% programs and algorithms through distinct forms of abstraction and
+ − 109
% gives you a new toolset with which to solve programming
+ − 110
% problems. Additionally, many of the techniques of functional
+ − 111
% programming are beginning to permeate new mainstream languages, so
+ − 112
% taking the time now to develop a thorough understanding of them is
+ − 113
% an investment which will pay great dividends.
+ − 114
+ − 115
334
+ − 116
335
+ − 117
% Exact colors from NB
+ − 118
\usepackage[breakable]{tcolorbox}
+ − 119
\definecolor{incolor}{HTML}{303F9F}
+ − 120
\definecolor{outcolor}{HTML}{D84315}
+ − 121
\definecolor{cellborder}{HTML}{CFCFCF}
+ − 122
\definecolor{cellbackground}{HTML}{F7F7F7}
334
+ − 123
335
+ − 124
492
+ − 125
123
+ − 126
\begin{document}
483
+ − 127
\fnote{\copyright{} Christian Urban, King's College London, 2017, 2018, 2019, 2020, 2021, 2022, 2023, 2024}
123
+ − 128
335
+ − 129
%\begin{tcolorbox}[breakable,size=fbox,boxrule=1pt,pad at break*=1mm,colback=cellbackground,colframe=cellborder]
+ − 130
% abd
+ − 131
%\end{tcolorbox}
+ − 132
125
+ − 133
\section*{A Crash-Course in Scala}
123
+ − 134
492
+ − 135
\mbox{}\hfill\textit{``Scala --- \underline{S}lowly \underline{c}ompiled
182
+ − 136
\underline{a}cademic \underline{la}nguage''}\smallskip\\
192
+ − 137
\mbox{}\hfill\textit{ --- a joke(?) found on Twitter}\bigskip
195
+ − 138
470
+ − 139
\mbox{}\hfill\textit{``Life is too short for \texttt{malloc}.''}\smallskip\\
492
+ − 140
\mbox{}\hfill\textit{ --- said Neal Ford at Oscon'13}\;\hr{https://www.youtube.com/watch?v=7aYS9PcAITQ}\bigskip\\
470
+ − 141
485
+ − 142
% In 1982, James or Jim Morris wrote:
+ − 143
%
+ − 144
% Functional languages are unnatural to use; but so are knives and
+ − 145
% forks, diplomatic protocols, double-entry bookkeeping, and a host of
+ − 146
% other things modern civilization has found useful.
+ − 147
%
+ − 148
% Real Programming in Functional Languages
+ − 149
% Xerox PARC technical report
+ − 150
% CSL·81·11 July 1,1981
+ − 151
+ − 152
470
+ − 153
195
+ − 154
\subsection*{Introduction}
+ − 155
178
+ − 156
\noindent
170
+ − 157
Scala is a programming language that combines functional and
+ − 158
object-oriented programming-styles. It has received quite a bit of
485
+ − 159
attention in the last ten or so years. One reason for this attention is
181
+ − 160
that, like the Java programming language, Scala compiles to the Java
+ − 161
Virtual Machine (JVM) and therefore Scala programs can run under MacOSX,
195
+ − 162
Linux and Windows. Because of this it has also access to
181
+ − 163
the myriads of Java libraries. Unlike Java, however, Scala often allows
186
+ − 164
programmers to write very concise and elegant code. Some therefore say
182
+ − 165
``Scala is the better Java''.\footnote{from
483
+ − 166
\url{https://www.slideshare.net/maximnovak/joy-of-scala}, though this might
492
+ − 167
be outdated as latest versions of Java are catching up somewhat}
188
+ − 168
485
+ − 169
A number of companies---the Guardian, Duolingo, Coursera, FourSquare,
492
+ − 170
Netflix, LinkedIn, ITV, Disney to name a few---either use Scala exclusively in
188
+ − 171
production code, or at least to some substantial degree. Scala seems
+ − 172
also useful in job-interviews (especially in data science) according to
+ − 173
this anecdotal report
170
+ − 174
181
+ − 175
\begin{quote}
+ − 176
\url{http://techcrunch.com/2016/06/14/scala-is-the-new-golden-child}
170
+ − 177
\end{quote}
+ − 178
+ − 179
\noindent
471
+ − 180
The official Scala web-page is here:
170
+ − 181
+ − 182
\begin{quote}
195
+ − 183
\url{http://www.scala-lang.org}\medskip
+ − 184
\end{quote}
170
+ − 185
395
+ − 186
\noindent\alert
485
+ − 187
For PEP, make sure you are using the version 3(!) of Scala. This is
470
+ − 188
the version I am going to use in the lectures and in the coursework. This
485
+ − 189
can be any version of Scala 3.X where $X=\{3,4\}$. Also the minor
+ − 190
number does not matter. Note that this will be the second year I am
+ − 191
using this newer version of Scala -- some hiccups can still happen. Apologies
470
+ − 192
in advance!\bigskip
395
+ − 193
471
+ − 194
\begin{tcolorbox}[colback=red!5!white,colframe=red!75!black]
476
+ − 195
I will be using the \textbf{\texttt{scala-cli}} REPL for Scala 3, rather
471
+ − 196
than the ``plain'' Scala REPL. This is a batteries included version of
492
+ − 197
Scala 3 and is easier to use and to install. In fact
476
+ − 198
\texttt{scala-cli} is designated to replace
+ − 199
the ``plain'' Scala REPL in future versions of Scala.
+ − 200
So why not using it now?
471
+ − 201
It can be downloaded from:
+ − 202
+ − 203
\begin{center}
492
+ − 204
\url{https://scala-cli.virtuslab.org}
+ − 205
\end{center}
+ − 206
\end{tcolorbox}\medskip
471
+ − 207
+ − 208
170
+ − 209
\noindent
485
+ − 210
If you are interested, there are also experimental backends for Scala
470
+ − 211
for generating JavaScript code (\url{https://www.scala-js.org}), and
+ − 212
there is work under way to have a native Scala compiler generating
+ − 213
X86-code (\url{http://www.scala-native.org}). There are also some
476
+ − 214
tricks for Scala programs to run as a native
470
+ − 215
GraalVM~\hr{https://scala-cli.virtuslab.org/docs/cookbooks/native-images/}
476
+ − 216
image. Though be warned these backends are still rather beta or even
470
+ − 217
alpha.
195
+ − 218
+ − 219
\subsection*{VS Code and Scala}
+ − 220
184
+ − 221
I found a convenient IDE for writing Scala programs is Microsoft's
181
+ − 222
\textit{Visual Studio Code} (VS Code) which runs under MacOSX, Linux and
269
Christian Urban <christian dot urban at kcl dot ac dot uk>
diff
changeset
+ − 223
obviously Windows.\footnote{\ldots{}unlike \emph{Microsoft Visual Studio}---note
191
+ − 224
the minuscule difference in the name---which is a heavy-duty,
269
Christian Urban <christian dot urban at kcl dot ac dot uk>
diff
changeset
+ − 225
Windows-only IDE\ldots{}jeez, with all their money could they not have come
191
+ − 226
up with a completely different name for a complete different project?
+ − 227
For the pedantic, Microsoft Visual Studio is an IDE, whereas Visual
485
+ − 228
Studio Code is considered to be a \emph{source code editor}. Anybody
+ − 229
out there knows what the
191
+ − 230
difference is?} It can be downloaded for free from
181
+ − 231
+ − 232
\begin{quote}
+ − 233
\url{https://code.visualstudio.com}
+ − 234
\end{quote}
+ − 235
+ − 236
\noindent
+ − 237
and should already come pre-installed in the Department (together with
195
+ − 238
the Scala compiler). Being a project that just started in 2015, VS Code is
470
+ − 239
relatively new and therefore far from perfect. However it includes a
182
+ − 240
\textit{Marketplace} from which a multitude of extensions can be
184
+ − 241
downloaded that make editing and running Scala code a little easier (see
+ − 242
Figure~\ref{vscode} for my setup).
181
+ − 243
+ − 244
\begin{figure}[t]
492
+ − 245
\begin{boxedminipage}{\textwidth}
+ − 246
\begin{center}
181
+ − 247
\includegraphics[scale=0.15]{../pics/vscode.png}\\[-10mm]\mbox{}
+ − 248
\end{center}
492
+ − 249
\caption{My installation of VS Code / Codium includes the
471
+ − 250
package \textbf{Scala Syntax (official)} 0.5.7 from Marketplace.
+ − 251
I have also bound the keys \keys{Ctrl} \keys{Ret} to the
195
+ − 252
action ``Run-Selected-Text-In-Active-Terminal'' in order to quickly
471
+ − 253
evaluate small code snippets in the Scala REPL. I use Codium's internal
+ − 254
terminal to run \texttt{scala-cli} version 1.0.5 which
+ − 255
uses Scala 3.3.1.\label{vscode}}
184
+ − 256
\end{boxedminipage}
492
+ − 257
\end{figure}
181
+ − 258
476
+ − 259
Actually \alert last year I switched to VS Codium as IDE for writing Scala programs. VS Codium is VS Code
492
+ − 260
minus all the telemetry data that is normally sent to Microsoft. Apart from
470
+ − 261
the telemetry (and Copilot, which you are not supposed to use anyway),
+ − 262
it works pretty much the same way as the original but is driven by a
+ − 263
dedicated community, rather than a big company. You can download VS
+ − 264
Codium from
441
+ − 265
+ − 266
\begin{quote}
+ − 267
\url{https://vscodium.com}
+ − 268
\end{quote}
+ − 269
+ − 270
471
+ − 271
What I like most about VS Code/Codium is that it provides easy access
476
+ − 272
to any Scala REPL. But if you prefer another editor for coding, it is
471
+ − 273
also painless to work with Scala completely on the command line (as
485
+ − 274
you might do with \texttt{g++} in the second part of PEP). For
471
+ − 275
the lazybones among us, there are even online editors and environments
485
+ − 276
for developing and running Scala programs: for example \textit{Scastie}
+ − 277
is one of them. It requires zero setup
+ − 278
(assuming you have a browser handy). You can access it at
492
+ − 279
181
+ − 280
\begin{quote}
485
+ − 281
\url{https://scastie.scala-lang.org}
181
+ − 282
\end{quote}
492
+ − 283
195
+ − 284
\noindent
197
+ − 285
But you should be careful if you use them for your coursework: they
492
+ − 286
are meant to play around, not really for serious work. Therefore make
+ − 287
sure \texttt{scala-cli} works on your own machine ASAP!
197
+ − 288
441
+ − 289
As one might expect, Scala can be used with the heavy-duty IDEs
471
+ − 290
Eclipse and IntelliJ. For example IntelliJ includes plugins for
+ − 291
Scala
170
+ − 292
+ − 293
\begin{quote}
471
+ − 294
\url{https://scalacenter.github.io/bloop/docs/ides/intellij}
170
+ − 295
\end{quote}
+ − 296
+ − 297
\noindent
471
+ − 298
\underline{\textbf{BUT}}, I do \textbf{not} recommend the usage of
492
+ − 299
either Eclipse or IntelliJ for PEP: for the small programs that we will write
+ − 300
in this module, these IDEs seem to make your life
+ − 301
harder, rather than easier. They are really meant to be used when you have a
471
+ − 302
million-lines codebase instead of our small
+ − 303
``toy-programs''\ldots{}for example why on earth am I required to
+ − 304
create a completely new project with several subdirectories when I
+ − 305
just want to try out 20-lines of Scala code? Your mileage may vary
+ − 306
though.~\texttt{;o)}
182
+ − 307
+ − 308
\subsection*{Why Functional Programming?}
+ − 309
186
+ − 310
Before we go on, let me explain a bit more why we want to inflict upon
+ − 311
you another programming language. You hopefully have mastered Java and
485
+ − 312
soon will master C++ as well, you possibly know Python already\ldots{}
+ − 313
the world should be your oyster, no? Well, as usual matters are not as simple
+ − 314
as one might wish. We do require Scala in PEP, but actually we do not
+ − 315
religiously care whether you learn Scala---after all it is just a
+ − 316
programming language (albeit a nifty one IMHO). What we do care about
+ − 317
is that you learn about \textit{functional programming}. Scala is just
+ − 318
the vehicle for that. Still, you need to learn Scala well enough to
+ − 319
get good marks in PEP, but functional programming could perhaps
+ − 320
equally be taught with Haskell, F\#, SML, Ocaml, Kotlin, Clojure,
+ − 321
Scheme, Elm and many other functional programming languages.
333
+ − 322
+ − 323
%Your friendly lecturer just
+ − 324
%happens to like Scala and the Department agreed that it is a good idea
+ − 325
%to inflict Scala upon you.
182
+ − 326
+ − 327
Very likely writing programs in a functional programming language is
470
+ − 328
quite different from what you are used to in your study so far. It
183
+ − 329
might even be totally alien to you. The reason is that functional
+ − 330
programming seems to go against the core principles of
470
+ − 331
\textit{imperative programming} (which is what you do in Java and
471
+ − 332
C/C++). The main idea of imperative programming is that
470
+ − 333
you have some form of \emph{state} in your program and you
+ − 334
continuously change this state by issuing some commands---for example
+ − 335
for updating a field in an array or for adding one to a variable
+ − 336
stored in memory and so on. The classic example for this style of
485
+ − 337
programming is a \texttt{for}-loop in say Java and C/C++. Consider the snippet:
182
+ − 338
+ − 339
\begin{lstlisting}[language=C,numbers=none]
492
+ − 340
for (int i = 10; i < 20; i++) {
269
Christian Urban <christian dot urban at kcl dot ac dot uk>
diff
changeset
+ − 341
//...do something with i...
184
+ − 342
}
182
+ − 343
\end{lstlisting}
+ − 344
470
+ − 345
\noindent Here the integer variable \texttt{i} embodies part of the
+ − 346
state of the program, which is first set to \texttt{10} and then
+ − 347
increased by one in each loop-iteration until it reaches \texttt{20}
+ − 348
at which point the loop exits. When this code is compiled and actually
+ − 349
runs, there will be some dedicated space reserved for \texttt{i} in
+ − 350
memory. This space of typically 32 bits contains \texttt{i}'s current
+ − 351
value\ldots\texttt{10} at the beginning, and then the content will be
+ − 352
overwritten with new content in every iteration. The main point here
+ − 353
is that this kind of updating, or overwriting, of memory is
+ − 354
25.806\ldots or \textbf{THE ROOT OF ALL EVIL}!!
186
+ − 355
+ − 356
\begin{center}
+ − 357
\includegraphics[scale=0.25]{../pics/root-of-all-evil.png}
492
+ − 358
\end{center}
186
+ − 359
182
+ − 360
+ − 361
\noindent
+ − 362
\ldots{}Well, it is perfectly benign if you have a sequential program
+ − 363
that gets run instruction by instruction...nicely one after another.
+ − 364
This kind of running code uses a single core of your CPU and goes as
184
+ − 365
fast as your CPU frequency, also called clock-speed, allows. The problem
+ − 366
is that this clock-speed has not much increased over the past decade and
+ − 367
no dramatic increases are predicted for any time soon. So you are a bit
277
+ − 368
stuck. This is unlike previous generations of developers who could rely
278
+ − 369
upon the fact that approximately every 2 years their code would run
+ − 370
twice as fast because the clock-speed of their CPUs got twice as fast.
333
+ − 371
485
+ − 372
Unfortunately this does not happen any more nowadays. To get you out
+ − 373
of this dreadful situation, CPU producers pile more and more cores
+ − 374
into CPUs in order to make them more powerful and potentially make
+ − 375
software faster. The task for you as developer is to take somehow
+ − 376
advantage of these cores by running as much of your code as possible
+ − 377
in parallel on as many cores you have available (typically 4-8 or even
+ − 378
more in modern laptops and sometimes much more on high-end
492
+ − 379
machines---and we conveniently ignore here how many cores are on modern
+ − 380
GPUs, which can be hundreds or even thousands). In this situation
+ − 381
\textit{mutable} variables like \texttt{i} in
485
+ − 382
the for-loop above are evil, or at least a major nuisance: Because if
+ − 383
you want to distribute some of the loop-iterations over several cores
+ − 384
that are currently idle in your system, you need to be extremely
+ − 385
careful about who can read and overwrite the variable
+ − 386
\texttt{i}.\footnote{If you are of the mistaken belief that nothing
+ − 387
nasty can happen to \texttt{i} inside the \texttt{for}-loop, then
+ − 388
you will have to be extra careful with the C++ material.}
333
+ − 389
Especially the writing operation is critical because you do not want
+ − 390
that conflicting writes mess about with \texttt{i}. Take my word: an
485
+ − 391
untold amount of misery has arisen from this problem. The catch is
492
+ − 392
that if you try to solve this problem in languages like C/C++ or Java, and be as
485
+ − 393
defensive as possible about reads and writes to \texttt{i}, then you
+ − 394
need to synchronise access to it. The result is that very often your
+ − 395
program waits more than it runs, thereby defeating the point of trying
+ − 396
to run the program in parallel in the first place. If you are less
+ − 397
defensive, then usually all hell breaks loose by seemingly obtaining
+ − 398
random results. And forget the idea of being able to debug such
+ − 399
code. If you want to watch a 5-minute video of horror stories, feel
+ − 400
free to follow \ldots{}
492
+ − 401
\hr{https://www.youtube.com/watch?v=LdLUgCJkiHY} \raisebox{-0.7mm}{\emoji{rofl}} (I love the fact, he
+ − 402
says at 4:02 mins that he does not understand how the JVM really
485
+ − 403
works\ldots{} I always assumed I am the only idiot who does not
492
+ − 404
understand how threads work on the JVM. Apparently not.
+ − 405
But the point is that I am a functional programmer: I do not care -- I do not have to
+ − 406
understand them.)\bigskip
182
+ − 407
485
+ − 408
\noindent
184
+ − 409
The central idea of functional programming is to eliminate any state
492
+ − 410
and all mutable variables from programs---or at least from the ``interesting bits'' of the
195
+ − 411
programs. Because then it is easy to parallelise the resulting
+ − 412
programs: if you do not have any state, then once created, all memory
+ − 413
content stays unchanged and reads to such memory are absolutely safe
+ − 414
without the need of any synchronisation. An example is given in
+ − 415
Figure~\ref{mand} where in the absence of the annoying state, Scala
+ − 416
makes it very easy to calculate the Mandelbrot set on as many cores of
+ − 417
your CPU as possible. Why is it so easy in this example? Because each
+ − 418
pixel in the Mandelbrot set can be calculated independently and the
+ − 419
calculation does not need to update any variable. It is so easy in
+ − 420
fact that going from the sequential version of the Mandelbrot program
+ − 421
to the parallel version can be achieved by adding just eight
+ − 422
characters---in two places you have to add \texttt{.par}. Try the same
272
+ − 423
in C/C++ or Java!
182
+ − 424
+ − 425
\begin{figure}[p]
184
+ − 426
\begin{boxedminipage}{\textwidth}
187
+ − 427
492
+ − 428
A Scala program for generating pretty pictures of the Mandelbrot set.\smallskip\\
191
+ − 429
(See \url{https://en.wikipedia.org/wiki/Mandelbrot_set} or\\
+ − 430
\phantom{(See }\url{https://www.youtube.com/watch?v=aSg2Db3jF_4}):
492
+ − 431
\begin{center}
+ − 432
\begin{tabular}{c}
191
+ − 433
\includegraphics[scale=0.11]{../pics/mand1.png}\\[-8mm]\mbox{}
184
+ − 434
\end{tabular}
187
+ − 435
\end{center}
184
+ − 436
187
+ − 437
\begin{center}
+ − 438
\begin{tabular}{@{}p{0.45\textwidth}|p{0.45\textwidth}@{}}
191
+ − 439
\bf sequential version: & \bf parallel version on 4 cores:\smallskip\\
182
+ − 440
191
+ − 441
{\hfill\includegraphics[scale=0.11]{../pics/mand4.png}\hfill} &
+ − 442
{\hfill\includegraphics[scale=0.11]{../pics/mand3.png}\hfill} \\
187
+ − 443
+ − 444
{\footnotesize\begin{lstlisting}[xleftmargin=-1mm]
186
+ − 445
for (y <- (0 until H)) {
+ − 446
for (x <- (0 until W)) {
492
+ − 447
+ − 448
val c = start +
186
+ − 449
(x * d_x + y * d_y * i)
492
+ − 450
val iters = iterations(c, max)
+ − 451
val colour =
+ − 452
if (iters == max) black
186
+ − 453
else colours(iters % 16)
+ − 454
191
+ − 455
pixel(x, y, colour)
186
+ − 456
}
+ − 457
viewer.updateUI()
492
+ − 458
}
+ − 459
\end{lstlisting}}
+ − 460
&
187
+ − 461
{\footnotesize\begin{lstlisting}[xleftmargin=0mm]
400
+ − 462
for (y <- (0 until H).par) {
+ − 463
for (x <- (0 until W).par) {
492
+ − 464
+ − 465
val c = start +
187
+ − 466
(x * d_x + y * d_y * i)
492
+ − 467
val iters = iterations(c, max)
+ − 468
val colour =
+ − 469
if (iters == max) black
187
+ − 470
else colours(iters % 16)
492
+ − 471
191
+ − 472
pixel(x, y, colour)
187
+ − 473
}
+ − 474
viewer.updateUI()
492
+ − 475
}
191
+ − 476
\end{lstlisting}}\\[-2mm]
187
+ − 477
+ − 478
\centering\includegraphics[scale=0.5]{../pics/cpu2.png} &
188
+ − 479
\centering\includegraphics[scale=0.5]{../pics/cpu1.png}
184
+ − 480
\end{tabular}
+ − 481
\end{center}
485
+ − 482
\caption{The code of the two ``main'' loops in my version of the mandelbrot program.
191
+ − 483
The parallel version differs only in \texttt{.par} being added to the
195
+ − 484
``ranges'' of the x and y coordinates. As can be seen from the CPU loads, in
+ − 485
the sequential version there is a lower peak for an extended period,
191
+ − 486
while in the parallel version there is a short sharp burst for
492
+ − 487
essentially the same workload\ldots{}meaning you get more work done
+ − 488
in a shorter amount of time. This easy \emph{parallelisation}
485
+ − 489
only works reliably with immutable programs.
492
+ − 490
\label{mand}}
184
+ − 491
\end{boxedminipage}
492
+ − 492
\end{figure}
182
+ − 493
275
+ − 494
But remember this easy parallelisation of code requires that we have no
492
+ − 495
state in our programs\ldots{}that is \emph{no} counters like \texttt{i} in
275
+ − 496
\texttt{for}-loops. You might then ask, how do I write loops without
+ − 497
such counters? Well, teaching you that this is possible is one of the
492
+ − 498
main points of the Scala-part in PEP. I can assure you it \emph{is} possible,
275
+ − 499
but you have to get your head around it. Once you have mastered this, it
+ − 500
will be fun to have no state in your programs (a side product is that it
492
+ − 501
much easier to debug state-less code and it is also more often than not easier
275
+ − 502
to understand). So have fun with Scala!\footnote{If you are still not
+ − 503
convinced about the function programming ``thing'', there are a few more
+ − 504
arguments: a lot of research in programming languages happens to take
+ − 505
place in functional programming languages. This has resulted in
+ − 506
ultra-useful features such as pattern-matching, strong type-systems,
+ − 507
laziness, implicits, algebraic datatypes to name a few. Imperative
+ − 508
languages seem to often lag behind in adopting them: I know, for
+ − 509
example, that Java will at some point in the future support
+ − 510
pattern-matching, which has been used for example in SML for at least
+ − 511
40(!) years. See
441
+ − 512
\url{https://openjdk.org/projects/amber/design-notes/patterns/pattern-matching-for-java}.
275
+ − 513
Automatic garbage collection was included in Java in 1995; the
+ − 514
functional language LISP had this already in 1958. Generics were added
+ − 515
to Java 5 in 2004; the functional language SML had it since 1990.
277
+ − 516
Higher-order functions were added to C\# in 2007, to Java 8 in
275
+ − 517
2014; again LISP had them since 1958. Also Rust, a C-like programming
+ − 518
language that has been developed since 2010 and is gaining quite some
+ − 519
interest, borrows many ideas from functional programming from
277
+ − 520
yesteryear.}\medskip
170
+ − 521
277
+ − 522
\noindent
441
+ − 523
If you need any after-work distractions, you might have fun reading
470
+ − 524
the following article about FP (functional programming) --- you
441
+ − 525
might have to disable your browser cookies though if you want to read
+ − 526
it for free. And spoiler alert: This is tongue-in-cheek \texttt{;o)}
277
+ − 527
+ − 528
\begin{quote}
470
+ − 529
\url{https://archive.ph/vrofC}
277
+ − 530
\end{quote}
188
+ − 531
492
+ − 532
\noindent
+ − 533
Relevant xkcd entries about functional programming are XXX.
+ − 534
123
+ − 535
\subsection*{The Very Basics}
+ − 536
476
+ − 537
Let us get back to Scala and \texttt{scala-cli}: One advantage of
+ − 538
Scala over Java is that it includes an interpreter (a REPL, or
123
+ − 539
\underline{R}ead-\underline{E}val-\underline{P}rint-\underline{L}oop)
181
+ − 540
with which you can run and test small code snippets without the need
123
+ − 541
of a compiler. This helps a lot with interactively developing
470
+ − 542
programs. It is my preferred way of writing small Scala programs. Once
476
+ − 543
you installed \texttt{scala-cli}, you can start the interpreter by typing on the
470
+ − 544
command line:
123
+ − 545
+ − 546
\begin{lstlisting}[language={},numbers=none,basicstyle=\ttfamily\small]
471
+ − 547
$ scala-cli
485
+ − 548
Welcome to Scala 3.4.1 (21.0.2, Java OpenJDK 64-Bit Server VM).
471
+ − 549
Type in expressions for evaluation. Or try :help.
123
+ − 550
+ − 551
scala>
+ − 552
\end{lstlisting}%$
+ − 553
476
+ − 554
\noindent The precise response may vary depending on the version and
+ − 555
platform where you installed \texttt{scala-cli}. Make sure however that
+ − 556
\texttt{scala-cli} uses Scala version 3---you can find the version
+ − 557
number in the welcome message. Also note that at the first time
+ − 558
\texttt{scala-cli} runs, it might download various components, for
+ − 559
example the Scala compiler, Scala runtimes etc. Once
+ − 560
\texttt{scala-cli} is up and running, you can type at the prompt
+ − 561
expressions like \code{2 + 3}\;\keys{Ret} and the output will be
123
+ − 562
470
+ − 563
\begin{lstlisting}[numbers=none,language={}]
123
+ − 564
scala> 2 + 3
470
+ − 565
val res0: Int = 5
123
+ − 566
\end{lstlisting}
+ − 567
188
+ − 568
\noindent The answer means that he result of the addition is of type
492
+ − 569
\code{Int} and the actual result is 5; \code{res0} is a name that
125
+ − 570
Scala gives automatically to the result. You can reuse this name later
188
+ − 571
on, for example
181
+ − 572
470
+ − 573
\begin{lstlisting}[numbers=none,language={}]
181
+ − 574
scala> res0 + 4
470
+ − 575
val res1: Int = 9
181
+ − 576
\end{lstlisting}
+ − 577
+ − 578
\noindent
+ − 579
Another classic example you can try out is
123
+ − 580
470
+ − 581
\begin{lstlisting}[numbers=none,language={}]
471
+ − 582
scala> println("hello world")
123
+ − 583
hello world
+ − 584
\end{lstlisting}
+ − 585
492
+ − 586
\noindent Note that in this case there is no result! The
471
+ − 587
reason is that \code{println} does not actually produce a result
124
+ − 588
(there is no \code{resX} and no type), rather it is a
123
+ − 589
function that causes the \emph{side-effect} of printing out a
+ − 590
string. Once you are more familiar with the functional
+ − 591
programming-style, you will know what the difference is
+ − 592
between a function that returns a result, like addition, and a
471
+ − 593
function that causes a side-effect, like \code{println}. We
123
+ − 594
shall come back to this point later, but if you are curious
+ − 595
now, the latter kind of functions always has \code{Unit} as
492
+ − 596
return type. It is just not printed by Scala.
123
+ − 597
471
+ − 598
You can try more examples with the \texttt{scala-cli} REPL, but feel free to
181
+ − 599
first guess what the result is (not all answers by Scala are obvious):
123
+ − 600
471
+ − 601
\begin{lstlisting}[numbers=none,language={}]
123
+ − 602
scala> 2 + 2
+ − 603
scala> 1 / 2
+ − 604
scala> 1.0 / 2
+ − 605
scala> 1 / 2.0
+ − 606
scala> 1 / 0
+ − 607
scala> 1.0 / 0.0
+ − 608
scala> true == false
+ − 609
scala> true && false
+ − 610
scala> 1 > 1.0
+ − 611
scala> "12345".length
181
+ − 612
scala> List(1,2,1).size
+ − 613
scala> Set(1,2,1).size
265
+ − 614
scala> List(1) == List(1)
+ − 615
scala> Array(1) == Array(1)
+ − 616
scala> Array(1).sameElements(Array(1))
492
+ − 617
scala> 0.1 + 0.2 == 0.3
335
+ − 618
\end{lstlisting}
+ − 619
+ − 620
\noindent
492
+ − 621
If you think Scala's answer in the last line is braindamaged, try the
+ − 622
same in your own favourite language.
+ − 623
Also observe carefully what Scala responds in the following
+ − 624
three instances involving the constant \lstinline!1!---can
335
+ − 625
you explain the differences?
+ − 626
+ − 627
+ − 628
\begin{lstlisting}[numbers=none]
+ − 629
scala> 1
+ − 630
scala> 1L
+ − 631
scala> 1F
181
+ − 632
\end{lstlisting}\smallskip
123
+ − 633
335
+ − 634
+ − 635
181
+ − 636
\noindent
+ − 637
Please take the Scala REPL seriously: If you want to take advantage of my
+ − 638
reference implementation for the assignments, you will need to be
+ − 639
able to ``play around'' with it!
+ − 640
+ − 641
\subsection*{Standalone Scala Apps}
123
+ − 642
277
+ − 643
If you want to write a standalone app in Scala, you can
471
+ − 644
implement a function \texttt{hello} and annotate the tag
+ − 645
\texttt{@main}. For example write
123
+ − 646
+ − 647
\begin{lstlisting}[numbers=none]
492
+ − 648
@main
471
+ − 649
def Hello() = println("hello world")
123
+ − 650
\end{lstlisting}
+ − 651
471
+ − 652
%object Hello extends App {
+ − 653
% println("hello world")
+ − 654
%}
+ − 655
197
+ − 656
\noindent save it in a file, say {\tt hello-world.scala}, and
492
+ − 657
then use \texttt{scala-cli} (which compiles the
471
+ − 658
scala file and runs it):
123
+ − 659
+ − 660
\begin{lstlisting}[language={},numbers=none,basicstyle=\ttfamily\small]
492
+ − 661
$ scala-cli hello-world.scala
123
+ − 662
hello world
+ − 663
\end{lstlisting}
+ − 664
124
+ − 665
\noindent
123
+ − 666
Like Java, Scala targets the JVM and consequently
+ − 667
Scala programs can also be executed by the bog-standard Java
471
+ − 668
Runtime. This can be done as follows:
123
+ − 669
+ − 670
\begin{lstlisting}[language={},numbers=none,basicstyle=\ttfamily\small]
471
+ − 671
$ scala-cli --power package --assembly hello-world.scala
+ − 672
$ java -jar Hello.jar
123
+ − 673
hello world
+ − 674
\end{lstlisting}
+ − 675
+ − 676
+ − 677
\subsection*{Values}
+ − 678
470
+ − 679
\begin{tcolorbox}[colback=red!5!white,colframe=red!75!black]
+ − 680
Do not use \code{var} in your code for PEP! This declares a mutable variable.
492
+ − 681
Only use \code{val}! This is for \emph{immutable} values.
+ − 682
\end{tcolorbox}\medskip
470
+ − 683
+ − 684
\noindent
124
+ − 685
In the lectures I will try to avoid as much as possible the term
+ − 686
\emph{variables} familiar from other programming languages. The reason
+ − 687
is that Scala has \emph{values}, which can be seen as abbreviations of
485
+ − 688
potentially larger expressions. The keyword for defining values is \code{val}.
271
+ − 689
For example
123
+ − 690
+ − 691
\begin{lstlisting}[numbers=none]
+ − 692
scala> val x = 42
470
+ − 693
val x: Int = 42
123
+ − 694
+ − 695
scala> val y = 3 + 4
470
+ − 696
val y: Int = 7
123
+ − 697
+ − 698
scala> val z = x / y
470
+ − 699
val z: Int = 6
123
+ − 700
\end{lstlisting}
+ − 701
+ − 702
\noindent
492
+ − 703
As can be seen, we first define \code{x} and \code{y} with admittedly some silly
271
+ − 704
expressions, and then reuse these values in the definition of \code{z}.
272
+ − 705
All easy, right? Why the kerfuffle about values? Well, values are
271
+ − 706
\emph{immutable}. You cannot change their value after you defined them.
+ − 707
If you try to reassign \code{z} above, Scala will yell at you:
123
+ − 708
+ − 709
\begin{lstlisting}[numbers=none]
+ − 710
scala> z = 9
470
+ − 711
-- [E052] Type Error: -----------------------------------
+ − 712
1 |z = 9
+ − 713
|^^^^^
+ − 714
|Reassignment to val z
+ − 715
| ...
+ − 716
1 error found
123
+ − 717
\end{lstlisting}
+ − 718
+ − 719
\noindent
+ − 720
So it would be a bit absurd to call values as variables...you cannot
195
+ − 721
change them; they cannot vary. You might think you can reassign them like
123
+ − 722
+ − 723
\begin{lstlisting}[numbers=none]
+ − 724
scala> val x = 42
+ − 725
scala> val z = x / 7
+ − 726
scala> val x = 70
492
+ − 727
scala> println(z)
123
+ − 728
\end{lstlisting}
+ − 729
492
+ − 730
\noindent but try to guess what Scala will print out
123
+ − 731
for \code{z}? Will it be \code{6} or \code{10}? A final word about
+ − 732
values: Try to stick to the convention that names of values should be
188
+ − 733
lower case, like \code{x}, \code{y}, \code{foo41} and so on. Upper-case
492
+ − 734
names you should reserve for what is called \emph{constructors}. And
271
+ − 735
forgive me when I call values as variables\ldots{}it is just something that
492
+ − 736
has been in imprinted into my developer-DNA during my early years and
+ − 737
is difficult to get rid of.~\texttt{;o)}
123
+ − 738
+ − 739
+ − 740
\subsection*{Function Definitions}
+ − 741
181
+ − 742
We do functional programming! So defining functions will be our main occupation.
492
+ − 743
As an example, a function named \code{f} taking a single argument of type
181
+ − 744
\code{Int} can be defined in Scala as follows:
123
+ − 745
+ − 746
\begin{lstlisting}[numbers=none]
492
+ − 747
def f(x: Int) : String = ...YOUR CODE...
+ − 748
\end{lstlisting}
123
+ − 749
+ − 750
\noindent
124
+ − 751
This function returns the value resulting from evaluating the expression
492
+ − 752
what your code is. Since we declared
+ − 753
\code{String} after the colon, the result of this function will be of type
271
+ − 754
\code{String}. It is a good habit to always include this information
272
+ − 755
about the return type, while it is only strictly necessary to give this
485
+ − 756
type in recursive functions (later more on that). Simple examples of Scala functions are:
123
+ − 757
+ − 758
\begin{lstlisting}[numbers=none]
+ − 759
def incr(x: Int) : Int = x + 1
+ − 760
def double(x: Int) : Int = x + x
+ − 761
def square(x: Int) : Int = x * x
+ − 762
\end{lstlisting}
+ − 763
+ − 764
\noindent
485
+ − 765
The general scheme for functions is
123
+ − 766
+ − 767
\begin{lstlisting}[numbers=none]
+ − 768
def fname(arg1: ty1, arg2: ty2,..., argn: tyn): rty = {
492
+ − 769
...BODY_OF_FUNCTION...
123
+ − 770
}
+ − 771
\end{lstlisting}
+ − 772
+ − 773
\noindent
492
+ − 774
where each argument, \texttt{arg1}, \texttt{arg2} and so on, requires
197
+ − 775
its type and the result type of the
+ − 776
function, \code{rty}, should also be given. If the body of the function is
470
+ − 777
more complex, then it can be enclosed in braces, like above. If it
124
+ − 778
is just a simple expression, like \code{x + 1}, you can omit the
195
+ − 779
braces. Very often functions are recursive (that is call themselves),
+ − 780
like the venerable factorial function:
123
+ − 781
+ − 782
\begin{lstlisting}[numbers=none]
492
+ − 783
def fact(n: Int) : Int =
123
+ − 784
if (n == 0) 1 else n * fact(n - 1)
+ − 785
\end{lstlisting}
188
+ − 786
+ − 787
\noindent
492
+ − 788
In this case we have to give the return type \code{Int}. But as said, it is a good
+ − 789
habit to give the return type for all functions. Note we could also
470
+ − 790
have written this with braces as
271
+ − 791
+ − 792
\begin{lstlisting}[numbers=none]
+ − 793
def fact(n: Int) : Int = {
492
+ − 794
if (n == 0) 1
271
+ − 795
else n * fact(n - 1)
492
+ − 796
}
271
+ − 797
\end{lstlisting}
+ − 798
+ − 799
\noindent
272
+ − 800
but this seems a bit overkill for a small function like \code{fact}.
471
+ − 801
Notice that I did not use a \code{then}-keyword in the
+ − 802
\code{if}-statements and that I enclosed the condition inside
+ − 803
parentheses, like \code{(n == 0)}. Your eyes might hurt to not see an
485
+ − 804
\code{then} with an \code{if}, but this has been long established
471
+ − 805
syntax for \code{if}-statements. Scala, to my knowledge, was pretty
+ − 806
unique in that for nearly 20 years of its existence\ldots{}until Scala
+ − 807
3 came along. While people like me have perfectly adapted to the sight
+ − 808
of \code{if}s without \code{then}s, it seems the developers of Scala
492
+ − 809
caved in to the special eyesight of Gen-Python people (I am sure that is not you) and now allow to
471
+ − 810
write the same function also as
+ − 811
+ − 812
\begin{lstlisting}[numbers=none]
+ − 813
def fact(n: Int) : Int = {
492
+ − 814
if n == 0 then 1
471
+ − 815
else n * fact(n - 1)
492
+ − 816
}
471
+ − 817
\end{lstlisting}
+ − 818
+ − 819
\noindent
492
+ − 820
The main difference between both versions is that if you want to drop the \code{then}, then you need to
+ − 821
enclose the boolean expression within parentheses.
+ − 822
I accept the second version might look a bit more familiar to beginners of Scala, if
+ − 823
they come from other languages, like Python, Java or C++. But that we also had
471
+ − 824
to get rid in Scala 3 of the familiar \texttt{\{\}}-parentheses is
+ − 825
completely beyond me. So in Scala 3 the braces are optional and the
+ − 826
\texttt{fact}-function can even be written as
+ − 827
+ − 828
\begin{lstlisting}[numbers=none]
492
+ − 829
def fact(n: Int) : Int =
485
+ − 830
if n == 0
492
+ − 831
then 1
471
+ − 832
else n * fact(n - 1)
+ − 833
\end{lstlisting}
+ − 834
+ − 835
\noindent on the condition that indents now become \emph{meaningful}
+ − 836
(as in Python).\raisebox{-0.7mm}{\emoji{face-vomiting}} All versions are now permitted in Scala 3. While you
+ − 837
are free to use any syntax version you want in PEP, or even mix them,
+ − 838
I will \textbf{not} show you any of my code in the newfangled
+ − 839
Pythonesque meaningful-indent-syntax. When necessary, I will always
+ − 840
use braces to indicate the beginning and end of a code block, and I
492
+ − 841
have not yet completely got used to the \code{if}s with
485
+ − 842
\code{then}s. Please forgive me for being still inconsistent with this\footnote{Scala adopted some very fine features of Python, for example string interpolations, but that we had to completely cave in to
+ − 843
the demands of Gen-Python is a bridge too far for my completely
+ − 844
insignificant opinion.
471
+ − 845
I always assumed escaping Python's dependency hell
485
+ − 846
is every software developers life goal---apparently not. \emoji{exploding-head}}
471
+ − 847
+ − 848
+ − 849
However, no matter which syntax style you adopt for \code{if}s, never
+ − 850
write an \code{if} without an \code{else}-branch! That has something
+ − 851
to do with functional programming and you will see its purpose later
+ − 852
on. Coming back to function definitions: While \code{def} is the main
335
+ − 853
mechanism for defining functions, there are a few other ways for doing
+ − 854
this. We will see some of them in the next sections.
272
+ − 855
+ − 856
Before we go on, let me explain one tricky point in function
335
+ − 857
definitions, especially in larger definitions. What does a Scala
+ − 858
function return as result? Scala has a \code{return} keyword, but it is
272
+ − 859
used for something different than in Java (and C/C++). Therefore please
+ − 860
make sure no \code{return} slips into your Scala code.
+ − 861
+ − 862
So in the absence of \code{return}, what value does a Scala function
+ − 863
actually produce? A rule-of-thumb is whatever is in the last line of the
+ − 864
function is the value that will be returned. Consider the following
+ − 865
example:\footnote{We could have written this function in just one line,
470
+ − 866
but for the sake of argument let's keep the two intermediate values.}
272
+ − 867
+ − 868
\begin{lstlisting}[numbers=none]
277
+ − 869
def average(xs: List[Int]) : Int = {
272
+ − 870
val s = xs.sum
+ − 871
val n = xs.length
+ − 872
s / n
492
+ − 873
}
272
+ − 874
\end{lstlisting}
+ − 875
+ − 876
\noindent In this example the expression \code{s / n} is in the last
+ − 877
line of the function---so this will be the result the function
+ − 878
calculates. The two lines before just calculate intermediate values.
335
+ − 879
This principle of the ``last-line'' comes in handy when you need to
+ − 880
print out values, for example, for debugging purposes. Suppose you want
492
+ − 881
rewrite the average function as
272
+ − 882
+ − 883
\begin{lstlisting}[numbers=none]
277
+ − 884
def average(xs: List[Int]) : Int = {
272
+ − 885
val s = xs.sum
+ − 886
val n = xs.length
+ − 887
val h = xs.head
+ − 888
println(s"Input $xs with first element $h")
+ − 889
s / n
492
+ − 890
}
272
+ − 891
\end{lstlisting}
+ − 892
+ − 893
\noindent
470
+ − 894
Here the function still only returns the expression \code{s / n} in
+ − 895
the last line. The \code{println} before just prints out some
+ − 896
information about the input of this function, but does not contribute
+ − 897
to the result of the function. Similarly, the value \code{h} is used
+ − 898
in the \code{println} but does not contribute to what integer is
+ − 899
returned by the function.
335
+ − 900
+ − 901
A caveat is that the idea with the ``last line'' is only a rough
+ − 902
rule-of-thumb. A better rule might be: the last expression that is
+ − 903
evaluated in the function. Consider the following version of
+ − 904
\code{average}:
272
+ − 905
+ − 906
\begin{lstlisting}[numbers=none]
277
+ − 907
def average(xs: List[Int]) : Int = {
272
+ − 908
if (xs.length == 0) 0
+ − 909
else xs.sum / xs.length
492
+ − 910
}
272
+ − 911
\end{lstlisting}
+ − 912
+ − 913
\noindent
335
+ − 914
What does this function return? Well there are two possibilities: either
+ − 915
the result of \code{xs.sum / xs.length} in the last line provided the
+ − 916
list \code{xs} is nonempty, \textbf{or} if the list is empty, then it
+ − 917
will return \code{0} from the \code{if}-branch (which is technically not
+ − 918
the last line, but the last expression evaluated by the function in the
272
+ − 919
empty-case).
+ − 920
+ − 921
Summing up, do not use \code{return} in your Scala code! A function
+ − 922
returns what is evaluated by the function as the last expression. There
+ − 923
is always only one such last expression. Previous expressions might
277
+ − 924
calculate intermediate values, but they are not returned. If your
+ − 925
function is supposed to return multiple things, then one way in Scala is
+ − 926
to use tuples. For example returning the minimum, average and maximum
+ − 927
can be achieved by
271
+ − 928
277
+ − 929
\begin{lstlisting}[numbers=none]
+ − 930
def avr_minmax(xs: List[Int]) : (Int, Int, Int) = {
+ − 931
if (xs.length == 0) (0, 0, 0)
+ − 932
else (xs.min, xs.sum / xs.length, xs.max)
492
+ − 933
}
277
+ − 934
\end{lstlisting}
+ − 935
+ − 936
\noindent
492
+ − 937
which still satisfies the rule-of-thumb: The result of the function is the
+ − 938
last expression that is run inside the function.
277
+ − 939
470
+ − 940
\begin{tcolorbox}[colback=red!5!white,colframe=red!75!black]
+ − 941
Do not use \code{return} in your code to indicate what a function
+ − 942
produces as a result! It has a different meaning in Scala than in
+ − 943
Java. It can change the meaning of your program, and you should
+ − 944
never use it.
+ − 945
\end{tcolorbox}
+ − 946
277
+ − 947
+ − 948
\subsection*{Loops, or Better the Absence Thereof}
123
+ − 949
272
+ − 950
Coming from Java or C/C++, you might be surprised that Scala does
123
+ − 951
not really have loops. It has instead, what is in functional
+ − 952
programming called, \emph{maps}. To illustrate how they work,
+ − 953
let us assume you have a list of numbers from 1 to 8 and want to
492
+ − 954
build the list of corresponding squares. The list of numbers from 1 to 8
123
+ − 955
can be constructed in Scala as follows:
+ − 956
470
+ − 957
\begin{lstlisting}[numbers=none,language={}]
123
+ − 958
scala> (1 to 8).toList
470
+ − 959
val res1: List[Int] = List(1, 2, 3, 4, 5, 6, 7, 8)
123
+ − 960
\end{lstlisting}
+ − 961
492
+ − 962
\noindent Like in modern versions of Java, the \code{1 to 8} generates a \code{Range}, which is then
+ − 963
transformed into a list by the \code{.toList}.
+ − 964
Generating from this list the list of
+ − 965
squares in an imperative programming language such as C++, you would assume
197
+ − 966
the list is given as a kind of array. You would then iterate, or loop,
123
+ − 967
an index over this array and replace each entry in the array
492
+ − 968
by its square. Right? In Scala, and in other functional
+ − 969
programming languages, you use maps to achieve the same.
123
+ − 970
272
+ − 971
A map essentially takes a function that describes how each element is
+ − 972
transformed (in this example the function is $n \rightarrow n * n$) and
+ − 973
a list over which this function should work. Pictorially you can think
+ − 974
of the idea behind maps as follows:
+ − 975
+ − 976
\begin{center}
+ − 977
\begin{tikzpicture}
492
+ − 978
272
+ − 979
\node (A0) at (1.2,0) {\texttt{List(}};
+ − 980
\node (A1) at (2.0,0) {\texttt{1\makebox[0mm]{ ,}}};
+ − 981
\node (A2) at (2.9,0) {\texttt{2\makebox[0mm]{ ,}}};
+ − 982
\node (A3) at (3.8,0) {\texttt{3\makebox[0mm]{ ,}}};
+ − 983
\node (A4) at (4.7,0) {\texttt{4\makebox[0mm]{ ,}}};
+ − 984
\node (A5) at (5.6,0) {\texttt{5\makebox[0mm]{ ,}}};
+ − 985
\node (A6) at (6.5,0) {\texttt{6\makebox[0mm]{ ,}}};
+ − 986
\node (A7) at (7.4,0) {\texttt{7\makebox[0mm]{ ,}}};
+ − 987
\node (A8) at (8.3,0) {\texttt{8)}};
+ − 988
+ − 989
\node (B0) at (1.2,-3) {\texttt{List(}};
+ − 990
\node (B1) at (2.0,-3) {\texttt{1\makebox[0mm]{ ,}}};
+ − 991
\node (B2) at (3.0,-3) {\texttt{4\makebox[0mm]{ ,}}};
+ − 992
\node (B3) at (4.1,-3) {\texttt{9\makebox[0mm]{ ,}}};
+ − 993
\node (B4) at (5.2,-3) {\texttt{16\makebox[0mm]{ ,}}};
+ − 994
\node (B5) at (6.3,-3) {\texttt{25\makebox[0mm]{ ,}}};
+ − 995
\node (B6) at (7.4,-3) {\texttt{36\makebox[0mm]{ ,}}};
+ − 996
\node (B7) at (8.4,-3) {\texttt{49\makebox[0mm]{ ,}}};
+ − 997
\node (B8) at (9.4,-3) {\texttt{64\makebox[0mm]{ )}}};
+ − 998
+ − 999
\draw [->,line width=1mm] (A1.south) -- (B1.north);
+ − 1000
\draw [->,line width=1mm] (A2.south) -- (B2.north);
+ − 1001
\draw [->,line width=1mm] (A3.south) -- (B3.north);
+ − 1002
\draw [->,line width=1mm] (A4.south) -- (B4.north);
+ − 1003
\draw [->,line width=1mm] (A5.south) -- (B5.north);
+ − 1004
\draw [->,line width=1mm] (A6.south) -- (B6.north);
+ − 1005
\draw [->,line width=1mm] (A7.south) -- (B7.north);
+ − 1006
\draw [->,line width=1mm] (A8.south) -- (B8.north);
+ − 1007
492
+ − 1008
\node [red] (Q0) at (-0.3,-0.3) {\large\texttt{n}};
277
+ − 1009
\node (Q1) at (-0.3,-0.4) {};
+ − 1010
\node (Q2) at (-0.3,-2.5) {};
+ − 1011
\node [red] (Q3) at (-0.3,-2.65) {\large\texttt{n\,*\,n}};
272
+ − 1012
\draw [->,red,line width=1mm] (Q1.south) -- (Q2.north);
+ − 1013
+ − 1014
\node [red] at (-1.3,-1.5) {\huge{}\it\textbf{map}};
+ − 1015
\end{tikzpicture}
+ − 1016
\end{center}
+ − 1017
+ − 1018
\noindent
+ − 1019
On top is the ``input'' list we want to transform; on the left is the
+ − 1020
``map'' function for how to transform each element in the input list
+ − 1021
(the square function in this case); at the bottom is the result list of
277
+ − 1022
the map. This means that a map generates a \emph{new} list, unlike a
273
+ − 1023
for-loop in Java or C/C++ which would most likely just update the
277
+ − 1024
existing list/array.
272
+ − 1025
277
+ − 1026
Now there are two ways for expressing such maps in Scala. The first way is
272
+ − 1027
called a \emph{for-comprehension}. The keywords are \code{for} and
+ − 1028
\code{yield}. Squaring the numbers from 1 to 8 with a for-comprehension
123
+ − 1029
would look as follows:
+ − 1030
+ − 1031
\begin{lstlisting}[numbers=none]
+ − 1032
scala> for (n <- (1 to 8).toList) yield n * n
470
+ − 1033
val res2: List[Int] = List(1, 4, 9, 16, 25, 36, 49, 64)
123
+ − 1034
\end{lstlisting}
+ − 1035
272
+ − 1036
\noindent This for-comprehension states that from the list of numbers
277
+ − 1037
we draw some elements. We use the name \code{n} to range over these
+ − 1038
elements (whereby the name is arbitrary; we could use something more
+ − 1039
descriptive if we wanted to). Using \code{n} we compute the result of
+ − 1040
\code{n * n} after the \code{yield}. This way of writing a map resembles
+ − 1041
a bit the for-loops from imperative languages, even though the ideas
+ − 1042
behind for-loops and for-comprehensions are quite different. Also, this
+ − 1043
is a simple example---what comes after \code{yield} can be a complex
+ − 1044
expression enclosed in \texttt{\{...\}}. A more complicated example
+ − 1045
might be
272
+ − 1046
+ − 1047
\begin{lstlisting}[numbers=none]
+ − 1048
scala> for (n <- (1 to 8).toList) yield {
+ − 1049
val i = n + 1
+ − 1050
val j = n - 1
273
+ − 1051
i * j + 1
272
+ − 1052
}
470
+ − 1053
val res3: List[Int] = List(1, 4, 9, 16, 25, 36, 49, 64)
272
+ − 1054
\end{lstlisting}
+ − 1055
492
+ − 1056
Let us come back to the simple example of squaring a list of numbers from above.
+ − 1057
As you can see in the for-comprehensions, we specified the list
470
+ − 1058
where each \code{n} comes from, namely \code{(1 to 8).toList}, and how
+ − 1059
each element needs to be transformed, the expression after the
+ − 1060
\code{yield}. This can also be expressed in a second way in Scala by
+ − 1061
using directly the function \code{map} as follows:
123
+ − 1062
470
+ − 1063
\begin{lstlisting}[numbers=none,language={}]
123
+ − 1064
scala> (1 to 8).toList.map(n => n * n)
470
+ − 1065
val res3 = List(1, 4, 9, 16, 25, 36, 49, 64)
123
+ − 1066
\end{lstlisting}
+ − 1067
272
+ − 1068
\noindent In this way, the expression \code{n => n * n} stands for the
+ − 1069
function that calculates the square (this is how the \code{n}s are
+ − 1070
transformed by the map). It might not be obvious, but
277
+ − 1071
the for-comprehensions above are just syntactic sugar: when compiling such
273
+ − 1072
code, Scala translates for-comprehensions into equivalent maps. This
+ − 1073
even works when for-comprehensions get more complicated (see below).
123
+ − 1074
+ − 1075
The very charming feature of Scala is that such maps or
272
+ − 1076
for-comprehensions can be written for any kind of data collection, such
+ − 1077
as lists, sets, vectors, options and so on. For example if we instead
+ − 1078
compute the remainders modulo 3 of this list, we can write
123
+ − 1079
470
+ − 1080
\begin{lstlisting}[numbers=none,language={}]
123
+ − 1081
scala> (1 to 8).toList.map(n => n % 3)
470
+ − 1082
val res4 = List(1, 2, 0, 1, 2, 0, 1, 2)
123
+ − 1083
\end{lstlisting}
+ − 1084
+ − 1085
\noindent If we, however, transform the numbers 1 to 8 not
270
Christian Urban <christian dot urban at kcl dot ac dot uk>
diff
changeset
+ − 1086
into a list, but into a set, and then compute the remainders
123
+ − 1087
modulo 3 we obtain
+ − 1088
470
+ − 1089
\begin{lstlisting}[numbers=none,language={}]
+ − 1090
scala> (1 to 8).toSet.map(n => n % 3)
+ − 1091
val res5 = Set(2, 1, 0)
123
+ − 1092
\end{lstlisting}
+ − 1093
470
+ − 1094
\noindent This\footnote{This returns actually \code{HashSet(1, 2, 3)},
301
+ − 1095
but this is just an implementation detail of how sets are implemented in
+ − 1096
Scala.} is the correct result for sets, as there are only three
470
+ − 1097
equivalence classes of integers modulo 3. Since maps and
301
+ − 1098
for-comprehensions are just syntactic variants of each other, the latter
+ − 1099
can also be written as
123
+ − 1100
492
+ − 1101
\begin{lstlisting}[numbers=none,language={}]
470
+ − 1102
scala> for (n <- (1 to 8).toSet) yield n % 3
+ − 1103
val res5 = Set(2, 1, 0)
123
+ − 1104
\end{lstlisting}
+ − 1105
492
+ − 1106
For-comprehensions can also be nested and the selection of
470
+ − 1107
elements can be guarded (or filtered). For example if we want to pair up
123
+ − 1108
the numbers 1 to 4 with the letters a to c, we can write
+ − 1109
+ − 1110
\begin{lstlisting}[numbers=none]
492
+ − 1111
scala> for (n <- (1 to 4).toList;
123
+ − 1112
m <- ('a' to 'c').toList) yield (n, m)
492
+ − 1113
val res6 = List((1,a), (1,b), (1,c), (2,a), (2,b), (2,c),
470
+ − 1114
(3,a), (3,b), (3,c), (4,a), (4,b), (4,c))
123
+ − 1115
\end{lstlisting}
+ − 1116
492
+ − 1117
\noindent
272
+ − 1118
In this example the for-comprehension ranges over two lists, and
277
+ − 1119
produces a list of pairs as output. Or, if we want to find all pairs of
272
+ − 1120
numbers between 1 and 3 where the sum is an even number, we can write
123
+ − 1121
+ − 1122
\begin{lstlisting}[numbers=none]
492
+ − 1123
scala> for (n <- (1 to 3).toList;
123
+ − 1124
m <- (1 to 3).toList;
+ − 1125
if (n + m) % 2 == 0) yield (n, m)
470
+ − 1126
val res7 = List((1,1), (1,3), (2,2), (3,1), (3,3))
123
+ − 1127
\end{lstlisting}
+ − 1128
272
+ − 1129
\noindent The \code{if}-condition in this for-comprehension filters out
277
+ − 1130
all pairs where the sum is not even (therefore \code{(1, 2)}, \code{(2,
492
+ − 1131
1)} and \code{(3, 2)} are not in the result because their sum is odd).
272
+ − 1132
278
+ − 1133
To summarise, maps (or for-comprehensions) transform one collection into
273
+ − 1134
another. For example a list of \code{Int}s into a list of squares, and
+ − 1135
so on. There is no need for for-loops in Scala. But please do not be
+ − 1136
tempted to write anything like
272
+ − 1137
+ − 1138
\begin{lstlisting}[numbers=none]
+ − 1139
scala> val cs = ('a' to 'h').toList
492
+ − 1140
scala> for (n <- (0 until cs.length).toList)
272
+ − 1141
yield cs(n).capitalize
470
+ − 1142
val res8: List[Char] = List(A, B, C, D, E, F, G, H)
272
+ − 1143
\end{lstlisting}
+ − 1144
+ − 1145
\noindent
277
+ − 1146
This is accepted Scala-code, but utterly bad style (it is more like
+ − 1147
Java). It can be written much clearer as:
272
+ − 1148
+ − 1149
\begin{lstlisting}[numbers=none]
+ − 1150
scala> val cs = ('a' to 'h').toList
+ − 1151
scala> for (c <- cs) yield c.capitalize
470
+ − 1152
val res9: List[Char] = List(A, B, C, D, E, F, G, H)
272
+ − 1153
\end{lstlisting}
123
+ − 1154
271
+ − 1155
\subsection*{Results and Side-Effects}
+ − 1156
301
+ − 1157
While hopefully all this about maps looks reasonable, there is one
273
+ − 1158
complication: In the examples above we always wanted to transform one
+ − 1159
list into another list (e.g.~list of squares), or one set into another
+ − 1160
set (set of numbers into set of remainders modulo 3). What happens if we
+ − 1161
just want to print out a list of integers? In these cases the
+ − 1162
for-comprehensions need to be modified. The reason is that \code{print},
+ − 1163
you guessed it, does not produce any result, but only produces what is
+ − 1164
in the functional-programming-lingo called a \emph{side-effect}\ldots it
+ − 1165
prints something out on the screen. Printing out the list of numbers
+ − 1166
from 1 to 5 would look as follows
123
+ − 1167
+ − 1168
\begin{lstlisting}[numbers=none]
+ − 1169
scala> for (n <- (1 to 5).toList) print(n)
+ − 1170
12345
+ − 1171
\end{lstlisting}
+ − 1172
+ − 1173
\noindent
+ − 1174
where you need to omit the keyword \code{yield}. You can
492
+ − 1175
also do more elaborate calculations before printing such as
123
+ − 1176
+ − 1177
\begin{lstlisting}[numbers=none]
+ − 1178
scala> for (n <- (1 to 5).toList) {
197
+ − 1179
val square = n * n
492
+ − 1180
println(s"$n * $n = $square")
123
+ − 1181
}
+ − 1182
1 * 1 = 1
+ − 1183
2 * 2 = 4
+ − 1184
3 * 3 = 9
+ − 1185
4 * 4 = 16
+ − 1186
5 * 5 = 25
+ − 1187
\end{lstlisting}%$
+ − 1188
301
+ − 1189
\noindent In this code I use a value assignment (\code{val
197
+ − 1190
square = ...} ) and also what is called in Scala a
123
+ − 1191
\emph{string interpolation}, written \code{s"..."}. The latter
470
+ − 1192
is for printing out formatted strings. It allows me to refer to the
270
Christian Urban <christian dot urban at kcl dot ac dot uk>
diff
changeset
+ − 1193
integer values \code{n} and \code{square} inside a string.
492
+ − 1194
This is very convenient for printing out ``things''.
123
+ − 1195
492
+ − 1196
The corresponding map construction for functions with
+ − 1197
side-effects is in Scala called \code{foreach}. So you
123
+ − 1198
could also write
+ − 1199
+ − 1200
+ − 1201
\begin{lstlisting}[numbers=none]
+ − 1202
scala> (1 to 5).toList.foreach(n => print(n))
+ − 1203
12345
+ − 1204
\end{lstlisting}
+ − 1205
+ − 1206
+ − 1207
\noindent or even just
+ − 1208
+ − 1209
\begin{lstlisting}[numbers=none]
+ − 1210
scala> (1 to 5).toList.foreach(print)
+ − 1211
12345
+ − 1212
\end{lstlisting}
+ − 1213
492
+ − 1214
\noindent
123
+ − 1215
If you want to find out more about maps and functions with
+ − 1216
side-effects, you can ponder about the response Scala gives if
+ − 1217
you replace \code{foreach} by \code{map} in the expression
+ − 1218
above. Scala will still allow \code{map} with side-effect
+ − 1219
functions, but then reacts with a slightly interesting result.
492
+ − 1220
If you understand the difference, you are pretty much on the
+ − 1221
road of becoming a master-functional programmer.
123
+ − 1222
273
+ − 1223
\subsection*{Aggregates}
+ − 1224
+ − 1225
There is one more usage of for-loops in Java, C/C++ and the like:
+ − 1226
sometimes you want to \emph{aggregate} something about a list, for
278
+ − 1227
example summing up all its elements. In this case you cannot use maps,
273
+ − 1228
because maps \emph{transform} one data collection into another data
+ − 1229
collection. They cannot be used to generate a single integer
278
+ − 1230
representing an aggregate. So how is this kind of aggregation done in
+ − 1231
Scala? Let us suppose you want to sum up all elements from a list. You
+ − 1232
might be tempted to write something like
273
+ − 1233
+ − 1234
\begin{lstlisting}[numbers=none]
+ − 1235
var cnt = 0
+ − 1236
for (n <- (1 to 8).toList) {
+ − 1237
cnt += n
+ − 1238
}
+ − 1239
print(cnt)
+ − 1240
\end{lstlisting}
+ − 1241
+ − 1242
\noindent
277
+ − 1243
and indeed this is accepted Scala code and produces the expected result,
273
+ − 1244
namely \code{36}, \textbf{BUT} this is imperative style and not
301
+ − 1245
permitted in PEP. If you submit this kind of code, you get 0 marks. The
+ − 1246
code uses a \code{var} and therefore violates the immutability property
+ − 1247
I ask for in your code. Sorry!
273
+ − 1248
+ − 1249
So how to do that same thing without using a \code{var}? Well there are
+ − 1250
several ways. One way is to define the following recursive
+ − 1251
\code{sum}-function:
+ − 1252
+ − 1253
\begin{lstlisting}[numbers=none]
492
+ − 1254
def sum(xs: List[Int]) : Int =
273
+ − 1255
if (xs.isEmpty) 0 else xs.head + sum(xs.tail)
492
+ − 1256
\end{lstlisting}
273
+ − 1257
+ − 1258
\noindent
+ − 1259
You can then call \code{sum((1 to 8).toList)} and obtain the same result
278
+ − 1260
without a mutable variable and without a for-loop. Obviously for simple things like
277
+ − 1261
sum, you could have written \code{xs.sum} in the first place. But not
+ − 1262
all aggregate functions are pre-defined and often you have to write your
+ − 1263
own recursive function for this.
273
+ − 1264
352
+ − 1265
%\subsection*{Always Produce a Result! No Exceptions!}
329
+ − 1266
%
+ − 1267
%Function should always produce a value. Exception is not thrown.
+ − 1268
%Whenever there is a possibility of non-value result (exception, void,
+ − 1269
%undefined, null, etc.), it should be incorporated in the result type.
+ − 1270
%Such types include but not limited to
+ − 1271
%
+ − 1272
%Option[T]
+ − 1273
352
+ − 1274
%TBD
334
+ − 1275
329
+ − 1276
271
+ − 1277
\subsection*{Higher-Order Functions}
+ − 1278
301
+ − 1279
Functions obviously play a central role in functional programming. Two simple
+ − 1280
examples are
+ − 1281
+ − 1282
\begin{lstlisting}[numbers=none]
+ − 1283
def even(x: Int) : Boolean = x % 2 == 0
+ − 1284
def odd(x: Int) : Boolean = x % 2 == 1
492
+ − 1285
\end{lstlisting}
301
+ − 1286
+ − 1287
\noindent
+ − 1288
More interestingly, the concept of functions is really pushed to the
+ − 1289
limit in functional programming. Functions can take other functions as
+ − 1290
arguments and can return a function as a result. This is actually
+ − 1291
quite important for making code generic. Assume a list of 10 elements:
+ − 1292
+ − 1293
\begin{lstlisting}[numbers=none]
492
+ − 1294
val lst = (1 to 10).toList
+ − 1295
\end{lstlisting}
301
+ − 1296
492
+ − 1297
\noindent
+ − 1298
Say, we want to filter out all even numbers. For this we can use
301
+ − 1299
+ − 1300
\begin{lstlisting}[numbers=none]
+ − 1301
scala> lst.filter(even)
+ − 1302
List(2, 4, 6, 8, 10)
492
+ − 1303
\end{lstlisting}
301
+ − 1304
+ − 1305
\noindent
+ − 1306
where \code{filter} expects a function as argument specifying which
+ − 1307
elements of the list should be kept and which should be left out. By
+ − 1308
allowing \code{filter} to take a function as argument, we can also
+ − 1309
easily filter out odd numbers as well.
+ − 1310
+ − 1311
\begin{lstlisting}[numbers=none]
+ − 1312
scala> lst.filter(odd)
+ − 1313
List(1, 3, 5, 7, 9)
492
+ − 1314
\end{lstlisting}
301
+ − 1315
+ − 1316
\noindent
+ − 1317
Such function arguments are quite frequently used for ``generic'' functions.
+ − 1318
For example it is easy to count odd elements in a list or find the first
+ − 1319
even number in a list:
+ − 1320
+ − 1321
\begin{lstlisting}[numbers=none]
+ − 1322
scala> lst.count(odd)
+ − 1323
5
+ − 1324
scala> lst.find(even)
+ − 1325
Some(2)
492
+ − 1326
\end{lstlisting}
301
+ − 1327
+ − 1328
\noindent
+ − 1329
Recall that the return type of \code{even} and \code{odd} are booleans.
+ − 1330
Such function are sometimes called predicates, because they determine
+ − 1331
what should be true for an element and what false, and then performing
492
+ − 1332
some operation according to this boolean. Such predicates are quite useful.
+ − 1333
Say you want to sort the \code{lst}-list in ascending and descending order.
301
+ − 1334
For this you can write
+ − 1335
+ − 1336
\begin{lstlisting}[numbers=none]
+ − 1337
lst.sortWith(_ < _)
+ − 1338
lst.sortWith(_ > _)
492
+ − 1339
\end{lstlisting}
301
+ − 1340
+ − 1341
\noindent where \code{sortWith} expects a predicate as argument. The
+ − 1342
construction \code{_ < _} stands for a function that takes two arguments
+ − 1343
and returns true when the first one is smaller than the second. You can
492
+ − 1344
think of this as elegant shorthand notation for
301
+ − 1345
+ − 1346
\begin{lstlisting}[numbers=none]
+ − 1347
def smaller(x: Int, y: Int) : Boolean = x < y
+ − 1348
lst.sortWith(smaller)
492
+ − 1349
\end{lstlisting}
301
+ − 1350
+ − 1351
\noindent
+ − 1352
Say you want to find in \code{lst} the first odd number greater than 2.
+ − 1353
For this you need to write a function that specifies exactly this
+ − 1354
condition. To do this you can use a slight variant of the shorthand
+ − 1355
notation above
+ − 1356
+ − 1357
\begin{lstlisting}[numbers=none]
+ − 1358
scala> lst.find(n => odd(n) && n > 2)
+ − 1359
Some(3)
492
+ − 1360
\end{lstlisting}
301
+ − 1361
+ − 1362
\noindent
+ − 1363
Here \code{n => ...} specifies a function that takes \code{n} as
+ − 1364
argument and uses this argument in whatever comes after the double
+ − 1365
arrow. If you want to use this mechanism for looking for an element that
+ − 1366
is both even and odd, then of course you out of luck.
+ − 1367
+ − 1368
\begin{lstlisting}[numbers=none]
+ − 1369
scala> lst.find(n => odd(n) && even(n))
+ − 1370
None
492
+ − 1371
\end{lstlisting}
301
+ − 1372
+ − 1373
While functions taking functions as arguments seems a rather useful
492
+ − 1374
feature, the utility of returning a function might not be so clear.
301
+ − 1375
I admit the following example is a bit contrived, but believe me
+ − 1376
sometims functions produce other functions in a very meaningful way.
+ − 1377
Say we want to generate functions according to strings, as in
+ − 1378
+ − 1379
\begin{lstlisting}[numbers=none]
+ − 1380
def mkfn(s: String) : (Int => Boolean) =
+ − 1381
if (s == "even") even else odd
+ − 1382
\end{lstlisting}
+ − 1383
+ − 1384
\noindent
+ − 1385
With this we can generate the required function for \code{filter}
+ − 1386
according to a string:
+ − 1387
+ − 1388
\begin{lstlisting}[numbers=none]
+ − 1389
scala> lst.filter(mkfn("even"))
+ − 1390
List(2, 4, 6, 8, 10)
+ − 1391
scala> lst.filter(mkfn("foo"))
+ − 1392
List(1, 3, 5, 7, 9)
+ − 1393
\end{lstlisting}
+ − 1394
+ − 1395
\noindent
+ − 1396
As said, this is example is a bit contrived---I was not able to think
+ − 1397
of anything simple, but for example in the Compiler module next year I
+ − 1398
show a compilation functions that needs to generate functions as
+ − 1399
intermediate result. Anyway, notice the interesting type we had to
470
+ − 1400
annotate to \code{mkfn}. The types in Scala are described next.
301
+ − 1401
274
+ − 1402
123
+ − 1403
\subsection*{Types}
+ − 1404
+ − 1405
In most functional programming languages, types play an
470
+ − 1406
essential role. Scala is such a language. You have already
123
+ − 1407
seen built-in types, like \code{Int}, \code{Boolean},
+ − 1408
\code{String} and \code{BigInt}, but also user-defined ones,
195
+ − 1409
like \code{Rexp} (see coursework). Unfortunately, types can be a thorny
123
+ − 1410
subject, especially in Scala. For example, why do we need to
+ − 1411
give the type to \code{toSet[Int]}, but not to \code{toList}?
+ − 1412
The reason is the power of Scala, which sometimes means it
+ − 1413
cannot infer all necessary typing information. At the
195
+ − 1414
beginning, while getting familiar with Scala, I recommend a
123
+ − 1415
``play-it-by-ear-approach'' to types. Fully understanding
+ − 1416
type-systems, especially complicated ones like in Scala, can
+ − 1417
take a module on their own.\footnote{Still, such a study can
+ − 1418
be a rewarding training: If you are in the business of
+ − 1419
designing new programming languages, you will not be able to
+ − 1420
turn a blind eye to types. They essentially help programmers
+ − 1421
to avoid common programming errors and help with maintaining
+ − 1422
code.}
+ − 1423
+ − 1424
In Scala, types are needed whenever you define an inductive
+ − 1425
datatype and also whenever you define functions (their
+ − 1426
arguments and their results need a type). Base types are types
+ − 1427
that do not take any (type)arguments, for example \code{Int}
+ − 1428
and \code{String}. Compound types take one or more arguments,
+ − 1429
which as seen earlier need to be given in angle-brackets, for
492
+ − 1430
example \code{List[Int]} or \code{Set[List[String]]} or
123
+ − 1431
\code{Map[Int, Int]}.
+ − 1432
470
+ − 1433
Scala provides a basic mechanism to check the type of a (closed)
+ − 1434
expression---closed means that all parts are already known to Scala.
+ − 1435
Then you can use the command \code{:type} and check in the REPL:
+ − 1436
+ − 1437
\begin{lstlisting}[ numbers=none]
+ − 1438
scala> :type (1, List(3), Set(4,5), "hello")
+ − 1439
(Int, List[Int], Set[Int], String)
+ − 1440
\end{lstlisting}
+ − 1441
+ − 1442
\noindent
+ − 1443
If Scala can calculate the type of the given expression, then it
+ − 1444
will print it. Unfortunately, this way of finding out a type is almost
+ − 1445
unusable: for `things' where the type is pretty obvious, it gives an
+ − 1446
answer; but for `things' that are actually of interest (such as
+ − 1447
what is the type of a pre-defined function), it gives up with
492
+ − 1448
an error message.
470
+ − 1449
123
+ − 1450
There are a few special type-constructors that fall outside
+ − 1451
this pattern. One is for tuples, where the type is written
492
+ − 1452
with parentheses. For example
123
+ − 1453
+ − 1454
\begin{lstlisting}[ numbers=none]
+ − 1455
(Int, Int, String)
+ − 1456
\end{lstlisting}
+ − 1457
+ − 1458
\noindent is for a triple (a tuple with three components---two
+ − 1459
integers and a string). Tuples are helpful if you want to
+ − 1460
define functions with multiple results, say the function
270
Christian Urban <christian dot urban at kcl dot ac dot uk>
diff
changeset
+ − 1461
returning the quotient and remainder of two numbers. For this
123
+ − 1462
you might define:
+ − 1463
+ − 1464
+ − 1465
\begin{lstlisting}[ numbers=none]
301
+ − 1466
def quo_rem(m: Int, n: Int) : (Int, Int) =
+ − 1467
(m / n, m % n)
123
+ − 1468
\end{lstlisting}
+ − 1469
+ − 1470
\noindent Since this function returns a pair of integers, its
277
+ − 1471
\emph{return type} needs to be of type \code{(Int, Int)}. Incidentally,
+ − 1472
this is also the \emph{input type} of this function. For this notice
+ − 1473
\code{quo_rem} takes \emph{two} arguments, namely \code{m} and \code{n},
+ − 1474
both of which are integers. They are ``packaged'' in a pair.
+ − 1475
Consequently the complete type of \code{quo_rem} is
123
+ − 1476
+ − 1477
\begin{lstlisting}[ numbers=none]
+ − 1478
(Int, Int) => (Int, Int)
+ − 1479
\end{lstlisting}
+ − 1480
301
+ − 1481
\noindent
277
+ − 1482
This uses another special type-constructor, written as the arrow
301
+ − 1483
\code{=>}. This is sometimes also called \emph{function arrow}. For
+ − 1484
example, the type \code{Int => String} is for a function that takes an
+ − 1485
integer as input argument and produces a string as result. A function
+ − 1486
of this type is for instance
123
+ − 1487
+ − 1488
\begin{lstlisting}[numbers=none]
+ − 1489
def mk_string(n: Int) : String = n match {
+ − 1490
case 0 => "zero"
+ − 1491
case 1 => "one"
+ − 1492
case 2 => "two"
492
+ − 1493
case _ => "many"
+ − 1494
}
123
+ − 1495
\end{lstlisting}
+ − 1496
+ − 1497
\noindent It takes an integer as input argument and returns a
301
+ − 1498
string. The type of the function generated in \code{mkfn} above, is
+ − 1499
\code{Int => Boolean}.
277
+ − 1500
+ − 1501
Unfortunately, unlike other functional programming languages, there is
+ − 1502
in Scala no easy way to find out the types of existing functions, except
+ − 1503
by looking into the documentation
123
+ − 1504
+ − 1505
\begin{quote}
471
+ − 1506
\url{https://dotty.epfl.ch/api/index.html}
123
+ − 1507
\end{quote}
+ − 1508
492
+ − 1509
The function arrow can also be iterated, as in
123
+ − 1510
\code{Int => String => Boolean}. This is the type for a function
+ − 1511
taking an integer as first argument and a string as second,
+ − 1512
and the result of the function is a boolean. Though silly, a
+ − 1513
function of this type would be
+ − 1514
+ − 1515
+ − 1516
\begin{lstlisting}[numbers=none]
492
+ − 1517
def chk_string(n: Int)(s: String) : Boolean =
123
+ − 1518
mk_string(n) == s
+ − 1519
\end{lstlisting}
+ − 1520
+ − 1521
+ − 1522
\noindent which checks whether the integer \code{n}
+ − 1523
corresponds to the name \code{s} given by the function
+ − 1524
\code{mk\_string}. Notice the unusual way of specifying the
+ − 1525
arguments of this function: the arguments are given one after
+ − 1526
the other, instead of being in a pair (what would be the type
+ − 1527
of this function then?). This way of specifying the arguments
+ − 1528
can be useful, for example in situations like this
+ − 1529
+ − 1530
\begin{lstlisting}[numbers=none]
+ − 1531
scala> List("one", "two", "three", "many").map(chk_string(2))
+ − 1532
res4 = List(false, true, false, false)
+ − 1533
+ − 1534
scala> List("one", "two", "three", "many").map(chk_string(3))
+ − 1535
res5 = List(false, false, false, true)
+ − 1536
\end{lstlisting}
+ − 1537
+ − 1538
\noindent In each case we can give to \code{map} a specialised
+ − 1539
version of \code{chk_string}---once specialised to 2 and once
+ − 1540
to 3. This kind of ``specialising'' a function is called
+ − 1541
\emph{partial application}---we have not yet given to this
+ − 1542
function all arguments it needs, but only some of them.
+ − 1543
+ − 1544
Coming back to the type \code{Int => String => Boolean}. The
+ − 1545
rule about such function types is that the right-most type
+ − 1546
specifies what the function returns (a boolean in this case).
+ − 1547
The types before that specify how many arguments the function
+ − 1548
expects and what their type is (in this case two arguments,
+ − 1549
one of type \code{Int} and another of type \code{String}).
+ − 1550
Given this rule, what kind of function has type
+ − 1551
\mbox{\code{(Int => String) => Boolean}}? Well, it returns a
+ − 1552
boolean. More interestingly, though, it only takes a single
+ − 1553
argument (because of the parentheses). The single argument
+ − 1554
happens to be another function (taking an integer as input and
492
+ − 1555
returning a string). Remember that \code{mk_string} is just
123
+ − 1556
such a function. So how can we use it? For this define
+ − 1557
the somewhat silly function \code{apply_3}:
+ − 1558
+ − 1559
\begin{lstlisting}[numbers=none]
+ − 1560
def apply_3(f: Int => String): Bool = f(3) == "many"
+ − 1561
+ − 1562
scala> apply_3(mk_string)
+ − 1563
res6 = true
+ − 1564
\end{lstlisting}
+ − 1565
+ − 1566
You might ask: Apart from silly functions like above, what is
+ − 1567
the point of having functions as input arguments to other
470
+ − 1568
functions?
+ − 1569
%In Java there is indeed no need of this kind of
+ − 1570
%feature: at least in the past it did not allow such
+ − 1571
%constructions. I think, the point of Java 8 and successors was to lift this
+ − 1572
%restriction.
+ − 1573
Well, in all functional programming languages,
123
+ − 1574
including Scala, it is really essential to allow functions as
301
+ − 1575
input argument. Above you have already seen \code{map} and
+ − 1576
\code{foreach} which need this feature. Consider the functions
123
+ − 1577
\code{print} and \code{println}, which both print out strings,
+ − 1578
but the latter adds a line break. You can call \code{foreach}
+ − 1579
with either of them and thus changing how, for example, five
+ − 1580
numbers are printed.
+ − 1581
+ − 1582
+ − 1583
\begin{lstlisting}[numbers=none]
+ − 1584
scala> (1 to 5).toList.foreach(print)
+ − 1585
12345
+ − 1586
scala> (1 to 5).toList.foreach(println)
+ − 1587
1
+ − 1588
2
+ − 1589
3
+ − 1590
4
+ − 1591
5
+ − 1592
\end{lstlisting}
+ − 1593
+ − 1594
+ − 1595
\noindent This is actually one of the main design principles
+ − 1596
in functional programming. You have generic functions like
+ − 1597
\code{map} and \code{foreach} that can traverse data containers,
+ − 1598
like lists or sets. They then take a function to specify what
+ − 1599
should be done with each element during the traversal. This
+ − 1600
requires that the generic traversal functions can cope with
+ − 1601
any kind of function (not just functions that, for example,
+ − 1602
take as input an integer and produce a string like above).
+ − 1603
This means we cannot fix the type of the generic traversal
+ − 1604
functions, but have to keep them
181
+ − 1605
\emph{polymorphic}.\footnote{Another interesting topic about
492
+ − 1606
types, but we omit it here for the sake of brevity.}
123
+ − 1607
301
+ − 1608
There is one more type constructor that is rather special. It is
+ − 1609
called \code{Unit}. Recall that \code{Boolean} has two values, namely
+ − 1610
\code{true} and \code{false}. This can be used, for example, to test
+ − 1611
something and decide whether the test succeeds or not. In contrast the
+ − 1612
type \code{Unit} has only a single value, written \code{()}. This
+ − 1613
seems like a completely useless type and return value for a function,
+ − 1614
but is actually quite useful. It indicates when the function does not
+ − 1615
return any result. The purpose of these functions is to cause
+ − 1616
something being written on the screen or written into a file, for
+ − 1617
example. This is what is called they cause a \emph{side-effect}, for
+ − 1618
example new content displayed on the screen or some new data in a
+ − 1619
file. Scala uses the \code{Unit} type to indicate that a function does
+ − 1620
not have a result, but potentially causes a side-effect. Typical
+ − 1621
examples are the printing functions, like \code{print}.
123
+ − 1622
301
+ − 1623
+ − 1624
%%\subsection*{User-Defined Types}
123
+ − 1625
143
+ − 1626
% \subsection*{Cool Stuff}
123
+ − 1627
143
+ − 1628
% The first wow-moment I had with Scala was when I came across
492
+ − 1629
% the following code-snippet for reading a web-page.
123
+ − 1630
+ − 1631
143
+ − 1632
% \begin{lstlisting}[ numbers=none]
+ − 1633
% import io.Source
+ − 1634
% val url = """http://www.inf.kcl.ac.uk/staff/urbanc/"""
+ − 1635
% Source.fromURL(url)("ISO-8859-1").take(10000).mkString
+ − 1636
% \end{lstlisting}
123
+ − 1637
+ − 1638
143
+ − 1639
% \noindent These three lines return a string containing the
+ − 1640
% HTML-code of my webpage. It actually already does something
+ − 1641
% more sophisticated, namely only returns the first 10000
+ − 1642
% characters of a webpage in case it is too large. Why is that
+ − 1643
% code-snippet of any interest? Well, try implementing
+ − 1644
% reading-from-a-webpage in Java. I also like the possibility of
+ − 1645
% triple-quoting strings, which I have only seen in Scala so
+ − 1646
% far. The idea behind this is that in such a string all
+ − 1647
% characters are interpreted literally---there are no escaped
+ − 1648
% characters, like \verb|\n| for newlines.
123
+ − 1649
143
+ − 1650
% My second wow-moment I had with a feature of Scala that other
+ − 1651
% functional programming languages do not have. This feature is
+ − 1652
% about implicit type conversions. If you have regular
+ − 1653
% expressions and want to use them for language processing you
+ − 1654
% often want to recognise keywords in a language, for example
+ − 1655
% \code{for},{} \code{if},{} \code{yield} and so on. But the
+ − 1656
% basic regular expression \code{CHAR} can only recognise a
+ − 1657
% single character. In order to recognise a whole string, like
+ − 1658
% \code{for}, you have to put many of those together using
+ − 1659
% \code{SEQ}:
123
+ − 1660
+ − 1661
143
+ − 1662
% \begin{lstlisting}[numbers=none]
+ − 1663
% SEQ(CHAR('f'), SEQ(CHAR('o'), CHAR('r')))
+ − 1664
% \end{lstlisting}
123
+ − 1665
143
+ − 1666
% \noindent This gets quickly unreadable when the strings and
+ − 1667
% regular expressions get more complicated. In other functional
+ − 1668
% programming languages, you can explicitly write a conversion
+ − 1669
% function that takes a string, say \dq{\pcode{for}}, and
+ − 1670
% generates the regular expression above. But then your code is
+ − 1671
% littered with such conversion functions.
123
+ − 1672
143
+ − 1673
% In Scala you can do better by ``hiding'' the conversion
+ − 1674
% functions. The keyword for doing this is \code{implicit} and
492
+ − 1675
% it needs a built-in library called
123
+ − 1676
143
+ − 1677
% \begin{lstlisting}[numbers=none]
+ − 1678
% scala.language.implicitConversions
+ − 1679
% \end{lstlisting}
123
+ − 1680
143
+ − 1681
% \noindent
+ − 1682
% Consider the code
123
+ − 1683
+ − 1684
143
+ − 1685
% \begin{lstlisting}[language=Scala]
+ − 1686
% import scala.language.implicitConversions
123
+ − 1687
143
+ − 1688
% def charlist2rexp(s: List[Char]) : Rexp = s match {
+ − 1689
% case Nil => EMPTY
+ − 1690
% case c::Nil => CHAR(c)
+ − 1691
% case c::s => SEQ(CHAR(c), charlist2rexp(s))
+ − 1692
% }
123
+ − 1693
492
+ − 1694
% implicit def string2rexp(s: String) : Rexp =
143
+ − 1695
% charlist2rexp(s.toList)
+ − 1696
% \end{lstlisting}
123
+ − 1697
+ − 1698
143
+ − 1699
% \noindent where the first seven lines implement a function
+ − 1700
% that given a list of characters generates the corresponding
+ − 1701
% regular expression. In Lines 9 and 10, this function is used
+ − 1702
% for transforming a string into a regular expression. Since the
+ − 1703
% \code{string2rexp}-function is declared as \code{implicit},
+ − 1704
% the effect will be that whenever Scala expects a regular
+ − 1705
% expression, but I only give it a string, it will automatically
+ − 1706
% insert a call to the \code{string2rexp}-function. I can now
+ − 1707
% write for example
123
+ − 1708
143
+ − 1709
% \begin{lstlisting}[numbers=none]
+ − 1710
% scala> ALT("ab", "ac")
+ − 1711
% res9 = ALT(SEQ(CHAR(a),CHAR(b)),SEQ(CHAR(a),CHAR(c)))
+ − 1712
% \end{lstlisting}
123
+ − 1713
143
+ − 1714
% \noindent Recall that \code{ALT} expects two regular
+ − 1715
% expressions as arguments, but I only supply two strings. The
+ − 1716
% implicit conversion function will transform the string into a
+ − 1717
% regular expression.
123
+ − 1718
143
+ − 1719
% Using implicit definitions, Scala allows me to introduce
+ − 1720
% some further syntactic sugar for regular expressions:
123
+ − 1721
+ − 1722
143
+ − 1723
% \begin{lstlisting}[ numbers=none]
+ − 1724
% implicit def RexpOps(r: Rexp) = new {
+ − 1725
% def | (s: Rexp) = ALT(r, s)
+ − 1726
% def ~ (s: Rexp) = SEQ(r, s)
+ − 1727
% def % = STAR(r)
+ − 1728
% }
123
+ − 1729
143
+ − 1730
% implicit def stringOps(s: String) = new {
+ − 1731
% def | (r: Rexp) = ALT(s, r)
+ − 1732
% def | (r: String) = ALT(s, r)
+ − 1733
% def ~ (r: Rexp) = SEQ(s, r)
+ − 1734
% def ~ (r: String) = SEQ(s, r)
+ − 1735
% def % = STAR(s)
+ − 1736
% }
+ − 1737
% \end{lstlisting}
123
+ − 1738
492
+ − 1739
143
+ − 1740
% \noindent This might seem a bit overly complicated, but its effect is
492
+ − 1741
% that I can now write regular expressions such as $ab + ac$
143
+ − 1742
% simply as
123
+ − 1743
+ − 1744
143
+ − 1745
% \begin{lstlisting}[numbers=none]
+ − 1746
% scala> "ab" | "ac"
+ − 1747
% res10 = ALT(SEQ(CHAR(a),CHAR(b)),SEQ(CHAR(a),CHAR(c)))
+ − 1748
% \end{lstlisting}
123
+ − 1749
492
+ − 1750
143
+ − 1751
% \noindent I leave you to figure out what the other
+ − 1752
% syntactic sugar in the code above stands for.
492
+ − 1753
143
+ − 1754
% One more useful feature of Scala is the ability to define
+ − 1755
% functions with varying argument lists. This is a feature that
+ − 1756
% is already present in old languages, like C, but seems to have
+ − 1757
% been forgotten in the meantime---Java does not have it. In the
+ − 1758
% context of regular expressions this feature comes in handy:
+ − 1759
% Say you are fed up with writing many alternatives as
123
+ − 1760
+ − 1761
143
+ − 1762
% \begin{lstlisting}[numbers=none]
+ − 1763
% ALT(..., ALT(..., ALT(..., ...)))
+ − 1764
% \end{lstlisting}
123
+ − 1765
+ − 1766
143
+ − 1767
% \noindent To make it difficult, you do not know how deep such
+ − 1768
% alternatives are nested. So you need something flexible that
+ − 1769
% can take as many alternatives as needed. In Scala one can
+ − 1770
% achieve this by adding a \code{*} to the type of an argument.
+ − 1771
% Consider the code
123
+ − 1772
+ − 1773
143
+ − 1774
% \begin{lstlisting}[language=Scala]
+ − 1775
% def Alts(rs: List[Rexp]) : Rexp = rs match {
+ − 1776
% case Nil => NULL
+ − 1777
% case r::Nil => r
+ − 1778
% case r::rs => ALT(r, Alts(rs))
+ − 1779
% }
123
+ − 1780
143
+ − 1781
% def ALTS(rs: Rexp*) = Alts(rs.toList)
+ − 1782
% \end{lstlisting}
123
+ − 1783
+ − 1784
143
+ − 1785
% \noindent The function in Lines 1 to 5 takes a list of regular
+ − 1786
% expressions and converts it into an appropriate alternative
+ − 1787
% regular expression. In Line 7 there is a wrapper for this
+ − 1788
% function which uses the feature of varying argument lists. The
+ − 1789
% effect of this code is that I can write the regular
+ − 1790
% expression for keywords as
123
+ − 1791
+ − 1792
143
+ − 1793
% \begin{lstlisting}[numbers=none]
+ − 1794
% ALTS("for", "def", "yield", "implicit", "if", "match", "case")
+ − 1795
% \end{lstlisting}
123
+ − 1796
+ − 1797
143
+ − 1798
% \noindent Again I leave it to you to find out how much this
+ − 1799
% simplifies the regular expression in comparison with if I had
+ − 1800
% to write this by hand using only the ``plain'' regular
+ − 1801
% expressions from the inductive datatype.
+ − 1802
197
+ − 1803
%\bigskip\noindent
+ − 1804
%\textit{More TBD.}
123
+ − 1805
197
+ − 1806
%\subsection*{Coursework}
181
+ − 1807
395
+ − 1808
\begin{figure}[p]
492
+ − 1809
\begin{boxedminipage}{\textwidth}
395
+ − 1810
\textbf{Scala Syntax for Java Developers}\bigskip
195
+ − 1811
395
+ − 1812
\noindent
343
+ − 1813
Scala compiles to the JVM, like the Java language. Because of this,
352
+ − 1814
it can re-use many libraries. Here are a few hints how some Java code
+ − 1815
tranlsates to Scala code:\bigskip
343
+ − 1816
352
+ − 1817
\noindent
+ − 1818
Variable declaration:
343
+ − 1819
\begin{lstlisting}[language=Java]
352
+ − 1820
Drink coke = getCoke();/*!\annotation{Java}!*/
343
+ − 1821
\end{lstlisting}
+ − 1822
+ − 1823
\begin{lstlisting}[language=Scala]
352
+ − 1824
val coke : Drink = getCoke()/*!\annotation{Scala}!*/
343
+ − 1825
\end{lstlisting}
+ − 1826
352
+ − 1827
\noindent
395
+ − 1828
or even
+ − 1829
+ − 1830
\begin{lstlisting}[language=Scala]
+ − 1831
val coke = getCoke()/*!\annotation{Scala}!*/
+ − 1832
\end{lstlisting}\bigskip
+ − 1833
+ − 1834
\noindent
343
+ − 1835
Unit means void:
+ − 1836
+ − 1837
\begin{lstlisting}[language=Java]
352
+ − 1838
public void output(String s) {/*!\annotation{Java}!*/
343
+ − 1839
System.out.println(s);
+ − 1840
}
+ − 1841
\end{lstlisting}
+ − 1842
+ − 1843
\begin{lstlisting}[language=Scala]
352
+ − 1844
def output(s: String): Unit = println(s)/*!\annotation{Scala}!*/
395
+ − 1845
\end{lstlisting}\bigskip
343
+ − 1846
352
+ − 1847
\noindent
470
+ − 1848
Compound types, say the type for list of Strings:
343
+ − 1849
+ − 1850
\begin{lstlisting}[language=Java]
352
+ − 1851
List<String>/*!\annotation{Java}!*/
343
+ − 1852
\end{lstlisting}
+ − 1853
+ − 1854
\begin{lstlisting}[language=Scala]
352
+ − 1855
List[String]/*!\annotation{Scala}!*/
395
+ − 1856
\end{lstlisting}\bigskip
343
+ − 1857
352
+ − 1858
\noindent
343
+ − 1859
String interpolations
+ − 1860
+ − 1861
\begin{lstlisting}[language=Java]
352
+ − 1862
System.out.println("Hello, "+ first + " "+ last + "!");
+ − 1863
/*!\annotation{Java}!*/
343
+ − 1864
\end{lstlisting}
+ − 1865
+ − 1866
\begin{lstlisting}[language=Scala]
352
+ − 1867
println(s"Hello, $first $last!")/*!\annotation{Scala}!*/
395
+ − 1868
\end{lstlisting}\bigskip
343
+ − 1869
352
+ − 1870
\noindent
395
+ − 1871
Java provides some syntactic sugar when constructing anonymous functions:
343
+ − 1872
+ − 1873
\begin{lstlisting}[language=Java]
+ − 1874
list.foreach(item -> System.out.println("* " + item));
352
+ − 1875
/*!\annotation{Java}!*/
343
+ − 1876
\end{lstlisting}
+ − 1877
352
+ − 1878
\noindent
441
+ − 1879
In Scala, we use the \code{=>} symbol for the same:
343
+ − 1880
+ − 1881
\begin{lstlisting}[language=Scala]
352
+ − 1882
list.foreach(item => println(s"* $item"))/*!\annotation{Scala}!*/
+ − 1883
\end{lstlisting}%$
395
+ − 1884
\end{boxedminipage}
+ − 1885
\end{figure}
343
+ − 1886
352
+ − 1887
%%new / vs case classes
343
+ − 1888
195
+ − 1889
123
+ − 1890
\subsection*{More Info}
+ − 1891
+ − 1892
There is much more to Scala than I can possibly describe in
492
+ − 1893
this short document and teach in the lectures. Fortunately there are a
197
+ − 1894
number of free books
123
+ − 1895
about Scala and of course lots of help online. For example
+ − 1896
+ − 1897
\begin{itemize}
400
+ − 1898
%%\item \url{http://www.scala-lang.org/docu/files/ScalaByExample.pdf}
+ − 1899
%%\item \url{http://www.scala-lang.org/docu/files/ScalaTutorial.pdf}
123
+ − 1900
\item \url{https://www.youtube.com/user/ShadowofCatron}
+ − 1901
\item \url{http://docs.scala-lang.org/tutorials}
+ − 1902
\item \url{https://www.scala-exercises.org}
188
+ − 1903
\item \url{https://twitter.github.io/scala_school}
123
+ − 1904
\end{itemize}
492
+ − 1905
197
+ − 1906
\noindent There is also an online course at Coursera on Functional
123
+ − 1907
Programming Principles in Scala by Martin Odersky, the main
+ − 1908
developer of the Scala language. And a document that explains
+ − 1909
Scala for Java programmers
+ − 1910
+ − 1911
\begin{itemize}
+ − 1912
\item \small\url{http://docs.scala-lang.org/tutorials/scala-for-java-programmers.html}
+ − 1913
\end{itemize}
+ − 1914
+ − 1915
While I am quite enthusiastic about Scala, I am also happy to
470
+ − 1916
admit that it has more than its fair share of faults.
+ − 1917
%The
+ − 1918
%problem seen earlier of having to give an explicit type to
+ − 1919
%\code{toSet}, but not \code{toList} is one of them. There are
+ − 1920
%also many ``deep'' ideas about types in Scala, which even to
+ − 1921
%me as seasoned functional programmer are puzzling.
+ − 1922
For example, whilst
123
+ − 1923
implicits are great, they can also be a source of great
+ − 1924
headaches, for example consider the code:
+ − 1925
+ − 1926
\begin{lstlisting}[numbers=none]
+ − 1927
scala> List (1, 2, 3) contains "your mom"
+ − 1928
res1: Boolean = false
+ − 1929
\end{lstlisting}
+ − 1930
+ − 1931
\noindent Rather than returning \code{false}, this code should
+ − 1932
throw a typing-error. There are also many limitations Scala
+ − 1933
inherited from the JVM that can be really annoying. For
+ − 1934
example a fixed stack size. One can work around this
+ − 1935
particular limitation, but why does one have to?
+ − 1936
More such `puzzles' can be found at
+ − 1937
+ − 1938
\begin{center}
+ − 1939
\url{http://scalapuzzlers.com} and
+ − 1940
\url{http://latkin.org/blog/2017/05/02/when-the-scala-compiler-doesnt-help/}
+ − 1941
\end{center}
492
+ − 1942
191
+ − 1943
Even if Scala has been a success in several high-profile companies,
+ − 1944
there is also a company (Yammer) that first used Scala in their
+ − 1945
production code, but then moved away from it. Allegedly they did not
+ − 1946
like the steep learning curve of Scala and also that new versions of
+ − 1947
Scala often introduced incompatibilities in old code. Also the Java
471
+ − 1948
language is lately developing at lightening speed (in comparison to
+ − 1949
the past) taking on many features of Scala and other languages, and it
+ − 1950
seems it even introduces new features on its own. So there is
+ − 1951
seemingly even more incentive to stick with the old stuff you
+ − 1952
know. Still, the goal of this part of PEP is to bend your mind about
+ − 1953
what programming is\ldots{}namely functional programming. I promise
+ − 1954
you, this will be useful no matter with which programming language you
+ − 1955
will work.
123
+ − 1956
333
+ − 1957
+ − 1958
Scala is deep: After many years, I still continue to learn new technique
470
+ − 1959
for writing more elegant code.
+ − 1960
%Unfortunately, I have not yet managed to
+ − 1961
%switch over my code to Scala 3.0 due to time constraints.
+ − 1962
Scala 3 seems
441
+ − 1963
to iron out a number of snags from Scala 2, but why on earth are they
442
+ − 1964
introducing Python-esque indentation and why on earth are they
441
+ − 1965
re-introducing the \texttt{then}-keyword in Scala 3, when I just about got
492
+ − 1966
comfortable without it?
333
+ − 1967
152
+ − 1968
%So all in all, Scala might not be a great teaching language,
+ − 1969
%but I hope this is mitigated by the fact that I never require
+ − 1970
%you to write any Scala code. You only need to be able to read
+ − 1971
%it. In the coursework you can use any programming language you
+ − 1972
%like. If you want to use Scala for this, then be my guest; if
+ − 1973
%you do not want, stick with the language you are most familiar
+ − 1974
%with.
123
+ − 1975
+ − 1976
191
+ − 1977
\subsection*{Conclusion}
+ − 1978
483
+ − 1979
I hope you liked the short journey through the Scala language---but
+ − 1980
remember we like you to take on board the functional programming point
+ − 1981
of view, rather than just learning another language: Immutable
+ − 1982
functions are easier to trust, because they the same output on the
+ − 1983
same input. For the same reason they are easier to test and debug.
+ − 1984
There is an interesting blog article about Scala by a convert:
198
+ − 1985
+ − 1986
\begin{center}
+ − 1987
\url{https://www.skedulo.com/tech-blog/technology-scala-programming/}
492
+ − 1988
\end{center}
198
+ − 1989
+ − 1990
\noindent
+ − 1991
He makes pretty much the same arguments about functional programming and
+ − 1992
immutability (one section is teasingly called \textit{``Where Did all
+ − 1993
the Bugs Go?''}). If you happen to moan about all the idiotic features
471
+ − 1994
of Scala (3), well, I guess this is part of the package according to this
198
+ − 1995
quote:\bigskip
197
+ − 1996
+ − 1997
%\begin{itemize}
+ − 1998
%\item no exceptions....there two kinds, one ``global'' exceptions, like
+ − 1999
%out of memory (not much can be done about this by the ``individual''
+ − 2000
%programmer); and ``local one'' open a file that might not exists - in
+ − 2001
%the latter you do not want to use exceptions, but Options
+ − 2002
%\end{itemize}
123
+ − 2003
182
+ − 2004
\begin{flushright}\it
492
+ − 2005
There are only two kinds of languages: the ones people complain
182
+ − 2006
about\\ and the ones nobody uses.\smallskip\\
+ − 2007
\mbox{}\hfill\small{}---Bjarne Stroustrup (the inventor of C++)
+ − 2008
\end{flushright}
+ − 2009
123
+ − 2010
\end{document}
+ − 2011
492
+ − 2012
%%% Local Variables:
123
+ − 2013
%%% mode: latex
+ − 2014
%%% TeX-master: t
492
+ − 2015
%%% End: