diff -r 841727e27252 -r 7e00d2b13b04 handouts/pep-ho.tex
--- a/handouts/pep-ho.tex	Thu Apr 23 14:49:54 2020 +0100
+++ b/handouts/pep-ho.tex	Wed Aug 12 00:56:20 2020 +0100
@@ -8,6 +8,9 @@
 \usepackage{boxedminipage}
 
 
+
+
+
 %cheat sheet
 %http://worldline.github.io/scala-cheatsheet/
 
@@ -89,10 +92,22 @@
 %% Section 10 about strings; interpolations and multiline strings
 
 
+% Exact colors from NB
+\usepackage[breakable]{tcolorbox}
+\definecolor{incolor}{HTML}{303F9F}
+\definecolor{outcolor}{HTML}{D84315}
+\definecolor{cellborder}{HTML}{CFCFCF}
+\definecolor{cellbackground}{HTML}{F7F7F7}
 
+
+    
 \begin{document}
 \fnote{\copyright{} Christian Urban, King's College London, 2017, 2018, 2019, 2020}
 
+%\begin{tcolorbox}[breakable,size=fbox,boxrule=1pt,pad at break*=1mm,colback=cellbackground,colframe=cellborder]
+%  abd
+%\end{tcolorbox}
+
 \section*{A Crash-Course in Scala}
 
 \mbox{}\hfill\textit{``Scala --- \underline{S}lowly \underline{c}ompiled 
@@ -441,6 +456,8 @@
 scala>
 \end{lstlisting}%$
 
+
+
 \noindent The precise response may vary depending
 on the version and platform where you installed Scala. At the Scala
 prompt you can type things like \code{2 + 3}\;\keys{Ret} and
@@ -500,8 +517,22 @@
 scala> List(1) == List(1)
 scala> Array(1) == Array(1)
 scala> Array(1).sameElements(Array(1))
+\end{lstlisting}
+
+\noindent
+Also observe carefully what Scala responds in the following 
+three instances involving the constant \lstinline!1!---can 
+you explain the differences?
+
+
+\begin{lstlisting}[numbers=none]
+scala> 1
+scala> 1L
+scala> 1F
 \end{lstlisting}\smallskip
 
+
+
 \noindent
 Please take the Scala REPL seriously: If you want to take advantage of my
 reference implementation for the assignments, you will need to be
@@ -659,14 +690,15 @@
 \noindent
 but this seems a bit overkill for a small function like \code{fact}.
 Note that Scala does not have a \code{then}-keyword in an
-\code{if}-statement; and there should be always an \code{else}-branch.
-Never write an \code{if} without an \code{else}, unless you know what
-you are doing! Note also that there are a few other ways of how to
-define a function. We will see some of them in the next sections.
+\code{if}-statement. Also important is that there should be always an
+\code{else}-branch. Never write an \code{if} without an \code{else},
+unless you know what you are doing! While \code{def} is the main
+mechanism for defining functions, there are a few other ways for doing
+this. We will see some of them in the next sections.
 
 Before we go on, let me explain one tricky point in function
-definitions, especially in larger definitions. What does a Scala function
-actually return? Scala has a \code{return} keyword, but it is
+definitions, especially in larger definitions. What does a Scala
+function return as result? Scala has a \code{return} keyword, but it is
 used for something different than in Java (and C/C++). Therefore please
 make sure no \code{return} slips into your Scala code.
 
@@ -687,8 +719,8 @@
 \noindent In this example the expression \code{s / n} is in the last
 line of the function---so this will be the result the function
 calculates. The two lines before just calculate intermediate values.
-This principle of the ``last-line'' comes in handy when you need to print
-out values, for example, for debugging purposes. Suppose you want
+This principle of the ``last-line'' comes in handy when you need to
+print out values, for example, for debugging purposes. Suppose you want
 rewrite the function as
 
 \begin{lstlisting}[numbers=none]
@@ -706,10 +738,12 @@
 The \code{println} before just prints out some information about the
 input of this function, but does not contribute to the result of the
 function. Similarly, the value \code{h} is used in the \code{println}
-but does not contribute to what integer is returned. However note that
-the idea with the ``last line'' is only a rough rule-of-thumb. A better
-rule might be: the last expression that is evaluated in the function.
-Consider the following version of \code{iaverage}:
+but does not contribute to what integer is returned. 
+
+A caveat is that the idea with the ``last line'' is only a rough
+rule-of-thumb. A better rule might be: the last expression that is
+evaluated in the function. Consider the following version of
+\code{average}:
 
 \begin{lstlisting}[numbers=none]
 def average(xs: List[Int]) : Int = {
@@ -719,11 +753,11 @@
 \end{lstlisting}
 
 \noindent
-What does this function return? Well are two possibilities: either the
-result of \code{xs.sum / xs.length} in the last line provided the list
-\code{xs} is nonempty, \textbf{or} if the list is empty, then it will
-return \code{0} from the \code{if}-branch (which is technically not the
-last line, but the last expression evaluated by the function in the
+What does this function return? Well there are two possibilities: either
+the result of \code{xs.sum / xs.length} in the last line provided the
+list \code{xs} is nonempty, \textbf{or} if the list is empty, then it
+will return \code{0} from the \code{if}-branch (which is technically not
+the last line, but the last expression evaluated by the function in the
 empty-case).
 
 Summing up, do not use \code{return} in your Scala code! A function