| 123 |      1 | \documentclass{article}
 | 
|  |      2 | \usepackage{../style}
 | 
|  |      3 | \usepackage{../langs}
 | 
|  |      4 | \usepackage{marvosym}
 | 
|  |      5 | 
 | 
|  |      6 | %cheat sheet
 | 
|  |      7 | %http://worldline.github.io/scala-cheatsheet/
 | 
|  |      8 | 
 | 
| 167 |      9 | % case class, apply, unappy
 | 
|  |     10 | % see https://medium.com/@thejasbabu/scala-pattern-matching-9c9e73ba9a8a
 | 
|  |     11 | 
 | 
|  |     12 | 
 | 
| 178 |     13 | \begin{document} 
 | 
| 123 |     14 | 
 | 
| 468 |     15 | \section*{A Crash-Course of Scala}
 | 
| 123 |     16 | 
 | 
|  |     17 | Scala is a programming language that combines functional and
 | 
| 170 |     18 | object-oriented programming-styles. It has received quite a bit of
 | 
|  |     19 | attention in the last five or so years. One reason for this attention
 | 
|  |     20 | is that, like the Java programming language, Scala compiles to the
 | 
|  |     21 | Java Virtual Machine (JVM) and therefore Scala programs can run under
 | 
|  |     22 | MacOSX, Linux and Windows.\footnote{There are also experimental
 | 
|  |     23 |   backends for Android and JavaScript; and also work is under way to
 | 
|  |     24 |   have a native compiler, see
 | 
|  |     25 |   \url{https://github.com/scala-native/scala-native}.} Unlike Java,
 | 
|  |     26 | however, Scala often allows programmers to write very concise and
 | 
|  |     27 | elegant code.  Some therefore say: ``Scala is the better
 | 
|  |     28 | Java''.\footnote{\url{https://www.slideshare.net/maximnovak/joy-of-scala}}
 | 
|  |     29 | Also a number of companies (the Guardian, Twitter, Coursera,
 | 
|  |     30 | FourSquare, LinkedIn to name a few) either use Scala exclusively in
 | 
|  |     31 | production code, or at least to some substantial degree. Scala seems
 | 
|  |     32 | also to be useful in job-interviews (in Data Science) according to
 | 
|  |     33 | this anecdotal report
 | 
|  |     34 | 
 | 
| 123 |     35 | 
 | 
|  |     36 | \begin{quote}
 | 
|  |     37 | \url{https://techcrunch.com/2016/06/14/scala-is-the-new-golden-child/}
 | 
|  |     38 | \end{quote}
 | 
|  |     39 | 
 | 
|  |     40 | \noindent
 | 
|  |     41 | If you want to try out Scala yourself, the official Scala compiler can be
 | 
|  |     42 | downloaded from
 | 
|  |     43 | 
 | 
|  |     44 | \begin{quote}
 | 
|  |     45 | \url{http://www.scala-lang.org}
 | 
|  |     46 | \end{quote}
 | 
|  |     47 | 
 | 
|  |     48 | \noindent
 | 
|  |     49 | A ready-made bundle with the Eclipse IDE is at
 | 
|  |     50 | 
 | 
|  |     51 | \begin{quote}
 | 
|  |     52 | \url{http://scala-ide.org/download/sdk.html}
 | 
|  |     53 | \end{quote}
 | 
|  |     54 | 
 | 
| 170 |     55 | \noindent
 | 
|  |     56 | When developing Scala programs, I personally prefer to use Emacs
 | 
|  |     57 | or Sublime as my environment, since they provide an easy access
 | 
|  |     58 | to the Scala REPL (see below).  But it is also possible to work
 | 
|  |     59 | completely on the command line and also with heavy-duty IDEs
 | 
|  |     60 | like Eclipse of IntelliJ. There is even an online editor and
 | 
|  |     61 | environment for developing Scala programs called ScalaFiddle
 | 
|  |     62 | 
 | 
|  |     63 | \begin{quote}
 | 
|  |     64 | \url{https://scalafiddle.io}
 | 
|  |     65 | \end{quote}
 | 
|  |     66 | 
 | 
| 123 |     67 | Why do I use Scala in the AFL module? Actually, you can do
 | 
|  |     68 | \emph{any} part of the coursework in \emph{any} programming
 | 
|  |     69 | language you like. I use Scala for showing you code during the
 | 
|  |     70 | lectures because its functional programming-style allows me to
 | 
|  |     71 | implement the functions we will discuss with very small
 | 
|  |     72 | code-snippets. If I had to do this in Java, I would first have
 | 
|  |     73 | to go through heaps of boilerplate code and the code-snippets
 | 
|  |     74 | would not look pretty. Since the Scala compiler is free, you
 | 
|  |     75 | can download the code-snippets and run every example I give.
 | 
|  |     76 | But if you prefer, you can also easily translate them into any
 | 
|  |     77 | other functional language, for example Haskell, Swift,
 | 
|  |     78 | Standard ML, F$^\#$, Ocaml and so on.
 | 
|  |     79 | 
 | 
|  |     80 | Developing programs in Scala can be done with the Eclipse IDE
 | 
|  |     81 | and also with the IntelliJ IDE, but for the small programs I will
 | 
|  |     82 | develop the good old Emacs-editor is adequate for me and I
 | 
|  |     83 | will run the programs on the command line. One advantage of
 | 
|  |     84 | Scala over Java is that it includes an interpreter (a REPL, or
 | 
|  |     85 | \underline{R}ead-\underline{E}val-\underline{P}rint-\underline{L}oop)
 | 
|  |     86 | with which you can run and test small code-snippets without
 | 
|  |     87 | the need of the compiler. This helps a lot with interactively
 | 
|  |     88 | developing programs. Once you installed Scala, you can start
 | 
|  |     89 | the interpreter by typing on the command line:
 | 
|  |     90 | 
 | 
|  |     91 | \begin{lstlisting}[language={},numbers=none,basicstyle=\ttfamily\small]
 | 
|  |     92 | $ scala
 | 
|  |     93 | Welcome to Scala version 2.11.8 (Java HotSpot(TM) 64-Bit Server VM).
 | 
|  |     94 | Type in expressions for evaluation. Or try :help.
 | 
|  |     95 | 
 | 
|  |     96 | scala>
 | 
|  |     97 | \end{lstlisting}
 | 
|  |     98 | 
 | 
|  |     99 | \noindent Of course the precise response may vary due to the
 | 
|  |    100 | version and platform where you installed Scala. At the Scala
 | 
|  |    101 | prompt you can type things like \code{2 + 3} \keys{Ret} and
 | 
|  |    102 | the output will be
 | 
|  |    103 | 
 | 
|  |    104 | \begin{lstlisting}[numbers=none]
 | 
|  |    105 | scala> 2 + 3
 | 
|  |    106 | res0: Int = 5
 | 
|  |    107 | \end{lstlisting}
 | 
|  |    108 | 
 | 
|  |    109 | \noindent indicating that the result of the addition is of
 | 
|  |    110 | type \code{Int} and the actual result is 5. Another classic
 | 
|  |    111 | example you can try out is
 | 
|  |    112 | 
 | 
|  |    113 | \begin{lstlisting}[numbers=none]
 | 
|  |    114 | scala> print("hello world")
 | 
|  |    115 | hello world
 | 
|  |    116 | \end{lstlisting}
 | 
|  |    117 | 
 | 
|  |    118 | \noindent Note that in this case there is no result. The
 | 
|  |    119 | reason is that \code{print} does not actually produce a result
 | 
|  |    120 | (there is no \code{resXX} and no type), rather it is a
 | 
|  |    121 | function that causes the \emph{side-effect} of printing out a
 | 
|  |    122 | string. Once you are more familiar with the functional
 | 
|  |    123 | programming-style, you will know what the difference is
 | 
|  |    124 | between a function that returns a result, like addition, and a
 | 
|  |    125 | function that causes a side-effect, like \code{print}. We
 | 
|  |    126 | shall come back to this point later, but if you are curious
 | 
|  |    127 | now, the latter kind of functions always has \code{Unit} as
 | 
|  |    128 | return type.
 | 
|  |    129 | 
 | 
|  |    130 | If you want to write a stand-alone app in Scala, you can
 | 
|  |    131 | implement an object that is an instance of \code{App}, say
 | 
|  |    132 | 
 | 
|  |    133 | \begin{lstlisting}[numbers=none]
 | 
|  |    134 | object Hello extends App {
 | 
|  |    135 |     println("hello world")
 | 
|  |    136 | }
 | 
|  |    137 | \end{lstlisting}
 | 
|  |    138 | 
 | 
|  |    139 | \noindent save it in a file, say {\tt hello-world.scala}, and
 | 
|  |    140 | then run the compiler and runtime environment:
 | 
|  |    141 | 
 | 
|  |    142 | \begin{lstlisting}[language={},numbers=none,basicstyle=\ttfamily\small]
 | 
|  |    143 | $ scalac hello-world.scala
 | 
|  |    144 | $ scala Hello
 | 
|  |    145 | hello world
 | 
|  |    146 | \end{lstlisting}
 | 
|  |    147 | 
 | 
|  |    148 | As mentioned above, Scala targets the JVM and consequently
 | 
|  |    149 | Scala programs can also be executed by the bog-standard Java
 | 
|  |    150 | Runtime. This only requires the inclusion of {\tt
 | 
|  |    151 | scala-library.jar}, which on my computer can be done as
 | 
|  |    152 | follows:
 | 
|  |    153 | 
 | 
|  |    154 | \begin{lstlisting}[language={},numbers=none,basicstyle=\ttfamily\small]
 | 
|  |    155 | $ scalac hello-world.scala
 | 
|  |    156 | $ java -cp /usr/local/src/scala/lib/scala-library.jar:. Hello
 | 
|  |    157 | hello world
 | 
|  |    158 | \end{lstlisting}
 | 
|  |    159 | 
 | 
|  |    160 | \noindent You might need to adapt the path to where you have
 | 
|  |    161 | installed Scala.
 | 
|  |    162 | 
 | 
|  |    163 | \subsection*{Inductive Datatypes}
 | 
|  |    164 | 
 | 
|  |    165 | The elegance and conciseness of Scala programs are often a
 | 
|  |    166 | result of inductive datatypes that can be easily defined in
 | 
|  |    167 | Scala. For example in ``every-day mathematics'' we define
 | 
|  |    168 | regular expressions simply by giving the grammar
 | 
|  |    169 | 
 | 
|  |    170 | \begin{center}
 | 
|  |    171 | \begin{tabular}{r@{\hspace{2mm}}r@{\hspace{2mm}}l@{\hspace{13mm}}l}
 | 
|  |    172 |   $r$ & $::=$ &   $\ZERO$            & null\\
 | 
|  |    173 |         & $\mid$ & $\ONE$            & empty string\\
 | 
|  |    174 |         & $\mid$ & $c$               & single character\\
 | 
|  |    175 |         & $\mid$ & $r_1 \cdot r_2$   & sequence\\
 | 
|  |    176 |         & $\mid$ & $r_1 + r_2$       & alternative / choice\\
 | 
|  |    177 |         & $\mid$ & $r^\star$             & star (zero or more)\\
 | 
|  |    178 |   \end{tabular}
 | 
|  |    179 | \end{center}
 | 
|  |    180 | 
 | 
|  |    181 | \noindent This grammar specifies what regular expressions are
 | 
|  |    182 | (essentially a kind of tree-structure with three kinds of
 | 
|  |    183 | inner nodes---sequence, alternative and star---and three kinds
 | 
|  |    184 | of leave nodes---null, empty and character). If you are
 | 
|  |    185 | familiar with Java, it might be an instructive exercise to
 | 
|  |    186 | define this kind of inductive datatypes in Java\footnote{Happy
 | 
|  |    187 | programming! \Smiley} and then compare it with how it can be
 | 
|  |    188 | implemented in Scala.
 | 
|  |    189 | 
 | 
|  |    190 | Implementing the regular expressions from above in Scala is
 | 
|  |    191 | actually very simple: It first requires an \emph{abstract
 | 
|  |    192 | class}, say, \code{Rexp}. This will act as the type for
 | 
|  |    193 | regular expressions. Second, it requires a case for each
 | 
|  |    194 | clause in the grammar. The cases for $\ZERO$ and $\ONE$ do not
 | 
|  |    195 | have any arguments, while in all the other cases we do have
 | 
|  |    196 | arguments. For example the character regular expression needs
 | 
|  |    197 | to take as an argument the character it is supposed to
 | 
|  |    198 | recognise. In Scala, the cases without arguments are called
 | 
|  |    199 | \emph{case objects}, whereas the ones with arguments are
 | 
|  |    200 | \emph{case classes}. The corresponding Scala code is as
 | 
|  |    201 | follows:
 | 
|  |    202 | 
 | 
|  |    203 | \begin{lstlisting}[numbers=none]
 | 
|  |    204 | abstract class Rexp 
 | 
|  |    205 | case object ZERO extends Rexp
 | 
|  |    206 | case object ONE extends Rexp
 | 
|  |    207 | case class CHAR (c: Char) extends Rexp
 | 
|  |    208 | case class SEQ (r1: Rexp, r2: Rexp) extends Rexp 
 | 
|  |    209 | case class ALT (r1: Rexp, r2: Rexp) extends Rexp 
 | 
|  |    210 | case class STAR (r: Rexp) extends Rexp 
 | 
|  |    211 | \end{lstlisting}
 | 
|  |    212 | 
 | 
|  |    213 | \noindent In order to be an instance of \code{Rexp}, each case
 | 
|  |    214 | object and case class needs to extend \code{Rexp}. Given the
 | 
|  |    215 | grammar above, I hope you can see the underlying pattern. If
 | 
|  |    216 | you want to play further with such definitions of inductive
 | 
|  |    217 | datatypes, feel free to define for example binary trees.
 | 
|  |    218 | 
 | 
|  |    219 | Once you make a definition like the one above in Scala, you
 | 
|  |    220 | can represent the regular expression for $a + b$, for example,
 | 
|  |    221 | as \code{ALT(CHAR('a'), CHAR('b'))}. Expressions such as
 | 
|  |    222 | \code{'a'} stand for ASCII characters, though in the output
 | 
|  |    223 | syntax, as you can see below, the quotes are omitted. In a
 | 
|  |    224 | later section we will see how we can support the more
 | 
|  |    225 | mathematical infix notation for regular expression operators
 | 
|  |    226 | in Scala. If you want to assign this regular expression to a
 | 
|  |    227 | variable, you can use the keyword \code{val} and type
 | 
|  |    228 | 
 | 
|  |    229 | \begin{lstlisting}[numbers=none]
 | 
|  |    230 | scala> val r = ALT(CHAR('a'), CHAR('b'))
 | 
|  |    231 | r: ALT = ALT(CHAR(a),CHAR(b))
 | 
|  |    232 | \end{lstlisting}
 | 
|  |    233 | 
 | 
|  |    234 | \noindent As you can see, in order to make such assignments,
 | 
|  |    235 | no \code{new} or constructor is required in the class (as in
 | 
|  |    236 | Java). However, if there is the need for some non-standard
 | 
|  |    237 | initialisation, you can of course define such a constructor in
 | 
|  |    238 | Scala too. But we omit such ``tricks'' here. 
 | 
|  |    239 | 
 | 
|  |    240 | Note that Scala in its response says the variable \code{r} is
 | 
|  |    241 | of type \code{ALT}, not \code{Rexp}. This might be a bit
 | 
|  |    242 | unexpected, but can be explained as follows: Scala always
 | 
|  |    243 | tries to find the most general type that is needed for a
 | 
|  |    244 | variable or expression, but does not ``over-generalise''. In
 | 
|  |    245 | our definition the type \code{Rexp} is more general than
 | 
|  |    246 | \code{ALT}, since it is the abstract class for all regular
 | 
|  |    247 | expressions. But in this particular case there is no need to
 | 
|  |    248 | give \code{r} the more general type of \code{Rexp}. This is
 | 
|  |    249 | different if you want to form a list of regular expressions,
 | 
|  |    250 | for example
 | 
|  |    251 | 
 | 
|  |    252 | \begin{lstlisting}[numbers=none]
 | 
|  |    253 | scala> val ls = List(ALT(CHAR('a'), CHAR('b')), ZERO)
 | 
|  |    254 | ls: List[Rexp] = List(ALT(CHAR(a),CHAR(b)), ZERO)
 | 
|  |    255 | \end{lstlisting}
 | 
|  |    256 | 
 | 
|  |    257 | \noindent In this case, Scala needs to assign a common type to
 | 
|  |    258 | the regular expressions so that it is compatible with the
 | 
|  |    259 | fact that lists can only contain elements of a single type. In
 | 
|  |    260 | this case the first common type is \code{Rexp}.\footnote{If you
 | 
|  |    261 | type in this example, you will notice that the type contains
 | 
|  |    262 | some further information, but let us ignore this for the
 | 
|  |    263 | moment.} 
 | 
|  |    264 | 
 | 
|  |    265 | For compound types like \code{List[...]}, the general rule is
 | 
|  |    266 | that when a type takes another type as argument, then this
 | 
|  |    267 | argument type is written in angle-brackets. This can also
 | 
|  |    268 | contain nested types as in \code{List[Set[Rexp]]}, which is a
 | 
|  |    269 | list of sets each of which contains regular expressions.
 | 
|  |    270 | 
 | 
|  |    271 | \subsection*{Functions and Pattern-Matching}
 | 
|  |    272 | 
 | 
|  |    273 | I mentioned above that Scala is a very elegant programming
 | 
|  |    274 | language for the code we will write in this module. This
 | 
|  |    275 | elegance mainly stems from the fact that in addition to
 | 
|  |    276 | inductive datatypes, also functions can be implemented very
 | 
|  |    277 | easily in Scala. To show you this, let us first consider a
 | 
|  |    278 | problem from number theory, called the \emph{Collatz-series},
 | 
|  |    279 | which corresponds to a famous unsolved problem in
 | 
|  |    280 | mathematics.\footnote{See for example
 | 
|  |    281 | \url{http://mathworld.wolfram.com/CollatzProblem.html}.}
 | 
|  |    282 | Mathematicians define this series as:
 | 
|  |    283 | 
 | 
|  |    284 | \[
 | 
|  |    285 | collatz_{n + 1} \dn 
 | 
|  |    286 | \begin{cases}
 | 
|  |    287 | \frac{1}{2} * collatz_n & \text{if $collatz_n$ is even}\\
 | 
|  |    288 | 3 * collatz_n + 1 & \text{if $collatz_n$ is odd}
 | 
|  |    289 | \end{cases}
 | 
|  |    290 | \]
 | 
|  |    291 | 
 | 
|  |    292 | \noindent The famous unsolved question is whether this
 | 
|  |    293 | series started with any $n > 0$ as $collatz_0$ will always
 | 
|  |    294 | return to $1$. This is obvious when started with $1$, and also
 | 
|  |    295 | with $2$, but already needs a bit of head-scratching for the
 | 
|  |    296 | case of $3$.
 | 
|  |    297 | 
 | 
|  |    298 | If we want to avoid the head-scratching, we could implement
 | 
|  |    299 | this as the following function in Scala:
 | 
|  |    300 | 
 | 
|  |    301 | \lstinputlisting[numbers=none]{../progs/collatz.scala}
 | 
|  |    302 | 
 | 
|  |    303 | \noindent The keyword for function definitions is \code{def}
 | 
|  |    304 | followed by the name of the function. After that you have a
 | 
|  |    305 | list of arguments (enclosed in parentheses and separated by
 | 
|  |    306 | commas). Each argument in this list needs its type to be
 | 
|  |    307 | annotated. In this case we only have one argument, which is of
 | 
|  |    308 | type \code{BigInt}. This type stands in Scala for arbitrary
 | 
|  |    309 | precision integers (in case you want to try out the function
 | 
|  |    310 | on really big numbers). After the arguments comes the type of
 | 
|  |    311 | what the function returns---a Boolean in this case for
 | 
|  |    312 | indicating that the function has reached 1. Finally, after the
 | 
|  |    313 | \code{=} comes the \emph{body} of the function implementing
 | 
|  |    314 | what the function is supposed to do. What the \code{collatz}
 | 
|  |    315 | function does should be pretty self-explanatory: the function
 | 
|  |    316 | first tests whether \code{n} is equal to 1 in which case it
 | 
|  |    317 | returns \code{true} and so on.
 | 
|  |    318 | 
 | 
|  |    319 | Notice the quirk in Scala's syntax for \code{if}s: The condition
 | 
|  |    320 | needs to be enclosed in parentheses and the then-case comes
 | 
|  |    321 | right after the condition---there is no \code{then} keyword in
 | 
|  |    322 | Scala.
 | 
|  |    323 | 
 | 
|  |    324 | The real power of Scala comes, however, from the ability to
 | 
|  |    325 | define functions by \emph{pattern matching}. In the
 | 
|  |    326 | \code{collatz} function above we need to test each case using a
 | 
|  |    327 | sequence of \code{if}s. This can be very cumbersome and brittle
 | 
|  |    328 | if there are many cases. If we wanted to define a function
 | 
|  |    329 | over regular expressions in Java, for example, which does not
 | 
|  |    330 | have pattern-matching, the resulting code would just be
 | 
|  |    331 | awkward.
 | 
|  |    332 | 
 | 
|  |    333 | Mathematicians already use the power of pattern-matching when
 | 
|  |    334 | they define the function that takes a regular expression and
 | 
|  |    335 | produces another regular expression that can recognise the
 | 
|  |    336 | reversed strings. They define this function as follows:
 | 
|  |    337 | 
 | 
|  |    338 | \begin{center}
 | 
|  |    339 | \begin{tabular}{r@{\hspace{2mm}}c@{\hspace{2mm}}l}
 | 
|  |    340 | $rev(\ZERO)$   & $\dn$ & $\ZERO$\\
 | 
|  |    341 | $rev(\ONE)$      & $\dn$ & $\ONE$\\
 | 
|  |    342 | $rev(c)$             & $\dn$ & $c$\\
 | 
|  |    343 | $rev(r_1 + r_2)$     & $\dn$ & $rev(r_1) + rev(r_2)$\\
 | 
|  |    344 | $rev(r_1 \cdot r_2)$ & $\dn$ & $rev(r_2) \cdot rev(r_1)$\\
 | 
|  |    345 | $rev(r^*)$                   & $\dn$ & $rev(r)^*$\\
 | 
|  |    346 | \end{tabular}
 | 
|  |    347 | \end{center}
 | 
|  |    348 | 
 | 
|  |    349 | \noindent It is defined by recursion analysing each pattern of
 | 
|  |    350 | what the regular expression might look like. The corresponding
 | 
|  |    351 | Scala code looks very similar to this definition, thanks to
 | 
|  |    352 | pattern-matching.
 | 
|  |    353 | 
 | 
|  |    354 | %%\lstinputlisting[language=Scala]{../progs/rev.scala}
 | 
|  |    355 | 
 | 
|  |    356 | \noindent The keyword for starting a pattern-match is
 | 
|  |    357 | \code{match} followed by a list of \code{case}s. Before the
 | 
|  |    358 | match keyword can be another pattern, but often, as in the
 | 
|  |    359 | case above, it is just a variable you want to pattern-match
 | 
|  |    360 | (the \code{r} after \code{=} in Line 1).
 | 
|  |    361 | 
 | 
|  |    362 | Each case in this definition follows the structure of how we
 | 
|  |    363 | defined regular expressions as inductive datatype. For example
 | 
|  |    364 | the case in Line 3 you can read as: if the regular expression
 | 
|  |    365 | \code{r} is of the form \code{EMPTY} then do whatever follows
 | 
|  |    366 | the \code{=>} (in this case just return \code{EMPTY}). Line 5
 | 
|  |    367 | reads as: if the regular expression \code{r} is of the form
 | 
|  |    368 | \code{ALT(r1, r2)}, where the left-branch of the alternative is
 | 
|  |    369 | matched by the variable \code{r1} and the right-branch by
 | 
|  |    370 | \code{r2} then do ``something''. The ``something'' can now use the
 | 
|  |    371 | variables \code{r1} and \code{r2} from the match. 
 | 
|  |    372 | 
 | 
|  |    373 | If you want to play with this function, call it for example
 | 
|  |    374 | with the regular expression $ab + ac$. This regular expression
 | 
|  |    375 | can recognise the strings $ab$ and $ac$. The function 
 | 
|  |    376 | \code{rev} produces $ba + ca$, which can recognise the reversed
 | 
|  |    377 | strings $ba$ and $ca$.
 | 
|  |    378 | 
 | 
|  |    379 | In Scala each pattern-match can also be guarded as in
 | 
|  |    380 | 
 | 
|  |    381 | \begin{lstlisting}[ numbers=none]
 | 
|  |    382 | case Pattern if Condition => Do_Something
 | 
|  |    383 | \end{lstlisting}
 | 
|  |    384 | 
 | 
|  |    385 | \noindent This allows us, for example, to re-write the 
 | 
|  |    386 | \code{collatz}-function from above as follows:
 | 
|  |    387 |  
 | 
|  |    388 | %%\lstinputlisting[language=Scala]{../progs/collatz2.scala}
 | 
|  |    389 | 
 | 
|  |    390 | 
 | 
|  |    391 | \noindent Although in this particular case the pattern-match
 | 
|  |    392 | does not improve the code in any way. In cases like
 | 
|  |    393 | \code{rev}, however, it is really crucial. The underscore in
 | 
|  |    394 | Line 4 indicates that we do not care what the pattern looks
 | 
|  |    395 | like. Thus this case acts like a default case whenever the
 | 
|  |    396 | cases above did not match. Cases are always tried out from top
 | 
|  |    397 | to bottom.
 | 
|  |    398 |  
 | 
|  |    399 | \subsection*{Loops, or better the Absence thereof}
 | 
|  |    400 | 
 | 
|  |    401 | Coming from Java or C, you might be surprised that Scala does
 | 
|  |    402 | not really have loops. It has instead, what is in functional
 | 
|  |    403 | programming called, \emph{maps}. To illustrate how they work,
 | 
|  |    404 | let us assume you have a list of numbers from 1 to 8 and want to
 | 
|  |    405 | build the list of squares. The list of numbers from 1 to 8 
 | 
|  |    406 | can be constructed in Scala as follows:
 | 
|  |    407 | 
 | 
|  |    408 | \begin{lstlisting}[numbers=none]
 | 
|  |    409 | scala> (1 to 8).toList
 | 
|  |    410 | res1: List[Int] = List(1, 2, 3, 4, 5, 6, 7, 8)
 | 
|  |    411 | \end{lstlisting}
 | 
|  |    412 | 
 | 
|  |    413 | \noindent Generating from this list, the list of squares in a
 | 
|  |    414 | programming language such as Java, you would assume the list
 | 
|  |    415 | is given as a kind of array. You would then iterate, or loop,
 | 
|  |    416 | an index over this array and replace each entry in the array
 | 
|  |    417 | by the square. Right? In Scala, and in other functional
 | 
|  |    418 | programming languages, you use maps to achieve the same. 
 | 
|  |    419 | 
 | 
|  |    420 | A map essentially takes a function that describes how each
 | 
|  |    421 | element is transformed (for example squared) and a list over
 | 
|  |    422 | which this function should work. There are two forms to
 | 
|  |    423 | express such maps in Scala. The first way is called a
 | 
|  |    424 | \emph{for-comprehension}. Squaring the numbers from 1 to 8
 | 
|  |    425 | would look in this form as follows:
 | 
|  |    426 | 
 | 
|  |    427 | \begin{lstlisting}[numbers=none]
 | 
|  |    428 | scala> for (n <- (1 to 8).toList) yield n * n
 | 
|  |    429 | res2: List[Int] = List(1, 4, 9, 16, 25, 36, 49, 64)
 | 
|  |    430 | \end{lstlisting}
 | 
|  |    431 | 
 | 
|  |    432 | \noindent The important keywords are \code{for} and
 | 
|  |    433 | \code{yield}. This for-comprehension roughly states that from
 | 
|  |    434 | the list of numbers we draw \code{n}s and compute the result
 | 
|  |    435 | of \code{n * n}. As you can see, we specified the list where
 | 
|  |    436 | each \code{n} comes from, namely \code{(1 to 8).toList}, and
 | 
|  |    437 | how each element needs to be transformed. This can also be
 | 
|  |    438 | expressed in a second way in Scala by using directly
 | 
|  |    439 | \code{map}s as follows:
 | 
|  |    440 | 
 | 
|  |    441 | \begin{lstlisting}[numbers=none]
 | 
|  |    442 | scala> (1 to 8).toList.map(n => n * n)
 | 
|  |    443 | res3 = List(1, 4, 9, 16, 25, 36, 49, 64)
 | 
|  |    444 | \end{lstlisting}
 | 
|  |    445 | 
 | 
|  |    446 | \noindent In this way, the expression \code{n => n * n} stands
 | 
|  |    447 | for the function that calculates the square (this is how the
 | 
|  |    448 | \code{n}s are transformed). This expression for functions
 | 
|  |    449 | might remind you of your lessons about the lambda-calculus
 | 
|  |    450 | where this would have been written as $\lambda n.\,n * n$. It
 | 
|  |    451 | might not be obvious, but for-comprehensions are just
 | 
|  |    452 | syntactic sugar: when compiling, Scala translates
 | 
|  |    453 | for-comprehensions into equivalent maps. This even works
 | 
|  |    454 | when for-comprehensions get more complicated (see below).
 | 
|  |    455 | 
 | 
|  |    456 | The very charming feature of Scala is that such maps or
 | 
|  |    457 | for-comprehensions can be written for any kind of data
 | 
|  |    458 | collection, such as lists, sets, vectors, options and so on.
 | 
|  |    459 | For example if we instead compute the reminders modulo 3 of
 | 
|  |    460 | this list, we can write
 | 
|  |    461 | 
 | 
|  |    462 | \begin{lstlisting}[numbers=none]
 | 
|  |    463 | scala> (1 to 8).toList.map(n => n % 3)
 | 
|  |    464 | res4 = List(1, 2, 0, 1, 2, 0, 1, 2)
 | 
|  |    465 | \end{lstlisting}
 | 
|  |    466 | 
 | 
|  |    467 | \noindent If we, however, transform the numbers 1 to 8 not
 | 
|  |    468 | into a list, but into a set, and then compute the reminders
 | 
|  |    469 | modulo 3 we obtain
 | 
|  |    470 | 
 | 
|  |    471 | \begin{lstlisting}[numbers=none]
 | 
|  |    472 | scala> (1 to 8).toSet[Int].map(n => n % 3)
 | 
|  |    473 | res5 = Set(2, 1, 0)
 | 
|  |    474 | \end{lstlisting}
 | 
|  |    475 | 
 | 
|  |    476 | \noindent This is the correct result for sets, as there are
 | 
|  |    477 | only three equivalence classes of integers modulo 3. Note that
 | 
|  |    478 | in this example we need to ``help'' Scala to transform the
 | 
|  |    479 | numbers into a set of integers by explicitly annotating the
 | 
|  |    480 | type \code{Int}. Since maps and for-comprehensions are
 | 
|  |    481 | just syntactic variants of each other, the latter can also be
 | 
|  |    482 | written as
 | 
|  |    483 | 
 | 
|  |    484 | \begin{lstlisting}[numbers=none]
 | 
|  |    485 | scala> for (n <- (1 to 8).toSet[Int]) yield n % 3
 | 
|  |    486 | res5 = Set(2, 1, 0)
 | 
|  |    487 | \end{lstlisting}
 | 
|  |    488 | 
 | 
|  |    489 | For-comprehensions can also be nested and the selection of 
 | 
|  |    490 | elements can be guarded. For example if we want to pair up
 | 
|  |    491 | the numbers 1 to 4 with the letters a to c, we can write
 | 
|  |    492 | 
 | 
|  |    493 | \begin{lstlisting}[numbers=none]
 | 
|  |    494 | scala> for (n <- (1 to 4).toList; 
 | 
|  |    495 |             m <- ('a' to 'c').toList) yield (n, m)
 | 
|  |    496 | res6 = List((1,a), (1,b), (1,c), (2,a), (2,b), (2,c), 
 | 
|  |    497 |             (3,a), (3,b), (3,c), (4,a), (4,b), (4,c))
 | 
|  |    498 | \end{lstlisting}
 | 
|  |    499 | 
 | 
|  |    500 | \noindent 
 | 
|  |    501 | Or if we want to find all pairs of numbers between 1 and 3
 | 
|  |    502 | where the sum is an even number, we can write
 | 
|  |    503 | 
 | 
|  |    504 | \begin{lstlisting}[numbers=none]
 | 
|  |    505 | scala> for (n <- (1 to 3).toList; 
 | 
|  |    506 |             m <- (1 to 3).toList;
 | 
|  |    507 |             if (n + m) % 2 == 0) yield (n, m)
 | 
|  |    508 | res7 = List((1,1), (1,3), (2,2), (3,1), (3,3))
 | 
|  |    509 | \end{lstlisting}
 | 
|  |    510 | 
 | 
|  |    511 | \noindent The \code{if}-condition in the for-comprehension
 | 
|  |    512 | filters out all pairs where the sum is not even.
 | 
|  |    513 | 
 | 
|  |    514 | While hopefully this all looks reasonable, there is one
 | 
|  |    515 | complication: In the examples above we always wanted to
 | 
|  |    516 | transform one list into another list (e.g.~list of squares),
 | 
|  |    517 | or one set into another set (set of numbers into set of
 | 
|  |    518 | reminders modulo 3). What happens if we just want to print out
 | 
|  |    519 | a list of integers? Then actually the for-comprehension
 | 
|  |    520 | needs to be modified. The reason is that \code{print}, you
 | 
|  |    521 | guessed it, does not produce any result, but only produces
 | 
|  |    522 | what is in the functional-programming-lingo called a
 | 
|  |    523 | side-effect. Printing out the list of numbers from 1 to 5
 | 
|  |    524 | would look as follows
 | 
|  |    525 | 
 | 
|  |    526 | \begin{lstlisting}[numbers=none]
 | 
|  |    527 | scala> for (n <- (1 to 5).toList) print(n)
 | 
|  |    528 | 12345
 | 
|  |    529 | \end{lstlisting}
 | 
|  |    530 | 
 | 
|  |    531 | \noindent
 | 
|  |    532 | where you need to omit the keyword \code{yield}. You can
 | 
|  |    533 | also do more elaborate calculations such as
 | 
|  |    534 | 
 | 
|  |    535 | \begin{lstlisting}[numbers=none]
 | 
|  |    536 | scala> for (n <- (1 to 5).toList) {
 | 
|  |    537 |   val square_n = n * n
 | 
|  |    538 |   println(s"$n * $n = $square_n") 
 | 
|  |    539 | }
 | 
|  |    540 | 1 * 1 = 1
 | 
|  |    541 | 2 * 2 = 4
 | 
|  |    542 | 3 * 3 = 9
 | 
|  |    543 | 4 * 4 = 16
 | 
|  |    544 | 5 * 5 = 25
 | 
|  |    545 | \end{lstlisting}
 | 
|  |    546 | 
 | 
|  |    547 | \noindent In this code I use a variable assignment (\code{val
 | 
|  |    548 | square_n = ...} ) and also what is called in Scala a
 | 
|  |    549 | \emph{string interpolation}, written \code{s"..."}. The latter
 | 
|  |    550 | is for printing out an equation. It allows me to refer to the
 | 
|  |    551 | integer values \code{n} and \code{square\_n} inside a string.
 | 
|  |    552 | This is very convenient for printing out ``things''. 
 | 
|  |    553 | 
 | 
|  |    554 | The corresponding map construction for functions with 
 | 
|  |    555 | side-effects is in Scala called \code{foreach}. So you 
 | 
|  |    556 | could also write
 | 
|  |    557 | 
 | 
|  |    558 | 
 | 
|  |    559 | \begin{lstlisting}[numbers=none]
 | 
|  |    560 | scala> (1 to 5).toList.foreach(n => print(n))
 | 
|  |    561 | 12345
 | 
|  |    562 | \end{lstlisting}
 | 
|  |    563 | 
 | 
|  |    564 | 
 | 
|  |    565 | \noindent or even just
 | 
|  |    566 | 
 | 
|  |    567 | \begin{lstlisting}[numbers=none]
 | 
|  |    568 | scala> (1 to 5).toList.foreach(print)
 | 
|  |    569 | 12345
 | 
|  |    570 | \end{lstlisting}
 | 
|  |    571 | 
 | 
|  |    572 | \noindent Again I hope this reminds you a bit of your
 | 
|  |    573 | lambda-calculus lessons, where an explanation is given why
 | 
|  |    574 | both forms produce the same result.
 | 
|  |    575 | 
 | 
|  |    576 | 
 | 
|  |    577 | If you want to find out more about maps and functions with
 | 
|  |    578 | side-effects, you can ponder about the response Scala gives if
 | 
|  |    579 | you replace \code{foreach} by \code{map} in the expression
 | 
|  |    580 | above. Scala will still allow \code{map} with side-effect
 | 
|  |    581 | functions, but then reacts with a slightly interesting result.
 | 
|  |    582 | 
 | 
|  |    583 | \subsection*{Types}
 | 
|  |    584 | 
 | 
|  |    585 | In most functional programming languages, types play an
 | 
|  |    586 | important role. Scala is such a language. You have already
 | 
|  |    587 | seen built-in types, like \code{Int}, \code{Boolean},
 | 
|  |    588 | \code{String} and \code{BigInt}, but also user-defined ones,
 | 
|  |    589 | like \code{Rexp}. Unfortunately, types can be a thorny
 | 
|  |    590 | subject, especially in Scala. For example, why do we need to
 | 
|  |    591 | give the type to \code{toSet[Int]}, but not to \code{toList}?
 | 
|  |    592 | The reason is the power of Scala, which sometimes means it
 | 
|  |    593 | cannot infer all necessary typing information. At the
 | 
|  |    594 | beginning while getting familiar with Scala, I recommend a
 | 
|  |    595 | ``play-it-by-ear-approach'' to types. Fully understanding
 | 
|  |    596 | type-systems, especially complicated ones like in Scala, can
 | 
|  |    597 | take a module on their own.\footnote{Still, such a study can
 | 
|  |    598 | be a rewarding training: If you are in the business of
 | 
|  |    599 | designing new programming languages, you will not be able to
 | 
|  |    600 | turn a blind eye to types. They essentially help programmers
 | 
|  |    601 | to avoid common programming errors and help with maintaining
 | 
|  |    602 | code.}
 | 
|  |    603 | 
 | 
|  |    604 | In Scala, types are needed whenever you define an inductive
 | 
|  |    605 | datatype and also whenever you define functions (their
 | 
|  |    606 | arguments and their results need a type). Base types are types
 | 
|  |    607 | that do not take any (type)arguments, for example \code{Int}
 | 
|  |    608 | and \code{String}. Compound types take one or more arguments,
 | 
|  |    609 | which as seen earlier need to be given in angle-brackets, for
 | 
|  |    610 | example \code{List[Int]} or \code{Set[List[String]]} or 
 | 
|  |    611 | \code{Map[Int, Int]}.
 | 
|  |    612 | 
 | 
|  |    613 | There are a few special type-constructors that fall outside
 | 
|  |    614 | this pattern. One is for tuples, where the type is written
 | 
|  |    615 | with parentheses. For example 
 | 
|  |    616 | 
 | 
|  |    617 | \begin{lstlisting}[ numbers=none]
 | 
|  |    618 | (Int, Int, String)
 | 
|  |    619 | \end{lstlisting}
 | 
|  |    620 | 
 | 
|  |    621 | \noindent is for a triple (a tuple with three components---two
 | 
|  |    622 | integers and a string). Tuples are helpful if you want to
 | 
|  |    623 | define functions with multiple results, say the function
 | 
|  |    624 | returning the quotient and reminder of two numbers. For this
 | 
|  |    625 | you might define:
 | 
|  |    626 | 
 | 
|  |    627 | 
 | 
|  |    628 | \begin{lstlisting}[ numbers=none]
 | 
|  |    629 | def quo_rem(m: Int, n: Int) : (Int, Int) = (m / n, m % n)
 | 
|  |    630 | \end{lstlisting}
 | 
|  |    631 | 
 | 
|  |    632 | 
 | 
|  |    633 | \noindent Since this function returns a pair of integers, its
 | 
|  |    634 | return type needs to be of type \code{(Int, Int)}.
 | 
|  |    635 | Incidentally, this is also the input type of this function.
 | 
|  |    636 | Notice this function takes \emph{two} arguments, namely
 | 
|  |    637 | \code{m} and \code{n}, both of which are integers. They are
 | 
|  |    638 | ``packaged'' in a pair. Consequently the complete type of
 | 
|  |    639 | \code{quo_rem} is
 | 
|  |    640 | 
 | 
|  |    641 | \begin{lstlisting}[ numbers=none]
 | 
|  |    642 | (Int, Int) => (Int, Int)
 | 
|  |    643 | \end{lstlisting}
 | 
|  |    644 | 
 | 
|  |    645 | Another special type-constructor is for functions, written as
 | 
|  |    646 | the arrow \code{=>}. For example, the type \code{Int =>
 | 
|  |    647 | String} is for a function that takes an integer as input
 | 
|  |    648 | argument and produces a string as result. A function of this
 | 
|  |    649 | type is for instance
 | 
|  |    650 | 
 | 
|  |    651 | \begin{lstlisting}[numbers=none]
 | 
|  |    652 | def mk_string(n: Int) : String = n match {
 | 
|  |    653 |   case 0 => "zero"
 | 
|  |    654 |   case 1 => "one"
 | 
|  |    655 |   case 2 => "two"
 | 
|  |    656 |   case _ => "many" 
 | 
|  |    657 | } 
 | 
|  |    658 | \end{lstlisting}
 | 
|  |    659 | 
 | 
|  |    660 | \noindent It takes an integer as input argument and returns a
 | 
|  |    661 | string. Unlike other functional programming languages, there
 | 
|  |    662 | is in Scala no easy way to find out the types of existing
 | 
|  |    663 | functions, except by looking into the documentation
 | 
|  |    664 | 
 | 
|  |    665 | \begin{quote}
 | 
|  |    666 | \url{http://www.scala-lang.org/api/current/}
 | 
|  |    667 | \end{quote}
 | 
|  |    668 | 
 | 
|  |    669 | The function arrow can also be iterated, as in 
 | 
|  |    670 | \code{Int => String => Boolean}. This is the type for a function
 | 
|  |    671 | taking an integer as first argument and a string as second,
 | 
|  |    672 | and the result of the function is a boolean. Though silly, a
 | 
|  |    673 | function of this type would be
 | 
|  |    674 | 
 | 
|  |    675 | 
 | 
|  |    676 | \begin{lstlisting}[numbers=none]
 | 
|  |    677 | def chk_string(n: Int)(s: String) : Boolean = 
 | 
|  |    678 |   mk_string(n) == s
 | 
|  |    679 | \end{lstlisting}
 | 
|  |    680 | 
 | 
|  |    681 | 
 | 
|  |    682 | \noindent which checks whether the integer \code{n}
 | 
|  |    683 | corresponds to the name \code{s} given by the function
 | 
|  |    684 | \code{mk\_string}. Notice the unusual way of specifying the
 | 
|  |    685 | arguments of this function: the arguments are given one after
 | 
|  |    686 | the other, instead of being in a pair (what would be the type
 | 
|  |    687 | of this function then?). This way of specifying the arguments
 | 
|  |    688 | can be useful, for example in situations like this
 | 
|  |    689 | 
 | 
|  |    690 | \begin{lstlisting}[numbers=none]
 | 
|  |    691 | scala> List("one", "two", "three", "many").map(chk_string(2))
 | 
|  |    692 | res4 = List(false, true, false, false)
 | 
|  |    693 | 
 | 
|  |    694 | scala> List("one", "two", "three", "many").map(chk_string(3))
 | 
|  |    695 | res5 = List(false, false, false, true)
 | 
|  |    696 | \end{lstlisting}
 | 
|  |    697 | 
 | 
|  |    698 | \noindent In each case we can give to \code{map} a specialised
 | 
|  |    699 | version of \code{chk_string}---once specialised to 2 and once
 | 
|  |    700 | to 3. This kind of ``specialising'' a function is called
 | 
|  |    701 | \emph{partial application}---we have not yet given to this
 | 
|  |    702 | function all arguments it needs, but only some of them.
 | 
|  |    703 | 
 | 
|  |    704 | Coming back to the type \code{Int => String => Boolean}. The
 | 
|  |    705 | rule about such function types is that the right-most type
 | 
|  |    706 | specifies what the function returns (a boolean in this case).
 | 
|  |    707 | The types before that specify how many arguments the function
 | 
|  |    708 | expects and what their type is (in this case two arguments,
 | 
|  |    709 | one of type \code{Int} and another of type \code{String}).
 | 
|  |    710 | Given this rule, what kind of function has type
 | 
|  |    711 | \mbox{\code{(Int => String) => Boolean}}? Well, it returns a
 | 
|  |    712 | boolean. More interestingly, though, it only takes a single
 | 
|  |    713 | argument (because of the parentheses). The single argument
 | 
|  |    714 | happens to be another function (taking an integer as input and
 | 
|  |    715 | returning a string). Remember that \code{mk_string} is just 
 | 
|  |    716 | such a function. So how can we use it? For this define
 | 
|  |    717 | the somewhat silly function \code{apply_3}:
 | 
|  |    718 | 
 | 
|  |    719 | \begin{lstlisting}[numbers=none]
 | 
|  |    720 | def apply_3(f: Int => String): Bool = f(3) == "many"
 | 
|  |    721 | 
 | 
|  |    722 | scala> apply_3(mk_string)
 | 
|  |    723 | res6 = true
 | 
|  |    724 | \end{lstlisting}
 | 
|  |    725 | 
 | 
|  |    726 | You might ask: Apart from silly functions like above, what is
 | 
|  |    727 | the point of having functions as input arguments to other
 | 
|  |    728 | functions? In Java there is indeed no need of this kind of
 | 
|  |    729 | feature: at least in the past it did not allow such
 | 
|  |    730 | constructions. I think, the point of Java 8 is to lift this
 | 
|  |    731 | restriction. But in all functional programming languages,
 | 
|  |    732 | including Scala, it is really essential to allow functions as
 | 
|  |    733 | input argument. Above you already seen \code{map} and
 | 
|  |    734 | \code{foreach} which need this. Consider the functions
 | 
|  |    735 | \code{print} and \code{println}, which both print out strings,
 | 
|  |    736 | but the latter adds a line break. You can call \code{foreach}
 | 
|  |    737 | with either of them and thus changing how, for example, five
 | 
|  |    738 | numbers are printed.
 | 
|  |    739 | 
 | 
|  |    740 | 
 | 
|  |    741 | \begin{lstlisting}[numbers=none]
 | 
|  |    742 | scala> (1 to 5).toList.foreach(print)
 | 
|  |    743 | 12345
 | 
|  |    744 | scala> (1 to 5).toList.foreach(println)
 | 
|  |    745 | 1
 | 
|  |    746 | 2
 | 
|  |    747 | 3
 | 
|  |    748 | 4
 | 
|  |    749 | 5
 | 
|  |    750 | \end{lstlisting}
 | 
|  |    751 | 
 | 
|  |    752 | 
 | 
|  |    753 | \noindent This is actually one of the main design principles
 | 
|  |    754 | in functional programming. You have generic functions like
 | 
|  |    755 | \code{map} and \code{foreach} that can traverse data containers,
 | 
|  |    756 | like lists or sets. They then take a function to specify what
 | 
|  |    757 | should be done with each element during the traversal. This
 | 
|  |    758 | requires that the generic traversal functions can cope with
 | 
|  |    759 | any kind of function (not just functions that, for example,
 | 
|  |    760 | take as input an integer and produce a string like above).
 | 
|  |    761 | This means we cannot fix the type of the generic traversal
 | 
|  |    762 | functions, but have to keep them
 | 
|  |    763 | \emph{polymorphic}.\footnote{Another interestic topic about
 | 
|  |    764 | types, but we omit it here for the sake of brevity.} 
 | 
|  |    765 | 
 | 
|  |    766 | There is one more type constructor that is rather special. It
 | 
|  |    767 | is called \code{Unit}. Recall that \code{Boolean} has two
 | 
|  |    768 | values, namely \code{true} and \code{false}. This can be used,
 | 
|  |    769 | for example, to test something and decide whether the test
 | 
|  |    770 | succeeds or not. In contrast the type \code{Unit} has only a
 | 
|  |    771 | single value, written \code{()}. This seems like a completely
 | 
|  |    772 | useless type and return value for a function, but is actually
 | 
|  |    773 | quite useful. It indicates when the function does not return
 | 
|  |    774 | any result. The purpose of these functions is to cause
 | 
|  |    775 | something being written on the screen or written into a file,
 | 
|  |    776 | for example. This is what is called they cause some effect on 
 | 
|  |    777 | the side, namely a new content displayed on the screen or some
 | 
|  |    778 | new data in a file. Scala uses the \code{Unit} type to indicate
 | 
|  |    779 | that a function does not have a result, but potentially causes
 | 
|  |    780 | some side-effect. Typical examples are the printing functions, 
 | 
|  |    781 | like \code{print}.
 | 
|  |    782 | 
 | 
|  |    783 | 
 | 
|  |    784 | \subsection*{Cool Stuff}
 | 
|  |    785 | 
 | 
|  |    786 | The first wow-moment I had with Scala was when I came across
 | 
|  |    787 | the following code-snippet for reading a web-page. 
 | 
|  |    788 | 
 | 
|  |    789 | 
 | 
|  |    790 | \begin{lstlisting}[ numbers=none]
 | 
|  |    791 | import io.Source
 | 
|  |    792 | val url = """http://www.inf.kcl.ac.uk/staff/urbanc/"""
 | 
|  |    793 | Source.fromURL(url)("ISO-8859-1").take(10000).mkString
 | 
|  |    794 | \end{lstlisting}
 | 
|  |    795 | 
 | 
|  |    796 | 
 | 
|  |    797 | \noindent These three lines return a string containing the
 | 
|  |    798 | HTML-code of my webpage. It actually already does something
 | 
|  |    799 | more sophisticated, namely only returns the first 10000
 | 
|  |    800 | characters of a webpage in case it is too large. Why is that
 | 
|  |    801 | code-snippet of any interest? Well, try implementing
 | 
|  |    802 | reading-from-a-webpage in Java. I also like the possibility of
 | 
|  |    803 | triple-quoting strings, which I have only seen in Scala so
 | 
|  |    804 | far. The idea behind this is that in such a string all
 | 
|  |    805 | characters are interpreted literally---there are no escaped
 | 
|  |    806 | characters, like \verb|\n| for newlines.
 | 
|  |    807 | 
 | 
|  |    808 | My second wow-moment I had with a feature of Scala that other
 | 
|  |    809 | functional programming languages do not have. This feature is
 | 
|  |    810 | about implicit type conversions. If you have regular
 | 
|  |    811 | expressions and want to use them for language processing you
 | 
|  |    812 | often want to recognise keywords in a language, for example
 | 
|  |    813 | \code{for},{} \code{if},{} \code{yield} and so on. But the
 | 
|  |    814 | basic regular expression \code{CHAR} can only recognise a
 | 
|  |    815 | single character. In order to recognise a whole string, like
 | 
|  |    816 | \code{for}, you have to put many of those together using
 | 
|  |    817 | \code{SEQ}:
 | 
|  |    818 | 
 | 
|  |    819 | 
 | 
|  |    820 | \begin{lstlisting}[numbers=none]
 | 
|  |    821 | SEQ(CHAR('f'), SEQ(CHAR('o'), CHAR('r')))
 | 
|  |    822 | \end{lstlisting}
 | 
|  |    823 | 
 | 
|  |    824 | \noindent This gets quickly unreadable when the strings and
 | 
|  |    825 | regular expressions get more complicated. In other functional
 | 
|  |    826 | programming languages, you can explicitly write a conversion
 | 
|  |    827 | function that takes a string, say \dq{\pcode{for}}, and
 | 
|  |    828 | generates the regular expression above. But then your code is
 | 
|  |    829 | littered with such conversion functions.
 | 
|  |    830 | 
 | 
|  |    831 | In Scala you can do better by ``hiding'' the conversion
 | 
|  |    832 | functions. The keyword for doing this is \code{implicit} and
 | 
|  |    833 | it needs a built-in library called 
 | 
|  |    834 | 
 | 
|  |    835 | \begin{lstlisting}[numbers=none]
 | 
|  |    836 | scala.language.implicitConversions
 | 
|  |    837 | \end{lstlisting}
 | 
|  |    838 | 
 | 
|  |    839 | \noindent
 | 
|  |    840 | Consider the code
 | 
|  |    841 | 
 | 
|  |    842 | 
 | 
|  |    843 | \begin{lstlisting}[language=Scala]
 | 
|  |    844 | import scala.language.implicitConversions
 | 
|  |    845 | 
 | 
|  |    846 | def charlist2rexp(s: List[Char]) : Rexp = s match {
 | 
|  |    847 |   case Nil => EMPTY
 | 
|  |    848 |   case c::Nil => CHAR(c)
 | 
|  |    849 |   case c::s => SEQ(CHAR(c), charlist2rexp(s))
 | 
|  |    850 | }
 | 
|  |    851 | 
 | 
|  |    852 | implicit def string2rexp(s: String) : Rexp = 
 | 
|  |    853 |   charlist2rexp(s.toList)
 | 
|  |    854 | \end{lstlisting}
 | 
|  |    855 | 
 | 
|  |    856 | 
 | 
|  |    857 | \noindent where the first seven lines implement a function
 | 
|  |    858 | that given a list of characters generates the corresponding
 | 
|  |    859 | regular expression. In Lines 9 and 10, this function is used
 | 
|  |    860 | for transforming a string into a regular expression. Since the
 | 
|  |    861 | \code{string2rexp}-function is declared as \code{implicit},
 | 
|  |    862 | the effect will be that whenever Scala expects a regular
 | 
|  |    863 | expression, but I only give it a string, it will automatically
 | 
|  |    864 | insert a call to the \code{string2rexp}-function. I can now
 | 
|  |    865 | write for example
 | 
|  |    866 | 
 | 
|  |    867 | \begin{lstlisting}[numbers=none]
 | 
|  |    868 | scala> ALT("ab", "ac")
 | 
|  |    869 | res9 = ALT(SEQ(CHAR(a),CHAR(b)),SEQ(CHAR(a),CHAR(c)))
 | 
|  |    870 | \end{lstlisting}
 | 
|  |    871 | 
 | 
|  |    872 | \noindent Recall that \code{ALT} expects two regular
 | 
|  |    873 | expressions as arguments, but I only supply two strings. The
 | 
|  |    874 | implicit conversion function will transform the string into a
 | 
|  |    875 | regular expression.
 | 
|  |    876 | 
 | 
|  |    877 | Using implicit definitions, Scala allows me to introduce
 | 
|  |    878 | some further syntactic sugar for regular expressions:
 | 
|  |    879 | 
 | 
|  |    880 | 
 | 
|  |    881 | \begin{lstlisting}[ numbers=none]
 | 
|  |    882 | implicit def RexpOps(r: Rexp) = new {
 | 
|  |    883 |   def | (s: Rexp) = ALT(r, s)
 | 
|  |    884 |   def ~ (s: Rexp) = SEQ(r, s)
 | 
|  |    885 |   def % = STAR(r)
 | 
|  |    886 | }
 | 
|  |    887 | 
 | 
|  |    888 | implicit def stringOps(s: String) = new {
 | 
|  |    889 |   def | (r: Rexp) = ALT(s, r)
 | 
|  |    890 |   def | (r: String) = ALT(s, r)
 | 
|  |    891 |   def ~ (r: Rexp) = SEQ(s, r)
 | 
|  |    892 |   def ~ (r: String) = SEQ(s, r)
 | 
|  |    893 |   def % = STAR(s)
 | 
|  |    894 | }
 | 
|  |    895 | \end{lstlisting}
 | 
|  |    896 | 
 | 
|  |    897 |  
 | 
|  |    898 | \noindent This might seem a bit overly complicated, but its effect is
 | 
|  |    899 | that I can now write regular expressions such as $ab + ac$ 
 | 
|  |    900 | simply as
 | 
|  |    901 | 
 | 
|  |    902 | 
 | 
|  |    903 | \begin{lstlisting}[numbers=none]
 | 
|  |    904 | scala> "ab" | "ac"
 | 
|  |    905 | res10 = ALT(SEQ(CHAR(a),CHAR(b)),SEQ(CHAR(a),CHAR(c)))
 | 
|  |    906 | \end{lstlisting}
 | 
|  |    907 | 
 | 
|  |    908 |  
 | 
|  |    909 | \noindent I leave you to figure out what the other
 | 
|  |    910 | syntactic sugar in the code above stands for.
 | 
|  |    911 |  
 | 
|  |    912 | One more useful feature of Scala is the ability to define
 | 
|  |    913 | functions with varying argument lists. This is a feature that
 | 
|  |    914 | is already present in old languages, like C, but seems to have
 | 
|  |    915 | been forgotten in the meantime---Java does not have it. In the
 | 
|  |    916 | context of regular expressions this feature comes in handy:
 | 
|  |    917 | Say you are fed up with writing many alternatives as
 | 
|  |    918 | 
 | 
|  |    919 | 
 | 
|  |    920 | \begin{lstlisting}[numbers=none]
 | 
|  |    921 | ALT(..., ALT(..., ALT(..., ...)))
 | 
|  |    922 | \end{lstlisting}
 | 
|  |    923 | 
 | 
|  |    924 | 
 | 
|  |    925 | \noindent To make it difficult, you do not know how deep such
 | 
|  |    926 | alternatives are nested. So you need something flexible that
 | 
|  |    927 | can take as many alternatives as needed. In Scala one can
 | 
|  |    928 | achieve this by adding a \code{*} to the type of an argument.
 | 
|  |    929 | Consider the code
 | 
|  |    930 | 
 | 
|  |    931 | 
 | 
|  |    932 | \begin{lstlisting}[language=Scala]
 | 
|  |    933 | def Alts(rs: List[Rexp]) : Rexp = rs match {
 | 
|  |    934 |   case Nil => NULL
 | 
|  |    935 |   case r::Nil => r
 | 
|  |    936 |   case r::rs => ALT(r, Alts(rs))
 | 
|  |    937 | }
 | 
|  |    938 | 
 | 
|  |    939 | def ALTS(rs: Rexp*) = Alts(rs.toList)
 | 
|  |    940 | \end{lstlisting}
 | 
|  |    941 | 
 | 
|  |    942 | 
 | 
|  |    943 | \noindent The function in Lines 1 to 5 takes a list of regular
 | 
|  |    944 | expressions and converts it into an appropriate alternative
 | 
|  |    945 | regular expression. In Line 7 there is a wrapper for this
 | 
|  |    946 | function which uses the feature of varying argument lists. The
 | 
|  |    947 | effect of this code  is that I can write the regular
 | 
|  |    948 | expression for keywords as
 | 
|  |    949 | 
 | 
|  |    950 | 
 | 
|  |    951 | \begin{lstlisting}[numbers=none]
 | 
|  |    952 | ALTS("for", "def", "yield", "implicit", "if", "match", "case")
 | 
|  |    953 | \end{lstlisting}
 | 
|  |    954 | 
 | 
|  |    955 | 
 | 
|  |    956 | \noindent Again I leave it to you to find out how much this
 | 
|  |    957 | simplifies the regular expression in comparison with if I had
 | 
|  |    958 | to write this by hand using only the ``plain'' regular
 | 
|  |    959 | expressions from the inductive datatype.
 | 
|  |    960 | 
 | 
|  |    961 | \subsection*{More Info}
 | 
|  |    962 | 
 | 
|  |    963 | There is much more to Scala than I can possibly describe in
 | 
|  |    964 | this document. Fortunately there are a number of free books
 | 
|  |    965 | about Scala and of course lots of help online. For example
 | 
|  |    966 | 
 | 
|  |    967 | \begin{itemize}
 | 
|  |    968 | \item \url{http://www.scala-lang.org/docu/files/ScalaByExample.pdf}
 | 
|  |    969 | \item \url{http://www.scala-lang.org/docu/files/ScalaTutorial.pdf}
 | 
|  |    970 | \item \url{https://www.youtube.com/user/ShadowofCatron}
 | 
|  |    971 | \item \url{http://docs.scala-lang.org/tutorials}
 | 
|  |    972 | \item \url{https://www.scala-exercises.org}
 | 
|  |    973 | \end{itemize}
 | 
|  |    974 | 
 | 
|  |    975 | \noindent There is also a course at Coursera on Functional
 | 
|  |    976 | Programming Principles in Scala by Martin Odersky, the main
 | 
|  |    977 | developer of the Scala language. And a document that explains
 | 
|  |    978 | Scala for Java programmers
 | 
|  |    979 | 
 | 
|  |    980 | \begin{itemize}
 | 
|  |    981 | \item \small\url{http://docs.scala-lang.org/tutorials/scala-for-java-programmers.html}
 | 
|  |    982 | \end{itemize}
 | 
|  |    983 | 
 | 
|  |    984 | While I am quite enthusiastic about Scala, I am also happy to
 | 
|  |    985 | admit that it has more than its fair share of faults. The
 | 
|  |    986 | problem seen earlier of having to give an explicit type to
 | 
|  |    987 | \code{toSet}, but not \code{toList} is one of them. There are
 | 
|  |    988 | also many ``deep'' ideas about types in Scala, which even to
 | 
|  |    989 | me as seasoned functional programmer are puzzling. Whilst
 | 
|  |    990 | implicits are great, they can also be a source of great
 | 
|  |    991 | headaches, for example consider the code:
 | 
|  |    992 | 
 | 
|  |    993 | \begin{lstlisting}[numbers=none]
 | 
|  |    994 | scala>  List (1, 2, 3) contains "your mom"
 | 
|  |    995 | res1: Boolean = false
 | 
|  |    996 | \end{lstlisting}
 | 
|  |    997 | 
 | 
|  |    998 | \noindent Rather than returning \code{false}, this code should
 | 
|  |    999 | throw a typing-error. There are also many limitations Scala
 | 
|  |   1000 | inherited from the JVM that can be really annoying. For
 | 
|  |   1001 | example a fixed stack size. One can work around this
 | 
|  |   1002 | particular limitation, but why does one have to?
 | 
|  |   1003 | More such `puzzles' can be found at
 | 
|  |   1004 | 
 | 
|  |   1005 | \begin{center}
 | 
|  |   1006 |   \url{http://scalapuzzlers.com} and
 | 
|  |   1007 |   \url{http://latkin.org/blog/2017/05/02/when-the-scala-compiler-doesnt-help/}
 | 
|  |   1008 | \end{center}
 | 
|  |   1009 | 
 | 
|  |   1010 | Even if Scala has been a success in several high-profile
 | 
|  |   1011 | companies, there is also a company (Yammer) that first used
 | 
|  |   1012 | Scala in their production code, but then moved away from it.
 | 
|  |   1013 | Allegedly they did not like the steep learning curve of Scala
 | 
|  |   1014 | and also that new versions of Scala often introduced
 | 
|  |   1015 | incompatibilities in old code. In the past two months
 | 
|  |   1016 | there have also been two forks of the Scala compiler.
 | 
|  |   1017 | It needs to be seen what the future brings for Scala.
 | 
|  |   1018 | 
 | 
|  |   1019 | So all in all, Scala might not be a great teaching language,
 | 
|  |   1020 | but I hope this is mitigated by the fact that I never require
 | 
|  |   1021 | you to write any Scala code. You only need to be able to read
 | 
|  |   1022 | it. In the coursework you can use any programming language you
 | 
|  |   1023 | like. If you want to use Scala for this, then be my guest; if
 | 
|  |   1024 | you do not want, stick with the language you are most familiar
 | 
|  |   1025 | with.
 | 
|  |   1026 | 
 | 
|  |   1027 | 
 | 
|  |   1028 | 
 | 
|  |   1029 | \end{document}
 | 
|  |   1030 | 
 | 
|  |   1031 | %%% Local Variables: 
 | 
|  |   1032 | %%% mode: latex
 | 
|  |   1033 | %%% TeX-master: t
 | 
|  |   1034 | %%% End: 
 |