author | Christian Urban <christian.urban@kcl.ac.uk> |
Sun, 14 Jul 2024 14:31:39 +0100 | |
changeset 492 | 4ffba2f72692 |
parent 485 | 19b75e899d37 |
permissions | -rw-r--r-- |
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
86a85865e772
updated
Christian Urban <christian dot urban at kcl dot ac dot uk>
parents:
265
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
86a85865e772
updated
Christian Urban <christian dot urban at kcl dot ac dot uk>
parents:
265
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
86a85865e772
updated
Christian Urban <christian dot urban at kcl dot ac dot uk>
parents:
265
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
b9eaa5cdec4a
updated
Christian Urban <christian dot urban at kcl dot ac dot uk>
parents:
269
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
b9eaa5cdec4a
updated
Christian Urban <christian dot urban at kcl dot ac dot uk>
parents:
269
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
b9eaa5cdec4a
updated
Christian Urban <christian dot urban at kcl dot ac dot uk>
parents:
269
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: |