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