
diff -r 38e13601cb1b -r 5c7279e09b15 handouts/pep-ho.tex
--- a/handouts/pep-ho.tex	Tue Aug 06 00:12:34 2019 +0100
+++ b/handouts/pep-ho.tex	Tue Aug 06 12:46:27 2019 +0100
@@ -41,7 +41,7 @@
 
 
 \begin{document}
-\fnote{\copyright{} Christian Urban, King's College London, 2017, 2018}
+\fnote{\copyright{} Christian Urban, King's College London, 2017, 2018, 2019}
 
 \section*{A Crash-Course in Scala}
 
@@ -244,7 +244,7 @@
 from this problem. The catch is that if you try to solve this problem in
 C++ or Java, and be as defensive as possible about reads and writes to
 \texttt{i}, then you need to synchronise access to it. The result is that
-your program more often than not waits more than it runs, thereby
+very often your program waits more than it runs, thereby
 defeating the point of trying to run the program in parallel in the
 first place. If you are less defensive, then usually all hell breaks
 loose by seemingly obtaining random results. And forget the idea of
@@ -373,7 +373,7 @@
 
 \begin{lstlisting}[language={},numbers=none,basicstyle=\ttfamily\small]
 $ scala
-Welcome to Scala 2.12.7 (Java HotSpot(TM) 64-Bit Server VM, Java 9).
+Welcome to Scala 2.13.0 (Java HotSpot(TM) 64-Bit Server VM, Java 9).
 Type in expressions for evaluation. Or try :help.
 
 scala>
@@ -488,7 +488,8 @@
 In the lectures I will try to avoid as much as possible the term
 \emph{variables} familiar from other programming languages. The reason
 is that Scala has \emph{values}, which can be seen as abbreviations of
-larger expressions. For example
+larger expressions. The keyword for defining values is \code{val}.
+For example
 
 \begin{lstlisting}[numbers=none]
 scala> val x = 42
@@ -502,9 +503,11 @@
 \end{lstlisting}
 
 \noindent
-Why the kerfuffle about values? Well, values are \emph{immutable}. You 
-cannot change their value after you defined them. If you try to reassign
-\code{z} above, Scala will yell at you:
+As can be seen we first define \code{x} and {y} with some silly
+expressions, and then reuse these values in the definition of \code{z}.
+All easy, no? Why the kerfuffle about values? Well, values are
+\emph{immutable}. You cannot change their value after you defined them.
+If you try to reassign \code{z} above, Scala will yell at you:
 
 \begin{lstlisting}[numbers=none]
 scala> z = 9
@@ -528,7 +531,10 @@
 for \code{z}?  Will it be \code{6} or \code{10}? A final word about
 values: Try to stick to the convention that names of values should be
 lower case, like \code{x}, \code{y}, \code{foo41} and so on. Upper-case
-names you should reserve for what is called \emph{constructors}.
+names you should reserve for what is called \emph{constructors}. And 
+forgive me when I call values as variables\ldots{}it is just something that
+has been in imprinted into my developer-DNA during my early days and
+difficult to get rid of.~\texttt{;o)}  
 
 
 \subsection*{Function Definitions}
@@ -543,8 +549,9 @@
 
 \noindent
 This function returns the value resulting from evaluating the expression
-\code{EXPR} (whatever is substituted for this). The result will be
-of type \code{String}. It is a good habit to always include this information
+\code{EXPR} (whatever is substituted for this). Since we declared
+\code{String}, the result of this function will be of type
+\code{String}. It is a good habit to always include this information
 about the return type. Simple examples of Scala functions are:
 
 \begin{lstlisting}[numbers=none]
@@ -558,7 +565,7 @@
 
 \begin{lstlisting}[numbers=none]
 def fname(arg1: ty1, arg2: ty2,..., argn: tyn): rty = {
-  BODY
+  ...BODY...
 }
 \end{lstlisting}
 
@@ -572,13 +579,26 @@
 like the venerable factorial function:
 
 \begin{lstlisting}[numbers=none]
-def fact(n: Int): Int = 
+def fact(n: Int) : Int = 
   if (n == 0) 1 else n * fact(n - 1)
 \end{lstlisting}
 
 \noindent
+We could also have written this as
+
+\begin{lstlisting}[numbers=none]
+def fact(n: Int) : Int = {
+  if (n == 0) 1 
+  else n * fact(n - 1)
+}    
+\end{lstlisting}
+
+\noindent
+but this seems a bit over-kill for a small function like \code{fact}.
 Note that Scala does not have a \code{then}-keyword in an \code{if}-statement.
-  
+Note also that there are a few other ways of how to define a function. We 
+will see some in the next sections.
+
 \subsection*{Loops, or better the Absence thereof}
 
 Coming from Java or C++, you might be surprised that Scala does
@@ -697,7 +717,9 @@
 \noindent The \code{if}-condition in the for-comprehension
 filters out all pairs where the sum is not even.
 
-While hopefully this all looks reasonable, there is one
+\subsection*{Results and Side-Effects}
+
+While hopefully this all about maps looks reasonable, there is one
 complication: In the examples above we always wanted to
 transform one list into another list (e.g.~list of squares),
 or one set into another set (set of numbers into set of
@@ -766,6 +788,8 @@
 above. Scala will still allow \code{map} with side-effect
 functions, but then reacts with a slightly interesting result.
 
+\subsection*{Higher-Order Functions}
+
 \subsection*{Types}
 
 In most functional programming languages, types play an




