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 

    11 \section*{A Crash-Course on Scala}

    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 

    41 \noindent indicating that the result of the addition is of

    42 type \code{Int} and the actual result is 5. Another classic

    43 example you can try out is

    44 

    45 \begin{lstlisting}[numbers=none]

    46 scala> print("hello world")

    47 hello world

    48 \end{lstlisting}

    49 

    50 \noindent Note that in this case there is no result. The

    51 reason is that \code{print} does not actually produce a result

    52 (there is no \code{resXX} and no type), rather it is a

    53 function that causes the \emph{side-effect} of printing out a

    54 string. Once you are more familiar with the functional

    55 programming-style, you will know what the difference is

    56 between a function that returns a result, like addition, and a

    57 function that causes a side-effect, like \code{print}. We

    58 shall come back to this point later, but if you are curious

    59 now, the latter kind of functions always has \code{Unit} as

    60 return type.

    61 

    62 You can try more examples with the Scala interpreter, but try

    63 first to guess what the result is (not all answers by Scala are obvious):

    64 

    65 \begin{lstlisting}[numbers=none]

    66 scala> 2 + 2

    67 scala> 1 / 2

    68 scala> 1.0 / 2

    69 scala> 1 / 2.0

    70 scala> 1 / 0

    71 scala> 1.0 / 0.0

    72 scala> true == false

    73 scala> true && false

    74 scala> 1 > 1.0

    75 scala> "12345".length

    76 \end{lstlisting}

    77 

    78 \subsection*{Stand-Alone Apps}

    79 

    80 If you want to write a stand-alone app in Scala, you can

    81 implement an object that is an instance of \code{App}, say

    82 

    83 \begin{lstlisting}[numbers=none]

    84 object Hello extends App {

    85     println("hello world")

    86 }

    87 \end{lstlisting}

    88 

    89 \noindent save it in a file, say {\tt hello-world.scala}, and

    90 then run the compiler and runtime environment:

    91 

    92 \begin{lstlisting}[language={},numbers=none,basicstyle=\ttfamily\small]

    93 $ scalac hello-world.scala

    94 $ scala Hello

    95 hello world

    96 \end{lstlisting}

    97 

    98 Like Java, Scala targets the JVM and consequently

    99 Scala programs can also be executed by the bog-standard Java

   100 Runtime. This only requires the inclusion of {\tt

   101 scala-library.jar}, which on my computer can be done as

   102 follows:

   103 

   104 \begin{lstlisting}[language={},numbers=none,basicstyle=\ttfamily\small]

   105 $ scalac hello-world.scala

   106 $ java -cp /usr/local/src/scala/lib/scala-library.jar:. Hello

   107 hello world

   108 \end{lstlisting}

   109 

   110 \noindent You might need to adapt the path to where you have

   111 installed Scala.

   112 

   113 \subsection*{Values}

   114 

   115 In the lectures, I will try as much as possible to avoid the term

   116 \emph{variables} familiar from other programming languages. Scala

   117 has \emph{values}, which can be seen as abbreviations of larger

   118 expressions. For example

   119 

   120 \begin{lstlisting}[numbers=none]

   121 scala> val x = 42

   122 x: Int = 42

   123 

   124 scala> val y = 3 + 4

   125 y: Int = 7

   126 

   127 scala> val z = x / y

   128 z: Int = 6

   129 \end{lstlisting}

   130 

   131 \noindent

   132 Why the kerfuffle about values? Well, values are \emph{immutable}. You cannot

   133 change their value after you defined them. If you try to reassign, say,

   134 \code{z}, Scala will yell at you:

   135 

   136 \begin{lstlisting}[numbers=none]

   137 scala> z = 9

   138 error: reassignment to val

   139        z = 9

   140          ^

   141 \end{lstlisting}

   142 

   143 \noindent

   144 So it would be a bit absurd to call values as variables...you cannot

   145 change them. You might think you can re-assign them like

   146 

   147 \begin{lstlisting}[numbers=none]

   148 scala> val x = 42

   149 scala> val z = x / 7

   150 scala> val x = 70

   151 scala> println(z) 

   152 \end{lstlisting}

   153 

   154 \noindent but try to guess what Scala will print out in the code above

   155 for \code{z}?  Will it be \code{6} or \code{10}? A final word about

   156 values: Try to stick to the convention that names of values should be

   157 lower case, like \code{x}, \code{y}, \code{foo41} and so on.

   158 

   159 

   160 \subsection*{Function Definitions}

   161 

   162 A function \code{f} taking a single argument of type \code{Int} can be defined

   163 as follows:

   164 

   165 \begin{lstlisting}[numbers=none]

   166 def f(x: Int) : String = EXPR

   167 \end{lstlisting} 

   168 

   169 \noindent

   170 It returns the value resulting from evaluating the expression

   171 \code{EXPR} (whatever is substituted for this). The result will be

   172 of type \code{String}. Simple examples of Scala functions are:

   173 

   174 \begin{lstlisting}[numbers=none]

   175 def incr(x: Int) : Int = x + 1

   176 def double(x: Int) : Int = x + x

   177 def square(x: Int) : Int = x * x

   178 \end{lstlisting}

   179 

   180 \noindent

   181 The general scheme for a function is

   182 

   183 \begin{lstlisting}[numbers=none]

   184 def fname(arg1: ty1, arg2: ty2,..., argn: tyn): rty = {

   185   BODY

   186 }

   187 \end{lstlisting}

   188 

   189 \noindent

   190 where each argument requires its type and the result type of the

   191 function, \code{rty}, shoudl be given. If the body of the  function

   192 is more complex, then it can be enclosed in braces; it it is just a

   193 simple expression, like \code{x + 1}, you can omit the braces. Very

   194 often functions are recursive (call themselves) like

   195 

   196 \begin{lstlisting}[numbers=none]

   197 def fact(n: Int): Int = 

   198   if (n == 0) 1 else n * fact(n - 1)

   199 \end{lstlisting}

   200   

   201 \subsection*{Loops, or better the Absence thereof}

   202 

   203 Coming from Java or C++, you might be surprised that Scala does

   204 not really have loops. It has instead, what is in functional

   205 programming called, \emph{maps}. To illustrate how they work,

   206 let us assume you have a list of numbers from 1 to 8 and want to

   207 build the list of squares. The list of numbers from 1 to 8 

   208 can be constructed in Scala as follows:

   209 

   210 \begin{lstlisting}[numbers=none]

   211 scala> (1 to 8).toList

   212 res1: List[Int] = List(1, 2, 3, 4, 5, 6, 7, 8)

   213 \end{lstlisting}

   214 

   215 \noindent Generating from this list, the list of squares in a

   216 programming language such as Java, you would assume the list

   217 is given as a kind of array. You would then iterate, or loop,

   218 an index over this array and replace each entry in the array

   219 by the square. Right? In Scala, and in other functional

   220 programming languages, you use maps to achieve the same. 

   221 

   222 A map essentially takes a function that describes how each

   223 element is transformed (for example squared) and a list over

   224 which this function should work. There are two forms to

   225 express such maps in Scala. The first way is called a

   226 \emph{for-comprehension}. Squaring the numbers from 1 to 8

   227 would look as follows:

   228 

   229 \begin{lstlisting}[numbers=none]

   230 scala> for (n <- (1 to 8).toList) yield n * n

   231 res2: List[Int] = List(1, 4, 9, 16, 25, 36, 49, 64)

   232 \end{lstlisting}

   233 

   234 \noindent The important keywords are \code{for} and

   235 \code{yield}. This for-comprehension roughly states that from

   236 the list of numbers we draw \code{n}s and compute the result

   237 of \code{n * n}. As you can see, we specified the list where

   238 each \code{n} comes from, namely \code{(1 to 8).toList}, and

   239 how each element needs to be transformed. This can also be

   240 expressed in a second way in Scala by using directly

   241 \code{map}s as follows:

   242 

   243 \begin{lstlisting}[numbers=none]

   244 scala> (1 to 8).toList.map(n => n * n)

   245 res3 = List(1, 4, 9, 16, 25, 36, 49, 64)

   246 \end{lstlisting}

   247 

   248 \noindent In this way, the expression \code{n => n * n} stands

   249 for the function that calculates the square (this is how the

   250 \code{n}s are transformed). This expression for functions

   251 might remind you of your lessons about the lambda-calculus

   252 where this would have been written as $\lambda n.\,n * n$. It

   253 might not be obvious, but for-comprehensions are just

   254 syntactic sugar: when compiling, Scala translates

   255 for-comprehensions into equivalent maps. This even works

   256 when for-comprehensions get more complicated (see below).

   257 

   258 The very charming feature of Scala is that such maps or

   259 for-comprehensions can be written for any kind of data

   260 collection, such as lists, sets, vectors, options and so on.

   261 For example if we instead compute the reminders modulo 3 of

   262 this list, we can write

   263 

   264 \begin{lstlisting}[numbers=none]

   265 scala> (1 to 8).toList.map(n => n % 3)

   266 res4 = List(1, 2, 0, 1, 2, 0, 1, 2)

   267 \end{lstlisting}

   268 

   269 \noindent If we, however, transform the numbers 1 to 8 not

   270 into a list, but into a set, and then compute the reminders

   271 modulo 3 we obtain

   272 

   273 \begin{lstlisting}[numbers=none]

   274 scala> (1 to 8).toSet[Int].map(n => n % 3)

   275 res5 = Set(2, 1, 0)

   276 \end{lstlisting}

   277 

   278 \noindent This is the correct result for sets, as there are

   279 only three equivalence classes of integers modulo 3. Note that

   280 in this example we need to ``help'' Scala to transform the

   281 numbers into a set of integers by explicitly annotating the

   282 type \code{Int}. Since maps and for-comprehensions are

   283 just syntactic variants of each other, the latter can also be

   284 written as

   285 

   286 \begin{lstlisting}[numbers=none]

   287 scala> for (n <- (1 to 8).toSet[Int]) yield n % 3

   288 res5 = Set(2, 1, 0)

   289 \end{lstlisting}

   290 

   291 For-comprehensions can also be nested and the selection of 

   292 elements can be guarded. For example if we want to pair up

   293 the numbers 1 to 4 with the letters a to c, we can write

   294 

   295 \begin{lstlisting}[numbers=none]

   296 scala> for (n <- (1 to 4).toList; 

   297             m <- ('a' to 'c').toList) yield (n, m)

   298 res6 = List((1,a), (1,b), (1,c), (2,a), (2,b), (2,c), 

   299             (3,a), (3,b), (3,c), (4,a), (4,b), (4,c))

   300 \end{lstlisting}

   301 

   302 \noindent 

   303 Or if we want to find all pairs of numbers between 1 and 3

   304 where the sum is an even number, we can write

   305 

   306 \begin{lstlisting}[numbers=none]

   307 scala> for (n <- (1 to 3).toList; 

   308             m <- (1 to 3).toList;

   309             if (n + m) % 2 == 0) yield (n, m)

   310 res7 = List((1,1), (1,3), (2,2), (3,1), (3,3))

   311 \end{lstlisting}

   312 

   313 \noindent The \code{if}-condition in the for-comprehension

   314 filters out all pairs where the sum is not even.

   315 

   316 While hopefully this all looks reasonable, there is one

   317 complication: In the examples above we always wanted to

   318 transform one list into another list (e.g.~list of squares),

   319 or one set into another set (set of numbers into set of

   320 reminders modulo 3). What happens if we just want to print out

   321 a list of integers? Then actually the for-comprehension

   322 needs to be modified. The reason is that \code{print}, you

   323 guessed it, does not produce any result, but only produces

   324 what is in the functional-programming-lingo called a

   325 side-effect. Printing out the list of numbers from 1 to 5

   326 would look as follows

   327 

   328 \begin{lstlisting}[numbers=none]

   329 scala> for (n <- (1 to 5).toList) print(n)

   330 12345

   331 \end{lstlisting}

   332 

   333 \noindent

   334 where you need to omit the keyword \code{yield}. You can

   335 also do more elaborate calculations such as

   336 

   337 \begin{lstlisting}[numbers=none]

   338 scala> for (n <- (1 to 5).toList) {

   339   val square_n = n * n

   340   println(s"$n * $n = $square_n") 

   341 }

   342 1 * 1 = 1

   343 2 * 2 = 4

   344 3 * 3 = 9

   345 4 * 4 = 16

   346 5 * 5 = 25

   347 \end{lstlisting}%$

   348 

   349 \noindent In this code I use a variable assignment (\code{val

   350 square_n = ...} ) and also what is called in Scala a

   351 \emph{string interpolation}, written \code{s"..."}. The latter

   352 is for printing out an equation. It allows me to refer to the

   353 integer values \code{n} and \code{square\_n} inside a string.

   354 This is very convenient for printing out ``things''. 

   355 

   356 The corresponding map construction for functions with 

   357 side-effects is in Scala called \code{foreach}. So you 

   358 could also write

   359 

   360 

   361 \begin{lstlisting}[numbers=none]

   362 scala> (1 to 5).toList.foreach(n => print(n))

   363 12345

   364 \end{lstlisting}

   365 

   366 

   367 \noindent or even just

   368 

   369 \begin{lstlisting}[numbers=none]

   370 scala> (1 to 5).toList.foreach(print)

   371 12345

   372 \end{lstlisting}

   373 

   374 \noindent Again I hope this reminds you a bit of your

   375 lambda-calculus lessons, where an explanation is given why

   376 both forms produce the same result.

   377 

   378 

   379 If you want to find out more about maps and functions with

   380 side-effects, you can ponder about the response Scala gives if

   381 you replace \code{foreach} by \code{map} in the expression

   382 above. Scala will still allow \code{map} with side-effect

   383 functions, but then reacts with a slightly interesting result.

   384 

   385 \subsection*{Types}

   386 

   387 In most functional programming languages, types play an

   388 important role. Scala is such a language. You have already

   389 seen built-in types, like \code{Int}, \code{Boolean},

   390 \code{String} and \code{BigInt}, but also user-defined ones,

   391 like \code{Rexp}. Unfortunately, types can be a thorny

   392 subject, especially in Scala. For example, why do we need to

   393 give the type to \code{toSet[Int]}, but not to \code{toList}?

   394 The reason is the power of Scala, which sometimes means it

   395 cannot infer all necessary typing information. At the

   396 beginning while getting familiar with Scala, I recommend a

   397 ``play-it-by-ear-approach'' to types. Fully understanding

   398 type-systems, especially complicated ones like in Scala, can

   399 take a module on their own.\footnote{Still, such a study can

   400 be a rewarding training: If you are in the business of

   401 designing new programming languages, you will not be able to

   402 turn a blind eye to types. They essentially help programmers

   403 to avoid common programming errors and help with maintaining

   404 code.}

   405 

   406 In Scala, types are needed whenever you define an inductive

   407 datatype and also whenever you define functions (their

   408 arguments and their results need a type). Base types are types

   409 that do not take any (type)arguments, for example \code{Int}

   410 and \code{String}. Compound types take one or more arguments,

   411 which as seen earlier need to be given in angle-brackets, for

   412 example \code{List[Int]} or \code{Set[List[String]]} or 

   413 \code{Map[Int, Int]}.

   414 

   415 There are a few special type-constructors that fall outside

   416 this pattern. One is for tuples, where the type is written

   417 with parentheses. For example 

   418 

   419 \begin{lstlisting}[ numbers=none]

   420 (Int, Int, String)

   421 \end{lstlisting}

   422 

   423 \noindent is for a triple (a tuple with three components---two

   424 integers and a string). Tuples are helpful if you want to

   425 define functions with multiple results, say the function

   426 returning the quotient and reminder of two numbers. For this

   427 you might define:

   428 

   429 

   430 \begin{lstlisting}[ numbers=none]

   431 def quo_rem(m: Int, n: Int) : (Int, Int) = (m / n, m % n)

   432 \end{lstlisting}

   433 

   434 

   435 \noindent Since this function returns a pair of integers, its

   436 return type needs to be of type \code{(Int, Int)}.

   437 Incidentally, this is also the input type of this function.

   438 Notice this function takes \emph{two} arguments, namely

   439 \code{m} and \code{n}, both of which are integers. They are

   440 ``packaged'' in a pair. Consequently the complete type of

   441 \code{quo_rem} is

   442 

   443 \begin{lstlisting}[ numbers=none]

   444 (Int, Int) => (Int, Int)

   445 \end{lstlisting}

   446 

   447 Another special type-constructor is for functions, written as

   448 the arrow \code{=>}. For example, the type \code{Int =>

   449 String} is for a function that takes an integer as input

   450 argument and produces a string as result. A function of this

   451 type is for instance

   452 

   453 \begin{lstlisting}[numbers=none]

   454 def mk_string(n: Int) : String = n match {

   455   case 0 => "zero"

   456   case 1 => "one"

   457   case 2 => "two"

   458   case _ => "many" 

   459 } 

   460 \end{lstlisting}

   461 

   462 \noindent It takes an integer as input argument and returns a

   463 string. Unlike other functional programming languages, there

   464 is in Scala no easy way to find out the types of existing

   465 functions, except by looking into the documentation

   466 

   467 \begin{quote}

   468 \url{http://www.scala-lang.org/api/current/}

   469 \end{quote}

   470 

   471 The function arrow can also be iterated, as in 

   472 \code{Int => String => Boolean}. This is the type for a function

   473 taking an integer as first argument and a string as second,

   474 and the result of the function is a boolean. Though silly, a

   475 function of this type would be

   476 

   477 

   478 \begin{lstlisting}[numbers=none]

   479 def chk_string(n: Int)(s: String) : Boolean = 

   480   mk_string(n) == s

   481 \end{lstlisting}

   482 

   483 

   484 \noindent which checks whether the integer \code{n}

   485 corresponds to the name \code{s} given by the function

   486 \code{mk\_string}. Notice the unusual way of specifying the

   487 arguments of this function: the arguments are given one after

   488 the other, instead of being in a pair (what would be the type

   489 of this function then?). This way of specifying the arguments

   490 can be useful, for example in situations like this

   491 

   492 \begin{lstlisting}[numbers=none]

   493 scala> List("one", "two", "three", "many").map(chk_string(2))

   494 res4 = List(false, true, false, false)

   495 

   496 scala> List("one", "two", "three", "many").map(chk_string(3))

   497 res5 = List(false, false, false, true)

   498 \end{lstlisting}

   499 

   500 \noindent In each case we can give to \code{map} a specialised

   501 version of \code{chk_string}---once specialised to 2 and once

   502 to 3. This kind of ``specialising'' a function is called

   503 \emph{partial application}---we have not yet given to this

   504 function all arguments it needs, but only some of them.

   505 

   506 Coming back to the type \code{Int => String => Boolean}. The

   507 rule about such function types is that the right-most type

   508 specifies what the function returns (a boolean in this case).

   509 The types before that specify how many arguments the function

   510 expects and what their type is (in this case two arguments,

   511 one of type \code{Int} and another of type \code{String}).

   512 Given this rule, what kind of function has type

   513 \mbox{\code{(Int => String) => Boolean}}? Well, it returns a

   514 boolean. More interestingly, though, it only takes a single

   515 argument (because of the parentheses). The single argument

   516 happens to be another function (taking an integer as input and

   517 returning a string). Remember that \code{mk_string} is just 

   518 such a function. So how can we use it? For this define

   519 the somewhat silly function \code{apply_3}:

   520 

   521 \begin{lstlisting}[numbers=none]

   522 def apply_3(f: Int => String): Bool = f(3) == "many"

   523 

   524 scala> apply_3(mk_string)

   525 res6 = true

   526 \end{lstlisting}

   527 

   528 You might ask: Apart from silly functions like above, what is

   529 the point of having functions as input arguments to other

   530 functions? In Java there is indeed no need of this kind of

   531 feature: at least in the past it did not allow such

   532 constructions. I think, the point of Java 8 is to lift this

   533 restriction. But in all functional programming languages,

   534 including Scala, it is really essential to allow functions as

   535 input argument. Above you already seen \code{map} and

   536 \code{foreach} which need this. Consider the functions

   537 \code{print} and \code{println}, which both print out strings,

   538 but the latter adds a line break. You can call \code{foreach}

   539 with either of them and thus changing how, for example, five

   540 numbers are printed.

   541 

   542 

   543 \begin{lstlisting}[numbers=none]

   544 scala> (1 to 5).toList.foreach(print)

   545 12345

   546 scala> (1 to 5).toList.foreach(println)

   547 1

   548 2

   549 3

   550 4

   551 5

   552 \end{lstlisting}

   553 

   554 

   555 \noindent This is actually one of the main design principles

   556 in functional programming. You have generic functions like

   557 \code{map} and \code{foreach} that can traverse data containers,

   558 like lists or sets. They then take a function to specify what

   559 should be done with each element during the traversal. This

   560 requires that the generic traversal functions can cope with

   561 any kind of function (not just functions that, for example,

   562 take as input an integer and produce a string like above).

   563 This means we cannot fix the type of the generic traversal

   564 functions, but have to keep them

   565 \emph{polymorphic}.\footnote{Another interestic topic about

   566 types, but we omit it here for the sake of brevity.} 

   567 

   568 There is one more type constructor that is rather special. It

   569 is called \code{Unit}. Recall that \code{Boolean} has two

   570 values, namely \code{true} and \code{false}. This can be used,

   571 for example, to test something and decide whether the test

   572 succeeds or not. In contrast the type \code{Unit} has only a

   573 single value, written \code{()}. This seems like a completely

   574 useless type and return value for a function, but is actually

   575 quite useful. It indicates when the function does not return

   576 any result. The purpose of these functions is to cause

   577 something being written on the screen or written into a file,

   578 for example. This is what is called they cause some effect on 

   579 the side, namely a new content displayed on the screen or some

   580 new data in a file. Scala uses the \code{Unit} type to indicate

   581 that a function does not have a result, but potentially causes

   582 some side-effect. Typical examples are the printing functions, 

   583 like \code{print}.

   584 

   585 

   586 \subsection*{Cool Stuff}

   587 

   588 The first wow-moment I had with Scala was when I came across

   589 the following code-snippet for reading a web-page. 

   590 

   591 

   592 \begin{lstlisting}[ numbers=none]

   593 import io.Source

   594 val url = """http://www.inf.kcl.ac.uk/staff/urbanc/"""

   595 Source.fromURL(url)("ISO-8859-1").take(10000).mkString

   596 \end{lstlisting}

   597 

   598 

   599 \noindent These three lines return a string containing the

   600 HTML-code of my webpage. It actually already does something

   601 more sophisticated, namely only returns the first 10000

   602 characters of a webpage in case it is too large. Why is that

   603 code-snippet of any interest? Well, try implementing

   604 reading-from-a-webpage in Java. I also like the possibility of

   605 triple-quoting strings, which I have only seen in Scala so

   606 far. The idea behind this is that in such a string all

   607 characters are interpreted literally---there are no escaped

   608 characters, like \verb|\n| for newlines.

   609 

   610 My second wow-moment I had with a feature of Scala that other

   611 functional programming languages do not have. This feature is

   612 about implicit type conversions. If you have regular

   613 expressions and want to use them for language processing you

   614 often want to recognise keywords in a language, for example

   615 \code{for},{} \code{if},{} \code{yield} and so on. But the

   616 basic regular expression \code{CHAR} can only recognise a

   617 single character. In order to recognise a whole string, like

   618 \code{for}, you have to put many of those together using

   619 \code{SEQ}:

   620 

   621 

   622 \begin{lstlisting}[numbers=none]

   623 SEQ(CHAR('f'), SEQ(CHAR('o'), CHAR('r')))

   624 \end{lstlisting}

   625 

   626 \noindent This gets quickly unreadable when the strings and

   627 regular expressions get more complicated. In other functional

   628 programming languages, you can explicitly write a conversion

   629 function that takes a string, say \dq{\pcode{for}}, and

   630 generates the regular expression above. But then your code is

   631 littered with such conversion functions.

   632 

   633 In Scala you can do better by ``hiding'' the conversion

   634 functions. The keyword for doing this is \code{implicit} and

   635 it needs a built-in library called 

   636 

   637 \begin{lstlisting}[numbers=none]

   638 scala.language.implicitConversions

   639 \end{lstlisting}

   640 

   641 \noindent

   642 Consider the code

   643 

   644 

   645 \begin{lstlisting}[language=Scala]

   646 import scala.language.implicitConversions

   647 

   648 def charlist2rexp(s: List[Char]) : Rexp = s match {

   649   case Nil => EMPTY

   650   case c::Nil => CHAR(c)

   651   case c::s => SEQ(CHAR(c), charlist2rexp(s))

   652 }

   653 

   654 implicit def string2rexp(s: String) : Rexp = 

   655   charlist2rexp(s.toList)

   656 \end{lstlisting}

   657 

   658 

   659 \noindent where the first seven lines implement a function

   660 that given a list of characters generates the corresponding

   661 regular expression. In Lines 9 and 10, this function is used

   662 for transforming a string into a regular expression. Since the

   663 \code{string2rexp}-function is declared as \code{implicit},

   664 the effect will be that whenever Scala expects a regular

   665 expression, but I only give it a string, it will automatically

   666 insert a call to the \code{string2rexp}-function. I can now

   667 write for example

   668 

   669 \begin{lstlisting}[numbers=none]

   670 scala> ALT("ab", "ac")

   671 res9 = ALT(SEQ(CHAR(a),CHAR(b)),SEQ(CHAR(a),CHAR(c)))

   672 \end{lstlisting}

   673 

   674 \noindent Recall that \code{ALT} expects two regular

   675 expressions as arguments, but I only supply two strings. The

   676 implicit conversion function will transform the string into a

   677 regular expression.

   678 

   679 Using implicit definitions, Scala allows me to introduce

   680 some further syntactic sugar for regular expressions:

   681 

   682 

   683 \begin{lstlisting}[ numbers=none]

   684 implicit def RexpOps(r: Rexp) = new {

   685   def | (s: Rexp) = ALT(r, s)

   686   def ~ (s: Rexp) = SEQ(r, s)

   687   def % = STAR(r)

   688 }

   689 

   690 implicit def stringOps(s: String) = new {

   691   def | (r: Rexp) = ALT(s, r)

   692   def | (r: String) = ALT(s, r)

   693   def ~ (r: Rexp) = SEQ(s, r)

   694   def ~ (r: String) = SEQ(s, r)

   695   def % = STAR(s)

   696 }

   697 \end{lstlisting}

   698 

   699  

   700 \noindent This might seem a bit overly complicated, but its effect is

   701 that I can now write regular expressions such as $ab + ac$ 

   702 simply as

   703 

   704 

   705 \begin{lstlisting}[numbers=none]

   706 scala> "ab" | "ac"

   707 res10 = ALT(SEQ(CHAR(a),CHAR(b)),SEQ(CHAR(a),CHAR(c)))

   708 \end{lstlisting}

   709 

   710  

   711 \noindent I leave you to figure out what the other

   712 syntactic sugar in the code above stands for.

   713  

   714 One more useful feature of Scala is the ability to define

   715 functions with varying argument lists. This is a feature that

   716 is already present in old languages, like C, but seems to have

   717 been forgotten in the meantime---Java does not have it. In the

   718 context of regular expressions this feature comes in handy:

   719 Say you are fed up with writing many alternatives as

   720 

   721 

   722 \begin{lstlisting}[numbers=none]

   723 ALT(..., ALT(..., ALT(..., ...)))

   724 \end{lstlisting}

   725 

   726 

   727 \noindent To make it difficult, you do not know how deep such

   728 alternatives are nested. So you need something flexible that

   729 can take as many alternatives as needed. In Scala one can

   730 achieve this by adding a \code{*} to the type of an argument.

   731 Consider the code

   732 

   733 

   734 \begin{lstlisting}[language=Scala]

   735 def Alts(rs: List[Rexp]) : Rexp = rs match {

   736   case Nil => NULL

   737   case r::Nil => r

   738   case r::rs => ALT(r, Alts(rs))

   739 }

   740 

   741 def ALTS(rs: Rexp*) = Alts(rs.toList)

   742 \end{lstlisting}

   743 

   744 

   745 \noindent The function in Lines 1 to 5 takes a list of regular

   746 expressions and converts it into an appropriate alternative

   747 regular expression. In Line 7 there is a wrapper for this

   748 function which uses the feature of varying argument lists. The

   749 effect of this code  is that I can write the regular

   750 expression for keywords as

   751 

   752 

   753 \begin{lstlisting}[numbers=none]

   754 ALTS("for", "def", "yield", "implicit", "if", "match", "case")

   755 \end{lstlisting}

   756 

   757 

   758 \noindent Again I leave it to you to find out how much this

   759 simplifies the regular expression in comparison with if I had

   760 to write this by hand using only the ``plain'' regular

   761 expressions from the inductive datatype.

   762 

   763 \subsection*{More Info}

   764 

   765 There is much more to Scala than I can possibly describe in

   766 this document. Fortunately there are a number of free books

   767 about Scala and of course lots of help online. For example

   768 

   769 \begin{itemize}

   770 \item \url{http://www.scala-lang.org/docu/files/ScalaByExample.pdf}

   771 \item \url{http://www.scala-lang.org/docu/files/ScalaTutorial.pdf}

   772 \item \url{https://www.youtube.com/user/ShadowofCatron}

   773 \item \url{http://docs.scala-lang.org/tutorials}

   774 \item \url{https://www.scala-exercises.org}

   775 \end{itemize}

   776 

   777 \noindent There is also a course at Coursera on Functional

   778 Programming Principles in Scala by Martin Odersky, the main

   779 developer of the Scala language. And a document that explains

   780 Scala for Java programmers

   781 

   782 \begin{itemize}

   783 \item \small\url{http://docs.scala-lang.org/tutorials/scala-for-java-programmers.html}

   784 \end{itemize}

   785 

   786 While I am quite enthusiastic about Scala, I am also happy to

   787 admit that it has more than its fair share of faults. The

   788 problem seen earlier of having to give an explicit type to

   789 \code{toSet}, but not \code{toList} is one of them. There are

   790 also many ``deep'' ideas about types in Scala, which even to

   791 me as seasoned functional programmer are puzzling. Whilst

   792 implicits are great, they can also be a source of great

   793 headaches, for example consider the code:

   794 

   795 \begin{lstlisting}[numbers=none]

   796 scala>  List (1, 2, 3) contains "your mom"

   797 res1: Boolean = false

   798 \end{lstlisting}

   799 

   800 \noindent Rather than returning \code{false}, this code should

   801 throw a typing-error. There are also many limitations Scala

   802 inherited from the JVM that can be really annoying. For

   803 example a fixed stack size. One can work around this

   804 particular limitation, but why does one have to?

   805 More such `puzzles' can be found at

   806 

   807 \begin{center}

   808   \url{http://scalapuzzlers.com} and

   809   \url{http://latkin.org/blog/2017/05/02/when-the-scala-compiler-doesnt-help/}

   810 \end{center}

   811 

   812 Even if Scala has been a success in several high-profile

   813 companies, there is also a company (Yammer) that first used

   814 Scala in their production code, but then moved away from it.

   815 Allegedly they did not like the steep learning curve of Scala

   816 and also that new versions of Scala often introduced

   817 incompatibilities in old code. In the past two months

   818 there have also been two forks of the Scala compiler.

   819 It needs to be seen what the future brings for Scala.

   820 

   821 So all in all, Scala might not be a great teaching language,

   822 but I hope this is mitigated by the fact that I never require

   823 you to write any Scala code. You only need to be able to read

   824 it. In the coursework you can use any programming language you

   825 like. If you want to use Scala for this, then be my guest; if

   826 you do not want, stick with the language you are most familiar

   827 with.

   828 

   829 

   830 

   831 \end{document}

   832 

   833 %%% Local Variables: 

   834 %%% mode: latex

   835 %%% TeX-master: t

   836 %%% End: