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