| 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 | 
 | 
|  |      9 | \begin{document}
 | 
|  |     10 | 
 | 
| 125 |     11 | \section*{A Crash-Course in Scala}
 | 
| 123 |     12 | 
 | 
|  |     13 | \subsection*{The Very Basics}
 | 
|  |     14 | 
 | 
|  |     15 | One advantage of Scala over Java is that it includes an interpreter (a
 | 
|  |     16 | REPL, or
 | 
|  |     17 | \underline{R}ead-\underline{E}val-\underline{P}rint-\underline{L}oop)
 | 
|  |     18 | with which you can run and test small code-snippets without the need
 | 
|  |     19 | of a compiler. This helps a lot with interactively developing
 | 
|  |     20 | programs. Once you installed Scala, you can start the interpreter by
 | 
|  |     21 | typing on the command line:
 | 
|  |     22 | 
 | 
|  |     23 | \begin{lstlisting}[language={},numbers=none,basicstyle=\ttfamily\small]
 | 
|  |     24 | $ scala
 | 
|  |     25 | Welcome to Scala 2.12.4 (Java HotSpot(TM) 64-Bit Server VM, Java 9).
 | 
|  |     26 | Type in expressions for evaluation. Or try :help.
 | 
|  |     27 | 
 | 
|  |     28 | scala>
 | 
|  |     29 | \end{lstlisting}%$
 | 
|  |     30 | 
 | 
|  |     31 | \noindent The precise response may vary depending
 | 
|  |     32 | on the version and platform where you installed Scala. At the Scala
 | 
|  |     33 | prompt you can type things like \code{2 + 3}\;\keys{Ret} and
 | 
|  |     34 | the output will be
 | 
|  |     35 | 
 | 
|  |     36 | \begin{lstlisting}[numbers=none]
 | 
|  |     37 | scala> 2 + 3
 | 
|  |     38 | res0: Int = 5
 | 
|  |     39 | \end{lstlisting}
 | 
|  |     40 | 
 | 
| 124 |     41 | \noindent indicating that the result of the addition is of type
 | 
|  |     42 | \code{Int} and the actual result is 5; \code{res0} is a name that
 | 
| 125 |     43 | Scala gives automatically to the result. You can reuse this name later
 | 
| 124 |     44 | on. Another classic example you can try out is
 | 
| 123 |     45 | 
 | 
|  |     46 | \begin{lstlisting}[numbers=none]
 | 
|  |     47 | scala> print("hello world")
 | 
|  |     48 | hello world
 | 
|  |     49 | \end{lstlisting}
 | 
|  |     50 | 
 | 
|  |     51 | \noindent Note that in this case there is no result. The
 | 
|  |     52 | reason is that \code{print} does not actually produce a result
 | 
| 124 |     53 | (there is no \code{resX} and no type), rather it is a
 | 
| 123 |     54 | function that causes the \emph{side-effect} of printing out a
 | 
|  |     55 | string. Once you are more familiar with the functional
 | 
|  |     56 | programming-style, you will know what the difference is
 | 
|  |     57 | between a function that returns a result, like addition, and a
 | 
|  |     58 | function that causes a side-effect, like \code{print}. We
 | 
|  |     59 | shall come back to this point later, but if you are curious
 | 
|  |     60 | now, the latter kind of functions always has \code{Unit} as
 | 
| 124 |     61 | return type. It is just not printed.
 | 
| 123 |     62 | 
 | 
|  |     63 | You can try more examples with the Scala interpreter, but try
 | 
|  |     64 | first to guess what the result is (not all answers by Scala are obvious):
 | 
|  |     65 | 
 | 
|  |     66 | \begin{lstlisting}[numbers=none]
 | 
|  |     67 | scala> 2 + 2
 | 
|  |     68 | scala> 1 / 2
 | 
|  |     69 | scala> 1.0 / 2
 | 
|  |     70 | scala> 1 / 2.0
 | 
|  |     71 | scala> 1 / 0
 | 
|  |     72 | scala> 1.0 / 0.0
 | 
|  |     73 | scala> true == false
 | 
|  |     74 | scala> true && false
 | 
|  |     75 | scala> 1 > 1.0
 | 
|  |     76 | scala> "12345".length
 | 
|  |     77 | \end{lstlisting}
 | 
|  |     78 | 
 | 
| 124 |     79 | \subsection*{Stand-Alone Scala Apps}
 | 
| 123 |     80 | 
 | 
|  |     81 | If you want to write a stand-alone app in Scala, you can
 | 
|  |     82 | implement an object that is an instance of \code{App}, say
 | 
|  |     83 | 
 | 
|  |     84 | \begin{lstlisting}[numbers=none]
 | 
|  |     85 | object Hello extends App {
 | 
|  |     86 |     println("hello world")
 | 
|  |     87 | }
 | 
|  |     88 | \end{lstlisting}
 | 
|  |     89 | 
 | 
| 124 |     90 | \noindent save it in a file, for example {\tt hello-world.scala}, and
 | 
| 123 |     91 | then run the compiler and runtime environment:
 | 
|  |     92 | 
 | 
|  |     93 | \begin{lstlisting}[language={},numbers=none,basicstyle=\ttfamily\small]
 | 
|  |     94 | $ scalac hello-world.scala
 | 
|  |     95 | $ scala Hello
 | 
|  |     96 | hello world
 | 
|  |     97 | \end{lstlisting}
 | 
|  |     98 | 
 | 
| 124 |     99 | \noindent
 | 
| 123 |    100 | Like Java, Scala targets the JVM and consequently
 | 
|  |    101 | Scala programs can also be executed by the bog-standard Java
 | 
|  |    102 | Runtime. This only requires the inclusion of {\tt
 | 
|  |    103 | scala-library.jar}, which on my computer can be done as
 | 
|  |    104 | follows:
 | 
|  |    105 | 
 | 
|  |    106 | \begin{lstlisting}[language={},numbers=none,basicstyle=\ttfamily\small]
 | 
|  |    107 | $ scalac hello-world.scala
 | 
|  |    108 | $ java -cp /usr/local/src/scala/lib/scala-library.jar:. Hello
 | 
|  |    109 | hello world
 | 
|  |    110 | \end{lstlisting}
 | 
|  |    111 | 
 | 
|  |    112 | \noindent You might need to adapt the path to where you have
 | 
|  |    113 | installed Scala.
 | 
|  |    114 | 
 | 
|  |    115 | \subsection*{Values}
 | 
|  |    116 | 
 | 
| 124 |    117 | In the lectures I will try to avoid as much as possible the term
 | 
|  |    118 | \emph{variables} familiar from other programming languages. The reason
 | 
|  |    119 | is that Scala has \emph{values}, which can be seen as abbreviations of
 | 
|  |    120 | larger expressions. For example
 | 
| 123 |    121 | 
 | 
|  |    122 | \begin{lstlisting}[numbers=none]
 | 
|  |    123 | scala> val x = 42
 | 
|  |    124 | x: Int = 42
 | 
|  |    125 | 
 | 
|  |    126 | scala> val y = 3 + 4
 | 
|  |    127 | y: Int = 7
 | 
|  |    128 | 
 | 
|  |    129 | scala> val z = x / y
 | 
|  |    130 | z: Int = 6
 | 
|  |    131 | \end{lstlisting}
 | 
|  |    132 | 
 | 
|  |    133 | \noindent
 | 
|  |    134 | Why the kerfuffle about values? Well, values are \emph{immutable}. You cannot
 | 
| 124 |    135 | change their value after you defined them. If you try to reassign
 | 
|  |    136 | \code{z} above, Scala will yell at you:
 | 
| 123 |    137 | 
 | 
|  |    138 | \begin{lstlisting}[numbers=none]
 | 
|  |    139 | scala> z = 9
 | 
|  |    140 | error: reassignment to val
 | 
|  |    141 |        z = 9
 | 
|  |    142 |          ^
 | 
|  |    143 | \end{lstlisting}
 | 
|  |    144 | 
 | 
|  |    145 | \noindent
 | 
|  |    146 | So it would be a bit absurd to call values as variables...you cannot
 | 
|  |    147 | change them. You might think you can re-assign them like
 | 
|  |    148 | 
 | 
|  |    149 | \begin{lstlisting}[numbers=none]
 | 
|  |    150 | scala> val x = 42
 | 
|  |    151 | scala> val z = x / 7
 | 
|  |    152 | scala> val x = 70
 | 
|  |    153 | scala> println(z) 
 | 
|  |    154 | \end{lstlisting}
 | 
|  |    155 | 
 | 
| 124 |    156 | \noindent but try to guess what Scala will print out 
 | 
| 123 |    157 | for \code{z}?  Will it be \code{6} or \code{10}? A final word about
 | 
|  |    158 | values: Try to stick to the convention that names of values should be
 | 
|  |    159 | lower case, like \code{x}, \code{y}, \code{foo41} and so on.
 | 
|  |    160 | 
 | 
|  |    161 | 
 | 
|  |    162 | \subsection*{Function Definitions}
 | 
|  |    163 | 
 | 
| 124 |    164 | We do functional programming. So defining functions will be our main occupation.
 | 
|  |    165 | A function \code{f} taking a single argument of type \code{Int} can be defined in Scala
 | 
| 123 |    166 | as follows:
 | 
|  |    167 | 
 | 
|  |    168 | \begin{lstlisting}[numbers=none]
 | 
|  |    169 | def f(x: Int) : String = EXPR
 | 
|  |    170 | \end{lstlisting} 
 | 
|  |    171 | 
 | 
|  |    172 | \noindent
 | 
| 124 |    173 | This function returns the value resulting from evaluating the expression
 | 
| 123 |    174 | \code{EXPR} (whatever is substituted for this). The result will be
 | 
| 124 |    175 | of type \code{String}. It is a good habbit to include this information
 | 
|  |    176 | about the return type always. Simple examples of Scala functions are:
 | 
| 123 |    177 | 
 | 
|  |    178 | \begin{lstlisting}[numbers=none]
 | 
|  |    179 | def incr(x: Int) : Int = x + 1
 | 
|  |    180 | def double(x: Int) : Int = x + x
 | 
|  |    181 | def square(x: Int) : Int = x * x
 | 
|  |    182 | \end{lstlisting}
 | 
|  |    183 | 
 | 
|  |    184 | \noindent
 | 
|  |    185 | The general scheme for a function is
 | 
|  |    186 | 
 | 
|  |    187 | \begin{lstlisting}[numbers=none]
 | 
|  |    188 | def fname(arg1: ty1, arg2: ty2,..., argn: tyn): rty = {
 | 
|  |    189 |   BODY
 | 
|  |    190 | }
 | 
|  |    191 | \end{lstlisting}
 | 
|  |    192 | 
 | 
|  |    193 | \noindent
 | 
|  |    194 | where each argument requires its type and the result type of the
 | 
| 124 |    195 | function, \code{rty}, should be given. If the body of the function is
 | 
|  |    196 | more complex, then it can be enclosed in braces, like above. If it it
 | 
|  |    197 | is just a simple expression, like \code{x + 1}, you can omit the
 | 
|  |    198 | braces. Very often functions are recursive (call themselves) like
 | 
|  |    199 | the venerable factorial function.
 | 
| 123 |    200 | 
 | 
|  |    201 | \begin{lstlisting}[numbers=none]
 | 
|  |    202 | def fact(n: Int): Int = 
 | 
|  |    203 |   if (n == 0) 1 else n * fact(n - 1)
 | 
|  |    204 | \end{lstlisting}
 | 
|  |    205 |   
 | 
|  |    206 | \subsection*{Loops, or better the Absence thereof}
 | 
|  |    207 | 
 | 
|  |    208 | Coming from Java or C++, you might be surprised that Scala does
 | 
|  |    209 | not really have loops. It has instead, what is in functional
 | 
|  |    210 | programming called, \emph{maps}. To illustrate how they work,
 | 
|  |    211 | let us assume you have a list of numbers from 1 to 8 and want to
 | 
|  |    212 | build the list of squares. The list of numbers from 1 to 8 
 | 
|  |    213 | can be constructed in Scala as follows:
 | 
|  |    214 | 
 | 
|  |    215 | \begin{lstlisting}[numbers=none]
 | 
|  |    216 | scala> (1 to 8).toList
 | 
|  |    217 | res1: List[Int] = List(1, 2, 3, 4, 5, 6, 7, 8)
 | 
|  |    218 | \end{lstlisting}
 | 
|  |    219 | 
 | 
|  |    220 | \noindent Generating from this list, the list of squares in a
 | 
|  |    221 | programming language such as Java, you would assume the list
 | 
|  |    222 | is given as a kind of array. You would then iterate, or loop,
 | 
|  |    223 | an index over this array and replace each entry in the array
 | 
|  |    224 | by the square. Right? In Scala, and in other functional
 | 
|  |    225 | programming languages, you use maps to achieve the same. 
 | 
|  |    226 | 
 | 
|  |    227 | A map essentially takes a function that describes how each
 | 
|  |    228 | element is transformed (for example squared) and a list over
 | 
|  |    229 | which this function should work. There are two forms to
 | 
|  |    230 | express such maps in Scala. The first way is called a
 | 
|  |    231 | \emph{for-comprehension}. Squaring the numbers from 1 to 8
 | 
|  |    232 | would look as follows:
 | 
|  |    233 | 
 | 
|  |    234 | \begin{lstlisting}[numbers=none]
 | 
|  |    235 | scala> for (n <- (1 to 8).toList) yield n * n
 | 
|  |    236 | res2: List[Int] = List(1, 4, 9, 16, 25, 36, 49, 64)
 | 
|  |    237 | \end{lstlisting}
 | 
|  |    238 | 
 | 
|  |    239 | \noindent The important keywords are \code{for} and
 | 
|  |    240 | \code{yield}. This for-comprehension roughly states that from
 | 
|  |    241 | the list of numbers we draw \code{n}s and compute the result
 | 
|  |    242 | of \code{n * n}. As you can see, we specified the list where
 | 
|  |    243 | each \code{n} comes from, namely \code{(1 to 8).toList}, and
 | 
|  |    244 | how each element needs to be transformed. This can also be
 | 
|  |    245 | expressed in a second way in Scala by using directly
 | 
|  |    246 | \code{map}s as follows:
 | 
|  |    247 | 
 | 
|  |    248 | \begin{lstlisting}[numbers=none]
 | 
|  |    249 | scala> (1 to 8).toList.map(n => n * n)
 | 
|  |    250 | res3 = List(1, 4, 9, 16, 25, 36, 49, 64)
 | 
|  |    251 | \end{lstlisting}
 | 
|  |    252 | 
 | 
|  |    253 | \noindent In this way, the expression \code{n => n * n} stands
 | 
|  |    254 | for the function that calculates the square (this is how the
 | 
|  |    255 | \code{n}s are transformed). This expression for functions
 | 
|  |    256 | might remind you of your lessons about the lambda-calculus
 | 
|  |    257 | where this would have been written as $\lambda n.\,n * n$. It
 | 
|  |    258 | might not be obvious, but for-comprehensions are just
 | 
|  |    259 | syntactic sugar: when compiling, Scala translates
 | 
|  |    260 | for-comprehensions into equivalent maps. This even works
 | 
|  |    261 | when for-comprehensions get more complicated (see below).
 | 
|  |    262 | 
 | 
|  |    263 | The very charming feature of Scala is that such maps or
 | 
|  |    264 | for-comprehensions can be written for any kind of data
 | 
|  |    265 | collection, such as lists, sets, vectors, options and so on.
 | 
|  |    266 | For example if we instead compute the reminders modulo 3 of
 | 
|  |    267 | this list, we can write
 | 
|  |    268 | 
 | 
|  |    269 | \begin{lstlisting}[numbers=none]
 | 
|  |    270 | scala> (1 to 8).toList.map(n => n % 3)
 | 
|  |    271 | res4 = List(1, 2, 0, 1, 2, 0, 1, 2)
 | 
|  |    272 | \end{lstlisting}
 | 
|  |    273 | 
 | 
|  |    274 | \noindent If we, however, transform the numbers 1 to 8 not
 | 
|  |    275 | into a list, but into a set, and then compute the reminders
 | 
|  |    276 | modulo 3 we obtain
 | 
|  |    277 | 
 | 
|  |    278 | \begin{lstlisting}[numbers=none]
 | 
|  |    279 | scala> (1 to 8).toSet[Int].map(n => n % 3)
 | 
|  |    280 | res5 = Set(2, 1, 0)
 | 
|  |    281 | \end{lstlisting}
 | 
|  |    282 | 
 | 
|  |    283 | \noindent This is the correct result for sets, as there are
 | 
|  |    284 | only three equivalence classes of integers modulo 3. Note that
 | 
|  |    285 | in this example we need to ``help'' Scala to transform the
 | 
|  |    286 | numbers into a set of integers by explicitly annotating the
 | 
|  |    287 | type \code{Int}. Since maps and for-comprehensions are
 | 
|  |    288 | just syntactic variants of each other, the latter can also be
 | 
|  |    289 | written as
 | 
|  |    290 | 
 | 
|  |    291 | \begin{lstlisting}[numbers=none]
 | 
|  |    292 | scala> for (n <- (1 to 8).toSet[Int]) yield n % 3
 | 
|  |    293 | res5 = Set(2, 1, 0)
 | 
|  |    294 | \end{lstlisting}
 | 
|  |    295 | 
 | 
|  |    296 | For-comprehensions can also be nested and the selection of 
 | 
|  |    297 | elements can be guarded. For example if we want to pair up
 | 
|  |    298 | the numbers 1 to 4 with the letters a to c, we can write
 | 
|  |    299 | 
 | 
|  |    300 | \begin{lstlisting}[numbers=none]
 | 
|  |    301 | scala> for (n <- (1 to 4).toList; 
 | 
|  |    302 |             m <- ('a' to 'c').toList) yield (n, m)
 | 
|  |    303 | res6 = List((1,a), (1,b), (1,c), (2,a), (2,b), (2,c), 
 | 
|  |    304 |             (3,a), (3,b), (3,c), (4,a), (4,b), (4,c))
 | 
|  |    305 | \end{lstlisting}
 | 
|  |    306 | 
 | 
|  |    307 | \noindent 
 | 
|  |    308 | Or if we want to find all pairs of numbers between 1 and 3
 | 
|  |    309 | where the sum is an even number, we can write
 | 
|  |    310 | 
 | 
|  |    311 | \begin{lstlisting}[numbers=none]
 | 
|  |    312 | scala> for (n <- (1 to 3).toList; 
 | 
|  |    313 |             m <- (1 to 3).toList;
 | 
|  |    314 |             if (n + m) % 2 == 0) yield (n, m)
 | 
|  |    315 | res7 = List((1,1), (1,3), (2,2), (3,1), (3,3))
 | 
|  |    316 | \end{lstlisting}
 | 
|  |    317 | 
 | 
|  |    318 | \noindent The \code{if}-condition in the for-comprehension
 | 
|  |    319 | filters out all pairs where the sum is not even.
 | 
|  |    320 | 
 | 
|  |    321 | While hopefully this all looks reasonable, there is one
 | 
|  |    322 | complication: In the examples above we always wanted to
 | 
|  |    323 | transform one list into another list (e.g.~list of squares),
 | 
|  |    324 | or one set into another set (set of numbers into set of
 | 
|  |    325 | reminders modulo 3). What happens if we just want to print out
 | 
|  |    326 | a list of integers? Then actually the for-comprehension
 | 
|  |    327 | needs to be modified. The reason is that \code{print}, you
 | 
|  |    328 | guessed it, does not produce any result, but only produces
 | 
|  |    329 | what is in the functional-programming-lingo called a
 | 
|  |    330 | side-effect. Printing out the list of numbers from 1 to 5
 | 
|  |    331 | would look as follows
 | 
|  |    332 | 
 | 
|  |    333 | \begin{lstlisting}[numbers=none]
 | 
|  |    334 | scala> for (n <- (1 to 5).toList) print(n)
 | 
|  |    335 | 12345
 | 
|  |    336 | \end{lstlisting}
 | 
|  |    337 | 
 | 
|  |    338 | \noindent
 | 
|  |    339 | where you need to omit the keyword \code{yield}. You can
 | 
|  |    340 | also do more elaborate calculations such as
 | 
|  |    341 | 
 | 
|  |    342 | \begin{lstlisting}[numbers=none]
 | 
|  |    343 | scala> for (n <- (1 to 5).toList) {
 | 
|  |    344 |   val square_n = n * n
 | 
|  |    345 |   println(s"$n * $n = $square_n") 
 | 
|  |    346 | }
 | 
|  |    347 | 1 * 1 = 1
 | 
|  |    348 | 2 * 2 = 4
 | 
|  |    349 | 3 * 3 = 9
 | 
|  |    350 | 4 * 4 = 16
 | 
|  |    351 | 5 * 5 = 25
 | 
|  |    352 | \end{lstlisting}%$
 | 
|  |    353 | 
 | 
|  |    354 | \noindent In this code I use a variable assignment (\code{val
 | 
|  |    355 | square_n = ...} ) and also what is called in Scala a
 | 
|  |    356 | \emph{string interpolation}, written \code{s"..."}. The latter
 | 
|  |    357 | is for printing out an equation. It allows me to refer to the
 | 
|  |    358 | integer values \code{n} and \code{square\_n} inside a string.
 | 
|  |    359 | This is very convenient for printing out ``things''. 
 | 
|  |    360 | 
 | 
|  |    361 | The corresponding map construction for functions with 
 | 
|  |    362 | side-effects is in Scala called \code{foreach}. So you 
 | 
|  |    363 | could also write
 | 
|  |    364 | 
 | 
|  |    365 | 
 | 
|  |    366 | \begin{lstlisting}[numbers=none]
 | 
|  |    367 | scala> (1 to 5).toList.foreach(n => print(n))
 | 
|  |    368 | 12345
 | 
|  |    369 | \end{lstlisting}
 | 
|  |    370 | 
 | 
|  |    371 | 
 | 
|  |    372 | \noindent or even just
 | 
|  |    373 | 
 | 
|  |    374 | \begin{lstlisting}[numbers=none]
 | 
|  |    375 | scala> (1 to 5).toList.foreach(print)
 | 
|  |    376 | 12345
 | 
|  |    377 | \end{lstlisting}
 | 
|  |    378 | 
 | 
|  |    379 | \noindent Again I hope this reminds you a bit of your
 | 
|  |    380 | lambda-calculus lessons, where an explanation is given why
 | 
|  |    381 | both forms produce the same result.
 | 
|  |    382 | 
 | 
|  |    383 | 
 | 
|  |    384 | If you want to find out more about maps and functions with
 | 
|  |    385 | side-effects, you can ponder about the response Scala gives if
 | 
|  |    386 | you replace \code{foreach} by \code{map} in the expression
 | 
|  |    387 | above. Scala will still allow \code{map} with side-effect
 | 
|  |    388 | functions, but then reacts with a slightly interesting result.
 | 
|  |    389 | 
 | 
|  |    390 | \subsection*{Types}
 | 
|  |    391 | 
 | 
|  |    392 | In most functional programming languages, types play an
 | 
|  |    393 | important role. Scala is such a language. You have already
 | 
|  |    394 | seen built-in types, like \code{Int}, \code{Boolean},
 | 
|  |    395 | \code{String} and \code{BigInt}, but also user-defined ones,
 | 
|  |    396 | like \code{Rexp}. Unfortunately, types can be a thorny
 | 
|  |    397 | subject, especially in Scala. For example, why do we need to
 | 
|  |    398 | give the type to \code{toSet[Int]}, but not to \code{toList}?
 | 
|  |    399 | The reason is the power of Scala, which sometimes means it
 | 
|  |    400 | cannot infer all necessary typing information. At the
 | 
|  |    401 | beginning while getting familiar with Scala, I recommend a
 | 
|  |    402 | ``play-it-by-ear-approach'' to types. Fully understanding
 | 
|  |    403 | type-systems, especially complicated ones like in Scala, can
 | 
|  |    404 | take a module on their own.\footnote{Still, such a study can
 | 
|  |    405 | be a rewarding training: If you are in the business of
 | 
|  |    406 | designing new programming languages, you will not be able to
 | 
|  |    407 | turn a blind eye to types. They essentially help programmers
 | 
|  |    408 | to avoid common programming errors and help with maintaining
 | 
|  |    409 | code.}
 | 
|  |    410 | 
 | 
|  |    411 | In Scala, types are needed whenever you define an inductive
 | 
|  |    412 | datatype and also whenever you define functions (their
 | 
|  |    413 | arguments and their results need a type). Base types are types
 | 
|  |    414 | that do not take any (type)arguments, for example \code{Int}
 | 
|  |    415 | and \code{String}. Compound types take one or more arguments,
 | 
|  |    416 | which as seen earlier need to be given in angle-brackets, for
 | 
|  |    417 | example \code{List[Int]} or \code{Set[List[String]]} or 
 | 
|  |    418 | \code{Map[Int, Int]}.
 | 
|  |    419 | 
 | 
|  |    420 | There are a few special type-constructors that fall outside
 | 
|  |    421 | this pattern. One is for tuples, where the type is written
 | 
|  |    422 | with parentheses. For example 
 | 
|  |    423 | 
 | 
|  |    424 | \begin{lstlisting}[ numbers=none]
 | 
|  |    425 | (Int, Int, String)
 | 
|  |    426 | \end{lstlisting}
 | 
|  |    427 | 
 | 
|  |    428 | \noindent is for a triple (a tuple with three components---two
 | 
|  |    429 | integers and a string). Tuples are helpful if you want to
 | 
|  |    430 | define functions with multiple results, say the function
 | 
|  |    431 | returning the quotient and reminder of two numbers. For this
 | 
|  |    432 | you might define:
 | 
|  |    433 | 
 | 
|  |    434 | 
 | 
|  |    435 | \begin{lstlisting}[ numbers=none]
 | 
|  |    436 | def quo_rem(m: Int, n: Int) : (Int, Int) = (m / n, m % n)
 | 
|  |    437 | \end{lstlisting}
 | 
|  |    438 | 
 | 
|  |    439 | 
 | 
|  |    440 | \noindent Since this function returns a pair of integers, its
 | 
|  |    441 | return type needs to be of type \code{(Int, Int)}.
 | 
|  |    442 | Incidentally, this is also the input type of this function.
 | 
|  |    443 | Notice this function takes \emph{two} arguments, namely
 | 
|  |    444 | \code{m} and \code{n}, both of which are integers. They are
 | 
|  |    445 | ``packaged'' in a pair. Consequently the complete type of
 | 
|  |    446 | \code{quo_rem} is
 | 
|  |    447 | 
 | 
|  |    448 | \begin{lstlisting}[ numbers=none]
 | 
|  |    449 | (Int, Int) => (Int, Int)
 | 
|  |    450 | \end{lstlisting}
 | 
|  |    451 | 
 | 
|  |    452 | Another special type-constructor is for functions, written as
 | 
|  |    453 | the arrow \code{=>}. For example, the type \code{Int =>
 | 
|  |    454 | String} is for a function that takes an integer as input
 | 
|  |    455 | argument and produces a string as result. A function of this
 | 
|  |    456 | type is for instance
 | 
|  |    457 | 
 | 
|  |    458 | \begin{lstlisting}[numbers=none]
 | 
|  |    459 | def mk_string(n: Int) : String = n match {
 | 
|  |    460 |   case 0 => "zero"
 | 
|  |    461 |   case 1 => "one"
 | 
|  |    462 |   case 2 => "two"
 | 
|  |    463 |   case _ => "many" 
 | 
|  |    464 | } 
 | 
|  |    465 | \end{lstlisting}
 | 
|  |    466 | 
 | 
|  |    467 | \noindent It takes an integer as input argument and returns a
 | 
|  |    468 | string. Unlike other functional programming languages, there
 | 
|  |    469 | is in Scala no easy way to find out the types of existing
 | 
|  |    470 | functions, except by looking into the documentation
 | 
|  |    471 | 
 | 
|  |    472 | \begin{quote}
 | 
|  |    473 | \url{http://www.scala-lang.org/api/current/}
 | 
|  |    474 | \end{quote}
 | 
|  |    475 | 
 | 
|  |    476 | The function arrow can also be iterated, as in 
 | 
|  |    477 | \code{Int => String => Boolean}. This is the type for a function
 | 
|  |    478 | taking an integer as first argument and a string as second,
 | 
|  |    479 | and the result of the function is a boolean. Though silly, a
 | 
|  |    480 | function of this type would be
 | 
|  |    481 | 
 | 
|  |    482 | 
 | 
|  |    483 | \begin{lstlisting}[numbers=none]
 | 
|  |    484 | def chk_string(n: Int)(s: String) : Boolean = 
 | 
|  |    485 |   mk_string(n) == s
 | 
|  |    486 | \end{lstlisting}
 | 
|  |    487 | 
 | 
|  |    488 | 
 | 
|  |    489 | \noindent which checks whether the integer \code{n}
 | 
|  |    490 | corresponds to the name \code{s} given by the function
 | 
|  |    491 | \code{mk\_string}. Notice the unusual way of specifying the
 | 
|  |    492 | arguments of this function: the arguments are given one after
 | 
|  |    493 | the other, instead of being in a pair (what would be the type
 | 
|  |    494 | of this function then?). This way of specifying the arguments
 | 
|  |    495 | can be useful, for example in situations like this
 | 
|  |    496 | 
 | 
|  |    497 | \begin{lstlisting}[numbers=none]
 | 
|  |    498 | scala> List("one", "two", "three", "many").map(chk_string(2))
 | 
|  |    499 | res4 = List(false, true, false, false)
 | 
|  |    500 | 
 | 
|  |    501 | scala> List("one", "two", "three", "many").map(chk_string(3))
 | 
|  |    502 | res5 = List(false, false, false, true)
 | 
|  |    503 | \end{lstlisting}
 | 
|  |    504 | 
 | 
|  |    505 | \noindent In each case we can give to \code{map} a specialised
 | 
|  |    506 | version of \code{chk_string}---once specialised to 2 and once
 | 
|  |    507 | to 3. This kind of ``specialising'' a function is called
 | 
|  |    508 | \emph{partial application}---we have not yet given to this
 | 
|  |    509 | function all arguments it needs, but only some of them.
 | 
|  |    510 | 
 | 
|  |    511 | Coming back to the type \code{Int => String => Boolean}. The
 | 
|  |    512 | rule about such function types is that the right-most type
 | 
|  |    513 | specifies what the function returns (a boolean in this case).
 | 
|  |    514 | The types before that specify how many arguments the function
 | 
|  |    515 | expects and what their type is (in this case two arguments,
 | 
|  |    516 | one of type \code{Int} and another of type \code{String}).
 | 
|  |    517 | Given this rule, what kind of function has type
 | 
|  |    518 | \mbox{\code{(Int => String) => Boolean}}? Well, it returns a
 | 
|  |    519 | boolean. More interestingly, though, it only takes a single
 | 
|  |    520 | argument (because of the parentheses). The single argument
 | 
|  |    521 | happens to be another function (taking an integer as input and
 | 
|  |    522 | returning a string). Remember that \code{mk_string} is just 
 | 
|  |    523 | such a function. So how can we use it? For this define
 | 
|  |    524 | the somewhat silly function \code{apply_3}:
 | 
|  |    525 | 
 | 
|  |    526 | \begin{lstlisting}[numbers=none]
 | 
|  |    527 | def apply_3(f: Int => String): Bool = f(3) == "many"
 | 
|  |    528 | 
 | 
|  |    529 | scala> apply_3(mk_string)
 | 
|  |    530 | res6 = true
 | 
|  |    531 | \end{lstlisting}
 | 
|  |    532 | 
 | 
|  |    533 | You might ask: Apart from silly functions like above, what is
 | 
|  |    534 | the point of having functions as input arguments to other
 | 
|  |    535 | functions? In Java there is indeed no need of this kind of
 | 
|  |    536 | feature: at least in the past it did not allow such
 | 
|  |    537 | constructions. I think, the point of Java 8 is to lift this
 | 
|  |    538 | restriction. But in all functional programming languages,
 | 
|  |    539 | including Scala, it is really essential to allow functions as
 | 
|  |    540 | input argument. Above you already seen \code{map} and
 | 
|  |    541 | \code{foreach} which need this. Consider the functions
 | 
|  |    542 | \code{print} and \code{println}, which both print out strings,
 | 
|  |    543 | but the latter adds a line break. You can call \code{foreach}
 | 
|  |    544 | with either of them and thus changing how, for example, five
 | 
|  |    545 | numbers are printed.
 | 
|  |    546 | 
 | 
|  |    547 | 
 | 
|  |    548 | \begin{lstlisting}[numbers=none]
 | 
|  |    549 | scala> (1 to 5).toList.foreach(print)
 | 
|  |    550 | 12345
 | 
|  |    551 | scala> (1 to 5).toList.foreach(println)
 | 
|  |    552 | 1
 | 
|  |    553 | 2
 | 
|  |    554 | 3
 | 
|  |    555 | 4
 | 
|  |    556 | 5
 | 
|  |    557 | \end{lstlisting}
 | 
|  |    558 | 
 | 
|  |    559 | 
 | 
|  |    560 | \noindent This is actually one of the main design principles
 | 
|  |    561 | in functional programming. You have generic functions like
 | 
|  |    562 | \code{map} and \code{foreach} that can traverse data containers,
 | 
|  |    563 | like lists or sets. They then take a function to specify what
 | 
|  |    564 | should be done with each element during the traversal. This
 | 
|  |    565 | requires that the generic traversal functions can cope with
 | 
|  |    566 | any kind of function (not just functions that, for example,
 | 
|  |    567 | take as input an integer and produce a string like above).
 | 
|  |    568 | This means we cannot fix the type of the generic traversal
 | 
|  |    569 | functions, but have to keep them
 | 
|  |    570 | \emph{polymorphic}.\footnote{Another interestic topic about
 | 
|  |    571 | types, but we omit it here for the sake of brevity.} 
 | 
|  |    572 | 
 | 
|  |    573 | There is one more type constructor that is rather special. It
 | 
|  |    574 | is called \code{Unit}. Recall that \code{Boolean} has two
 | 
|  |    575 | values, namely \code{true} and \code{false}. This can be used,
 | 
|  |    576 | for example, to test something and decide whether the test
 | 
|  |    577 | succeeds or not. In contrast the type \code{Unit} has only a
 | 
|  |    578 | single value, written \code{()}. This seems like a completely
 | 
|  |    579 | useless type and return value for a function, but is actually
 | 
|  |    580 | quite useful. It indicates when the function does not return
 | 
|  |    581 | any result. The purpose of these functions is to cause
 | 
|  |    582 | something being written on the screen or written into a file,
 | 
|  |    583 | for example. This is what is called they cause some effect on 
 | 
|  |    584 | the side, namely a new content displayed on the screen or some
 | 
|  |    585 | new data in a file. Scala uses the \code{Unit} type to indicate
 | 
|  |    586 | that a function does not have a result, but potentially causes
 | 
|  |    587 | some side-effect. Typical examples are the printing functions, 
 | 
|  |    588 | like \code{print}.
 | 
|  |    589 | 
 | 
|  |    590 | 
 | 
| 143 |    591 | % \subsection*{Cool Stuff}
 | 
| 123 |    592 | 
 | 
| 143 |    593 | % The first wow-moment I had with Scala was when I came across
 | 
|  |    594 | % the following code-snippet for reading a web-page. 
 | 
| 123 |    595 | 
 | 
|  |    596 | 
 | 
| 143 |    597 | % \begin{lstlisting}[ numbers=none]
 | 
|  |    598 | % import io.Source
 | 
|  |    599 | % val url = """http://www.inf.kcl.ac.uk/staff/urbanc/"""
 | 
|  |    600 | % Source.fromURL(url)("ISO-8859-1").take(10000).mkString
 | 
|  |    601 | % \end{lstlisting}
 | 
| 123 |    602 | 
 | 
|  |    603 | 
 | 
| 143 |    604 | % \noindent These three lines return a string containing the
 | 
|  |    605 | % HTML-code of my webpage. It actually already does something
 | 
|  |    606 | % more sophisticated, namely only returns the first 10000
 | 
|  |    607 | % characters of a webpage in case it is too large. Why is that
 | 
|  |    608 | % code-snippet of any interest? Well, try implementing
 | 
|  |    609 | % reading-from-a-webpage in Java. I also like the possibility of
 | 
|  |    610 | % triple-quoting strings, which I have only seen in Scala so
 | 
|  |    611 | % far. The idea behind this is that in such a string all
 | 
|  |    612 | % characters are interpreted literally---there are no escaped
 | 
|  |    613 | % characters, like \verb|\n| for newlines.
 | 
| 123 |    614 | 
 | 
| 143 |    615 | % My second wow-moment I had with a feature of Scala that other
 | 
|  |    616 | % functional programming languages do not have. This feature is
 | 
|  |    617 | % about implicit type conversions. If you have regular
 | 
|  |    618 | % expressions and want to use them for language processing you
 | 
|  |    619 | % often want to recognise keywords in a language, for example
 | 
|  |    620 | % \code{for},{} \code{if},{} \code{yield} and so on. But the
 | 
|  |    621 | % basic regular expression \code{CHAR} can only recognise a
 | 
|  |    622 | % single character. In order to recognise a whole string, like
 | 
|  |    623 | % \code{for}, you have to put many of those together using
 | 
|  |    624 | % \code{SEQ}:
 | 
| 123 |    625 | 
 | 
|  |    626 | 
 | 
| 143 |    627 | % \begin{lstlisting}[numbers=none]
 | 
|  |    628 | % SEQ(CHAR('f'), SEQ(CHAR('o'), CHAR('r')))
 | 
|  |    629 | % \end{lstlisting}
 | 
| 123 |    630 | 
 | 
| 143 |    631 | % \noindent This gets quickly unreadable when the strings and
 | 
|  |    632 | % regular expressions get more complicated. In other functional
 | 
|  |    633 | % programming languages, you can explicitly write a conversion
 | 
|  |    634 | % function that takes a string, say \dq{\pcode{for}}, and
 | 
|  |    635 | % generates the regular expression above. But then your code is
 | 
|  |    636 | % littered with such conversion functions.
 | 
| 123 |    637 | 
 | 
| 143 |    638 | % In Scala you can do better by ``hiding'' the conversion
 | 
|  |    639 | % functions. The keyword for doing this is \code{implicit} and
 | 
|  |    640 | % it needs a built-in library called 
 | 
| 123 |    641 | 
 | 
| 143 |    642 | % \begin{lstlisting}[numbers=none]
 | 
|  |    643 | % scala.language.implicitConversions
 | 
|  |    644 | % \end{lstlisting}
 | 
| 123 |    645 | 
 | 
| 143 |    646 | % \noindent
 | 
|  |    647 | % Consider the code
 | 
| 123 |    648 | 
 | 
|  |    649 | 
 | 
| 143 |    650 | % \begin{lstlisting}[language=Scala]
 | 
|  |    651 | % import scala.language.implicitConversions
 | 
| 123 |    652 | 
 | 
| 143 |    653 | % def charlist2rexp(s: List[Char]) : Rexp = s match {
 | 
|  |    654 | %   case Nil => EMPTY
 | 
|  |    655 | %   case c::Nil => CHAR(c)
 | 
|  |    656 | %   case c::s => SEQ(CHAR(c), charlist2rexp(s))
 | 
|  |    657 | % }
 | 
| 123 |    658 | 
 | 
| 143 |    659 | % implicit def string2rexp(s: String) : Rexp = 
 | 
|  |    660 | %   charlist2rexp(s.toList)
 | 
|  |    661 | % \end{lstlisting}
 | 
| 123 |    662 | 
 | 
|  |    663 | 
 | 
| 143 |    664 | % \noindent where the first seven lines implement a function
 | 
|  |    665 | % that given a list of characters generates the corresponding
 | 
|  |    666 | % regular expression. In Lines 9 and 10, this function is used
 | 
|  |    667 | % for transforming a string into a regular expression. Since the
 | 
|  |    668 | % \code{string2rexp}-function is declared as \code{implicit},
 | 
|  |    669 | % the effect will be that whenever Scala expects a regular
 | 
|  |    670 | % expression, but I only give it a string, it will automatically
 | 
|  |    671 | % insert a call to the \code{string2rexp}-function. I can now
 | 
|  |    672 | % write for example
 | 
| 123 |    673 | 
 | 
| 143 |    674 | % \begin{lstlisting}[numbers=none]
 | 
|  |    675 | % scala> ALT("ab", "ac")
 | 
|  |    676 | % res9 = ALT(SEQ(CHAR(a),CHAR(b)),SEQ(CHAR(a),CHAR(c)))
 | 
|  |    677 | % \end{lstlisting}
 | 
| 123 |    678 | 
 | 
| 143 |    679 | % \noindent Recall that \code{ALT} expects two regular
 | 
|  |    680 | % expressions as arguments, but I only supply two strings. The
 | 
|  |    681 | % implicit conversion function will transform the string into a
 | 
|  |    682 | % regular expression.
 | 
| 123 |    683 | 
 | 
| 143 |    684 | % Using implicit definitions, Scala allows me to introduce
 | 
|  |    685 | % some further syntactic sugar for regular expressions:
 | 
| 123 |    686 | 
 | 
|  |    687 | 
 | 
| 143 |    688 | % \begin{lstlisting}[ numbers=none]
 | 
|  |    689 | % implicit def RexpOps(r: Rexp) = new {
 | 
|  |    690 | %   def | (s: Rexp) = ALT(r, s)
 | 
|  |    691 | %   def ~ (s: Rexp) = SEQ(r, s)
 | 
|  |    692 | %   def % = STAR(r)
 | 
|  |    693 | % }
 | 
| 123 |    694 | 
 | 
| 143 |    695 | % implicit def stringOps(s: String) = new {
 | 
|  |    696 | %   def | (r: Rexp) = ALT(s, r)
 | 
|  |    697 | %   def | (r: String) = ALT(s, r)
 | 
|  |    698 | %   def ~ (r: Rexp) = SEQ(s, r)
 | 
|  |    699 | %   def ~ (r: String) = SEQ(s, r)
 | 
|  |    700 | %   def % = STAR(s)
 | 
|  |    701 | % }
 | 
|  |    702 | % \end{lstlisting}
 | 
| 123 |    703 | 
 | 
|  |    704 |  
 | 
| 143 |    705 | % \noindent This might seem a bit overly complicated, but its effect is
 | 
|  |    706 | % that I can now write regular expressions such as $ab + ac$ 
 | 
|  |    707 | % simply as
 | 
| 123 |    708 | 
 | 
|  |    709 | 
 | 
| 143 |    710 | % \begin{lstlisting}[numbers=none]
 | 
|  |    711 | % scala> "ab" | "ac"
 | 
|  |    712 | % res10 = ALT(SEQ(CHAR(a),CHAR(b)),SEQ(CHAR(a),CHAR(c)))
 | 
|  |    713 | % \end{lstlisting}
 | 
| 123 |    714 | 
 | 
|  |    715 |  
 | 
| 143 |    716 | % \noindent I leave you to figure out what the other
 | 
|  |    717 | % syntactic sugar in the code above stands for.
 | 
| 123 |    718 |  
 | 
| 143 |    719 | % One more useful feature of Scala is the ability to define
 | 
|  |    720 | % functions with varying argument lists. This is a feature that
 | 
|  |    721 | % is already present in old languages, like C, but seems to have
 | 
|  |    722 | % been forgotten in the meantime---Java does not have it. In the
 | 
|  |    723 | % context of regular expressions this feature comes in handy:
 | 
|  |    724 | % Say you are fed up with writing many alternatives as
 | 
| 123 |    725 | 
 | 
|  |    726 | 
 | 
| 143 |    727 | % \begin{lstlisting}[numbers=none]
 | 
|  |    728 | % ALT(..., ALT(..., ALT(..., ...)))
 | 
|  |    729 | % \end{lstlisting}
 | 
| 123 |    730 | 
 | 
|  |    731 | 
 | 
| 143 |    732 | % \noindent To make it difficult, you do not know how deep such
 | 
|  |    733 | % alternatives are nested. So you need something flexible that
 | 
|  |    734 | % can take as many alternatives as needed. In Scala one can
 | 
|  |    735 | % achieve this by adding a \code{*} to the type of an argument.
 | 
|  |    736 | % Consider the code
 | 
| 123 |    737 | 
 | 
|  |    738 | 
 | 
| 143 |    739 | % \begin{lstlisting}[language=Scala]
 | 
|  |    740 | % def Alts(rs: List[Rexp]) : Rexp = rs match {
 | 
|  |    741 | %   case Nil => NULL
 | 
|  |    742 | %   case r::Nil => r
 | 
|  |    743 | %   case r::rs => ALT(r, Alts(rs))
 | 
|  |    744 | % }
 | 
| 123 |    745 | 
 | 
| 143 |    746 | % def ALTS(rs: Rexp*) = Alts(rs.toList)
 | 
|  |    747 | % \end{lstlisting}
 | 
| 123 |    748 | 
 | 
|  |    749 | 
 | 
| 143 |    750 | % \noindent The function in Lines 1 to 5 takes a list of regular
 | 
|  |    751 | % expressions and converts it into an appropriate alternative
 | 
|  |    752 | % regular expression. In Line 7 there is a wrapper for this
 | 
|  |    753 | % function which uses the feature of varying argument lists. The
 | 
|  |    754 | % effect of this code  is that I can write the regular
 | 
|  |    755 | % expression for keywords as
 | 
| 123 |    756 | 
 | 
|  |    757 | 
 | 
| 143 |    758 | % \begin{lstlisting}[numbers=none]
 | 
|  |    759 | % ALTS("for", "def", "yield", "implicit", "if", "match", "case")
 | 
|  |    760 | % \end{lstlisting}
 | 
| 123 |    761 | 
 | 
|  |    762 | 
 | 
| 143 |    763 | % \noindent Again I leave it to you to find out how much this
 | 
|  |    764 | % simplifies the regular expression in comparison with if I had
 | 
|  |    765 | % to write this by hand using only the ``plain'' regular
 | 
|  |    766 | % expressions from the inductive datatype.
 | 
|  |    767 | 
 | 
|  |    768 | \bigskip\noindent
 | 
|  |    769 | \textit{More TBD.}
 | 
| 123 |    770 | 
 | 
|  |    771 | \subsection*{More Info}
 | 
|  |    772 | 
 | 
|  |    773 | There is much more to Scala than I can possibly describe in
 | 
|  |    774 | this document. Fortunately there are a number of free books
 | 
|  |    775 | about Scala and of course lots of help online. For example
 | 
|  |    776 | 
 | 
|  |    777 | \begin{itemize}
 | 
|  |    778 | \item \url{http://www.scala-lang.org/docu/files/ScalaByExample.pdf}
 | 
|  |    779 | \item \url{http://www.scala-lang.org/docu/files/ScalaTutorial.pdf}
 | 
|  |    780 | \item \url{https://www.youtube.com/user/ShadowofCatron}
 | 
|  |    781 | \item \url{http://docs.scala-lang.org/tutorials}
 | 
|  |    782 | \item \url{https://www.scala-exercises.org}
 | 
|  |    783 | \end{itemize}
 | 
|  |    784 | 
 | 
|  |    785 | \noindent There is also a course at Coursera on Functional
 | 
|  |    786 | Programming Principles in Scala by Martin Odersky, the main
 | 
|  |    787 | developer of the Scala language. And a document that explains
 | 
|  |    788 | Scala for Java programmers
 | 
|  |    789 | 
 | 
|  |    790 | \begin{itemize}
 | 
|  |    791 | \item \small\url{http://docs.scala-lang.org/tutorials/scala-for-java-programmers.html}
 | 
|  |    792 | \end{itemize}
 | 
|  |    793 | 
 | 
|  |    794 | While I am quite enthusiastic about Scala, I am also happy to
 | 
|  |    795 | admit that it has more than its fair share of faults. The
 | 
|  |    796 | problem seen earlier of having to give an explicit type to
 | 
|  |    797 | \code{toSet}, but not \code{toList} is one of them. There are
 | 
|  |    798 | also many ``deep'' ideas about types in Scala, which even to
 | 
|  |    799 | me as seasoned functional programmer are puzzling. Whilst
 | 
|  |    800 | implicits are great, they can also be a source of great
 | 
|  |    801 | headaches, for example consider the code:
 | 
|  |    802 | 
 | 
|  |    803 | \begin{lstlisting}[numbers=none]
 | 
|  |    804 | scala>  List (1, 2, 3) contains "your mom"
 | 
|  |    805 | res1: Boolean = false
 | 
|  |    806 | \end{lstlisting}
 | 
|  |    807 | 
 | 
|  |    808 | \noindent Rather than returning \code{false}, this code should
 | 
|  |    809 | throw a typing-error. There are also many limitations Scala
 | 
|  |    810 | inherited from the JVM that can be really annoying. For
 | 
|  |    811 | example a fixed stack size. One can work around this
 | 
|  |    812 | particular limitation, but why does one have to?
 | 
|  |    813 | More such `puzzles' can be found at
 | 
|  |    814 | 
 | 
|  |    815 | \begin{center}
 | 
|  |    816 |   \url{http://scalapuzzlers.com} and
 | 
|  |    817 |   \url{http://latkin.org/blog/2017/05/02/when-the-scala-compiler-doesnt-help/}
 | 
|  |    818 | \end{center}
 | 
|  |    819 | 
 | 
|  |    820 | Even if Scala has been a success in several high-profile
 | 
|  |    821 | companies, there is also a company (Yammer) that first used
 | 
|  |    822 | Scala in their production code, but then moved away from it.
 | 
|  |    823 | Allegedly they did not like the steep learning curve of Scala
 | 
|  |    824 | and also that new versions of Scala often introduced
 | 
|  |    825 | incompatibilities in old code. In the past two months
 | 
|  |    826 | there have also been two forks of the Scala compiler.
 | 
|  |    827 | It needs to be seen what the future brings for Scala.
 | 
|  |    828 | 
 | 
| 152 |    829 | %So all in all, Scala might not be a great teaching language,
 | 
|  |    830 | %but I hope this is mitigated by the fact that I never require
 | 
|  |    831 | %you to write any Scala code. You only need to be able to read
 | 
|  |    832 | %it. In the coursework you can use any programming language you
 | 
|  |    833 | %like. If you want to use Scala for this, then be my guest; if
 | 
|  |    834 | %you do not want, stick with the language you are most familiar
 | 
|  |    835 | %with.
 | 
| 123 |    836 | 
 | 
|  |    837 | 
 | 
|  |    838 | 
 | 
|  |    839 | \end{document}
 | 
|  |    840 | 
 | 
|  |    841 | %%% Local Variables: 
 | 
|  |    842 | %%% mode: latex
 | 
|  |    843 | %%% TeX-master: t
 | 
|  |    844 | %%% End: 
 |