Began using listings in earnest. Added motivation section.

src/main/book/content/bibliography/monadic.aux

@@ -1,6 +1,6 @@
 \relax 
 \@setckpt{bibliography/monadic}{
-\setcounter{page}{24}
+\setcounter{page}{30}
 \setcounter{equation}{0}
 \setcounter{enumi}{0}
 \setcounter{enumii}{0}
@@ -20,8 +20,8 @@
 \setcounter{parentequation}{0}
 \setcounter{Item}{0}
 \setcounter{Hfootnote}{0}
-\setcounter{lstlisting}{0}
 \setcounter{lstnumber}{1}
 \setcounter{theorem}{0}
 \setcounter{section@level}{1}
+\setcounter{lstlisting}{0}
 }

src/main/book/content/chapters/eight/ch.aux

@@ -1,12 +1,12 @@
 \relax 
-\@writefile{toc}{\contentsline {chapter}{\numberline {8}Domain model, storage and state}{19}{chapter.8}}
+\@writefile{toc}{\contentsline {chapter}{\numberline {8}Domain model, storage and state}{25}{chapter.8}}
 \@writefile{lof}{\addvspace {10\p@ }}
 \@writefile{lot}{\addvspace {10\p@ }}
-\@writefile{toc}{\contentsline {section}{\numberline {8.1}Mapping our domain model to storage}{19}{section.8.1}}
-\@writefile{toc}{\contentsline {section}{\numberline {8.2}Storage and language-integrated query}{19}{section.8.2}}
-\@writefile{toc}{\contentsline {section}{\numberline {8.3}Continuations revisited}{19}{section.8.3}}
+\@writefile{toc}{\contentsline {section}{\numberline {8.1}Mapping our domain model to storage}{25}{section.8.1}}
+\@writefile{toc}{\contentsline {section}{\numberline {8.2}Storage and language-integrated query}{25}{section.8.2}}
+\@writefile{toc}{\contentsline {section}{\numberline {8.3}Continuations revisited}{25}{section.8.3}}
 \@setckpt{chapters/eight/ch}{
-\setcounter{page}{20}
+\setcounter{page}{26}
 \setcounter{equation}{0}
 \setcounter{enumi}{0}
 \setcounter{enumii}{0}
@@ -26,8 +26,8 @@
 \setcounter{parentequation}{0}
 \setcounter{Item}{0}
 \setcounter{Hfootnote}{0}
-\setcounter{lstlisting}{0}
 \setcounter{lstnumber}{1}
 \setcounter{theorem}{0}
 \setcounter{section@level}{1}
+\setcounter{lstlisting}{0}
 }

src/main/book/content/chapters/five/ch.aux

@@ -1,12 +1,12 @@
 \relax 
-\@writefile{toc}{\contentsline {chapter}{\numberline {5}The domain model as abstract syntax}{13}{chapter.5}}
+\@writefile{toc}{\contentsline {chapter}{\numberline {5}The domain model as abstract syntax}{19}{chapter.5}}
 \@writefile{lof}{\addvspace {10\p@ }}
 \@writefile{lot}{\addvspace {10\p@ }}
-\@writefile{toc}{\contentsline {section}{\numberline {5.1}Our abstract syntax}{13}{section.5.1}}
-\@writefile{toc}{\contentsline {section}{\numberline {5.2}Our application domain model}{13}{section.5.2}}
-\@writefile{toc}{\contentsline {section}{\numberline {5.3}A transform pipeline}{13}{section.5.3}}
+\@writefile{toc}{\contentsline {section}{\numberline {5.1}Our abstract syntax}{19}{section.5.1}}
+\@writefile{toc}{\contentsline {section}{\numberline {5.2}Our application domain model}{19}{section.5.2}}
+\@writefile{toc}{\contentsline {section}{\numberline {5.3}A transform pipeline}{19}{section.5.3}}
 \@setckpt{chapters/five/ch}{
-\setcounter{page}{14}
+\setcounter{page}{20}
 \setcounter{equation}{0}
 \setcounter{enumi}{0}
 \setcounter{enumii}{0}
@@ -26,8 +26,8 @@
 \setcounter{parentequation}{0}
 \setcounter{Item}{0}
 \setcounter{Hfootnote}{0}
-\setcounter{lstlisting}{0}
 \setcounter{lstnumber}{1}
 \setcounter{theorem}{0}
 \setcounter{section@level}{1}
+\setcounter{lstlisting}{0}
 }

src/main/book/content/chapters/four/ch.aux

@@ -1,12 +1,12 @@
 \relax 
-\@writefile{toc}{\contentsline {chapter}{\numberline {4}Parsing requests, monadically}{11}{chapter.4}}
+\@writefile{toc}{\contentsline {chapter}{\numberline {4}Parsing requests, monadically}{17}{chapter.4}}
 \@writefile{lof}{\addvspace {10\p@ }}
 \@writefile{lot}{\addvspace {10\p@ }}
-\@writefile{toc}{\contentsline {section}{\numberline {4.1}Obligatory parsing monad}{11}{section.4.1}}
-\@writefile{toc}{\contentsline {section}{\numberline {4.2}Your parser combinators are showing}{11}{section.4.2}}
-\@writefile{toc}{\contentsline {section}{\numberline {4.3}EBNF and why higher levels of abstraction are better}{11}{section.4.3}}
+\@writefile{toc}{\contentsline {section}{\numberline {4.1}Obligatory parsing monad}{17}{section.4.1}}
+\@writefile{toc}{\contentsline {section}{\numberline {4.2}Your parser combinators are showing}{17}{section.4.2}}
+\@writefile{toc}{\contentsline {section}{\numberline {4.3}EBNF and why higher levels of abstraction are better}{17}{section.4.3}}
 \@setckpt{chapters/four/ch}{
-\setcounter{page}{12}
+\setcounter{page}{18}
 \setcounter{equation}{0}
 \setcounter{enumi}{0}
 \setcounter{enumii}{0}
@@ -26,8 +26,8 @@
 \setcounter{parentequation}{0}
 \setcounter{Item}{0}
 \setcounter{Hfootnote}{0}
-\setcounter{lstlisting}{0}
 \setcounter{lstnumber}{1}
 \setcounter{theorem}{0}
 \setcounter{section@level}{1}
+\setcounter{lstlisting}{0}
 }

src/main/book/content/chapters/nine/ch.aux

@@ -1,13 +1,13 @@
 \relax 
-\@writefile{toc}{\contentsline {chapter}{\numberline {9}Putting it all together}{21}{chapter.9}}
+\@writefile{toc}{\contentsline {chapter}{\numberline {9}Putting it all together}{27}{chapter.9}}
 \@writefile{lof}{\addvspace {10\p@ }}
 \@writefile{lot}{\addvspace {10\p@ }}
-\@writefile{toc}{\contentsline {section}{\numberline {9.1}Our web application end-to-end}{21}{section.9.1}}
-\@writefile{toc}{\contentsline {section}{\numberline {9.2}Deploying our application}{21}{section.9.2}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {9.2.1}Why we are not deploying on GAE}{21}{subsection.9.2.1}}
-\@writefile{toc}{\contentsline {section}{\numberline {9.3}From one web application to web framework}{21}{section.9.3}}
+\@writefile{toc}{\contentsline {section}{\numberline {9.1}Our web application end-to-end}{27}{section.9.1}}
+\@writefile{toc}{\contentsline {section}{\numberline {9.2}Deploying our application}{27}{section.9.2}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {9.2.1}Why we are not deploying on GAE}{27}{subsection.9.2.1}}
+\@writefile{toc}{\contentsline {section}{\numberline {9.3}From one web application to web framework}{27}{section.9.3}}
 \@setckpt{chapters/nine/ch}{
-\setcounter{page}{22}
+\setcounter{page}{28}
 \setcounter{equation}{0}
 \setcounter{enumi}{0}
 \setcounter{enumii}{0}
@@ -27,8 +27,8 @@
 \setcounter{parentequation}{0}
 \setcounter{Item}{0}
 \setcounter{Hfootnote}{0}
-\setcounter{lstlisting}{0}
 \setcounter{lstnumber}{1}
 \setcounter{theorem}{0}
 \setcounter{section@level}{1}
+\setcounter{lstlisting}{0}
 }

src/main/book/content/chapters/one/ch.aux

@@ -4,16 +4,16 @@
 \@writefile{lot}{\addvspace {10\p@ }}
 \@writefile{toc}{\contentsline {section}{\numberline {1.1}Where are we}{3}{section.1.1}}
 \@writefile{toc}{\contentsline {subsection}{\numberline {1.1.1}The concurrency squeeze: from the hardware up, from the web down}{3}{subsection.1.1.1}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {1.1.2}Ubiquity of robust, high-performance virtual machines}{5}{subsection.1.1.2}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.1.2}Ubiquity of robust, high-performance virtual machines}{4}{subsection.1.1.2}}
 \@writefile{toc}{\contentsline {subsection}{\numberline {1.1.3}Advances in functional programming, monads and the awkward squad}{5}{subsection.1.1.3}}
-\@writefile{toc}{\contentsline {section}{\numberline {1.2}Where are we going}{5}{section.1.2}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {1.2.1}A functional web}{5}{subsection.1.2.1}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {1.2.2}DSL-based design}{5}{subsection.1.2.2}}
-\@writefile{toc}{\contentsline {section}{\numberline {1.3}How are we going to get there}{5}{section.1.3}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {1.3.1}Leading by example}{5}{subsection.1.3.1}}
-\@writefile{toc}{\contentsline {subsubsection}{Our toy language}{5}{section*.6}}
+\@writefile{toc}{\contentsline {section}{\numberline {1.2}Where are we going}{7}{section.1.2}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.2.1}A functional web}{7}{subsection.1.2.1}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.2.2}DSL-based design}{7}{subsection.1.2.2}}
+\@writefile{toc}{\contentsline {section}{\numberline {1.3}How are we going to get there}{7}{section.1.3}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.3.1}Leading by example}{7}{subsection.1.3.1}}
+\@writefile{toc}{\contentsline {subsubsection}{Our toy language}{7}{section*.6}}
 \@setckpt{chapters/one/ch}{
-\setcounter{page}{7}
+\setcounter{page}{9}
 \setcounter{equation}{0}
 \setcounter{enumi}{0}
 \setcounter{enumii}{0}
@@ -33,8 +33,8 @@
 \setcounter{parentequation}{0}
 \setcounter{Item}{0}
 \setcounter{Hfootnote}{0}
-\setcounter{lstlisting}{0}
 \setcounter{lstnumber}{1}
 \setcounter{theorem}{0}
 \setcounter{section@level}{3}
+\setcounter{lstlisting}{0}
 }

src/main/book/content/chapters/one/how-are-we-going-to-get-there.tex

@@ -14,12 +14,12 @@ \subsection{Leading by example}
 cloud-based editor for a simple programming language, not unlike
 \texttt{Mozilla's bespin} . A user can register with the service and
 then create an application project which allows them
-% \begin{list}
-%    \item to write code in a structured editor that understands the language;
-%    \item manage files in the application project;
-%    \item compile the application;
-%    \item run the application
-% \end{list}
+\begin{itemize}
+   \item to write code in a structured editor that understands the language;
+   \item manage files in the application project;
+   \item compile the application;
+   \item run the application
+\end{itemize}
 
 \subsubsection{Our toy language}
 

src/main/book/content/chapters/one/where-are-we.tex

@@ -3,10 +3,10 @@ \section{Where are we}
 \subsection{The concurrency squeeze: from the hardware up, from the web down}
 
 It used to be fashionable in academic papers or think tank reports to
-predict or bemoan the imminent demise of Moore's law, to wax on about
-the need to ``go sideways'' in hardware design from the number of
-cores per die to the number of processors per box. Those days of
-polite conversation about the on coming storm are definitely in our
+predict and then bemoan the imminent demise of Moore's law, to wax on
+about the need to ``go sideways'' in hardware design from the number
+of cores per die to the number of processors per box. Those days of
+polite conversation about the on-coming storm are definitely in our
 rear view mirror. Today's developer knows that if her program is
 commercially interesting at all then it needs to be web-accessible on
 a 24x7 basis; and if it's going to be commercially significant it will
@@ -40,24 +40,127 @@ \subsection{The concurrency squeeze: from the hardware up, from the web down}
 considerably improve productivity and maintainability. Java brought
 the C/C++ programmer several steps closer to a functional paradigm,
 introducing garbage collection, type abstractions such as generics and
-other niceties. Languages like OCaml, F\# and Scala go a step further,
-bringing the modern developer into contact with higher order
-functions, the relationship between types and pattern matching and
-powerful abstractions like monads. Yet, functional programming does
-not embrace concurrency and distribution in its foundations. It is not
-based a model of computation, like the actor model or the process
-calculi that are based on a notion of execution that is fundamentally
-concurrent. That said, it meshes nicely with a variety of concurrency
-programming models. In particular, the combination of higher order
-functions (with the ability to pass functions as arguments and return
-functions as values) together with the structuring techniques of
-monads make models such as software transactional memory or data flow
-parallelism quite easy to integrate, while pattern-matching
-additionally makes message-passing style easier to incorporate.
+other niceties. Languages like \texttt{OCaml}, \texttt{F\#} and
+\texttt{Scala} go a step further, bringing the modern developer into
+contact with higher order functions, the relationship between types
+and pattern matching and powerful abstractions like monads. Yet,
+functional programming does not embrace concurrency and distribution
+in its foundations. It is not based on a model of computation, like
+the actor model or the process calculi, in which the notion of
+execution that is fundamentally concurrent. That said, it meshes
+nicely with a variety of concurrency programming models. In
+particular, the combination of higher order functions (with the
+ability to pass functions as arguments and return functions as values)
+together with the structuring techniques of monads make models such as
+software transactional memory or data flow parallelism quite easy to
+integrate, while pattern-matching additionally makes message-passing
+style easier to incorporate.
 
 \subsection{Ubiquity of robust, high-performance virtual machines}
 
-
+Another reality of the modern programmer's life is the ubiquity of
+robust, high-performance virtual machines. Both the \texttt{Java}
+Virtual Machine (\texttt{JVM}) and the Common Language Runtime
+(\texttt{CLR}) provide manage code execution environments that are not
+just competitive with their unmanaged counterparts (such as \texttt{C}
+and \texttt{C++}), but actually the dominant choice for many
+applications. This has two effects that are playing themselves out in
+terms of industry trends. Firstly, it provides some level of
+insulation between changes in hardware design (from single core per
+die to multi-core, for example) that impacts execution model and
+language level interface. To illustrate the point note that these
+changes in hardware have impacted memory models. This has a much
+greater impact on the \texttt{C/C++} family of languages than on
+\texttt{Java} because the latter is built on an abstract machine that
+hides the underlying memory model. One may, in fact, contemplate an
+ironic future in which this abstraction alone causes managed code to
+outperform \texttt{C/C++} code because of \texttt{C/C++}'s faulty
+assumptions about best use of memory. Secondly, it completely changes
+the landscape for language development. By providing a much higher
+level and more uniform target for language execution semantics it
+lowers the barrier to entry for contending language designs. It is not
+surprising, therefore, that we have seen an explosion in language
+proposals in the last several years, including \texttt{Clojure},
+\texttt{Fortress}, \texttt{Scala}, \texttt{F\#} and many others. It
+should not escape notice that all of the languages in that list and
+the majority of the proposals coming out are either functional
+languages, object-functional languages, or heavily influenced by
+functional language design concepts.
 
 \subsection{Advances in functional programming, monads and the awkward squad}
 
+One of the reasons that language design proposals have been so heavily
+influenced by functional language design principles is that functional
+language design has made demonstrable progress. Since the '80's when
+\texttt{Lisp} and it's progeny were thrown out of the industry for
+performance failures a lot of excellent work has gone on that has
+rectified many of the problems those languages faced. In particular,
+while \texttt{Lisp} implementations tried to take a practical approach
+to certain aspects of computation, chiefly having to do with
+side-effecting operations and i/o, the underlying semantic model did
+not seem well-suited to address those kinds of computations. And yet,
+not only are side-effecting computations and especially i/o
+ubiquitous, using them led (at least initially) to considerably better
+performance. Avoiding those operations (sometimes called functional
+purity) seemed to be an academic exercise not well suited to writing
+``real world'' applications.
+
+However, while many industry shops were throwing out functional
+languages, except for niche applications, work was going on that would
+reverse this trend. One of the key developments in this was an early
+bifurcation of functional language designs at a fairly fundamental
+level. The \texttt{Lisp} family of languages are untyped and
+dynamic. In the modern world the lack of typing might seem egregiously
+unmaintainable, but by comparison to \texttt{C} it was more than made
+up for by the kind of dynamic meta-programming that these languages
+made possible. Programmers enjoyed a certain kind of productivity
+because they could ``go meta'' -- writing programs to write programs
+(even dynamically modify them on the fly) -- in a uniform manner. This
+sort of feature has become mainstream, as found in \texttt{Ruby} or
+even \texttt{Java}'s reflection API, precisely because it is so
+extremely useful. Unfortunately, the productivity gains of
+meta-programming were not enough to offset the performance shortfalls
+at the time.
+
+There was, however, a statically typed branch of functional
+programming that began to have traction in certain academic circles
+with the development of the \texttt{ML} family of languages -- which
+today includes \texttt{OCaml}, which can be considered the direct
+ancestor of \texttt{Scala}. One of the very first developments in that
+line of investigation was the recognition that data description came
+in not just one but \emph{two} flavors: types and \emph{patterns}. The
+two flavors, it was recognized, are dual. Types tell the program how
+data was built up from its components while patterns tell a program
+how to take data apart in terms of its components. These are the
+origins of elements in \texttt{Scala}'s design like
+\lstinline[language=Scala]!case class!es and the
+\lstinline[language=Scala]!match! construct. The \texttt{ML} family of
+languages also gave us the first workable parametric polymorphism
+(that's generic types to you). 
+
+Still these languages suffered when it came to a compelling and
+uniform treatment of side-effecting computations. That all changed
+with Haskell. In the mid-80's a young researcher by the name of
+Eugenio Moggi observed that an idea previously discovered in a then
+obscure branch of mathematics (called category theory) offered a way
+to \emph{structure} functional programs to allow them to deal with
+side-effecting computations in uniform and compelling
+manner. Essentially, the notion of a monad (as it was called in the
+category theory literature) provided a language level abstraction for
+structuring side-effecting computations in a functional setting. In
+today's parlance, he found a domain specific language, a DSL, for
+organizing side-effecting computations in an ambient (or hosting)
+functional language. Once Moggi made this discovery another
+researcher, Phil Wadler, realized that this DSL had a couple of
+different ``presentations'' that were almost immediately
+understandable by the average programmer. One presentation, called
+comprehensions (after it's counter part in set theory), could be
+understood directly in terms of a very familiar construct
+\lstinline[language=SQL]!SELECT ... FROM ... WHERE ...!; while the
+other, dubbed \lstinline[language=Haskell]!do!-notation by the
+\texttt{Haskell} community, provided operations that behaved
+remarkably like sequencing and assignment. \texttt{Haskell} offers
+syntactic sugar to support the latter while the former has been
+adopted in both \texttt{XQuery}'s
+\lstinline[language=XML]!FLWOR!-expressions and Microsoft's
+\texttt{LINQ}

src/main/book/content/chapters/seven/ch.aux

@@ -1,11 +1,11 @@
 \relax 
-\@writefile{toc}{\contentsline {chapter}{\numberline {7}A review of collections as monads}{17}{chapter.7}}
+\@writefile{toc}{\contentsline {chapter}{\numberline {7}A review of collections as monads}{23}{chapter.7}}
 \@writefile{lof}{\addvspace {10\p@ }}
 \@writefile{lot}{\addvspace {10\p@ }}
-\@writefile{toc}{\contentsline {section}{\numberline {7.1}Monad as container}{17}{section.7.1}}
-\@writefile{toc}{\contentsline {section}{\numberline {7.2}Monads and take-out}{17}{section.7.2}}
+\@writefile{toc}{\contentsline {section}{\numberline {7.1}Monad as container}{23}{section.7.1}}
+\@writefile{toc}{\contentsline {section}{\numberline {7.2}Monads and take-out}{23}{section.7.2}}
 \@setckpt{chapters/seven/ch}{
-\setcounter{page}{18}
+\setcounter{page}{24}
 \setcounter{equation}{0}
 \setcounter{enumi}{0}
 \setcounter{enumii}{0}
@@ -25,8 +25,8 @@
 \setcounter{parentequation}{0}
 \setcounter{Item}{0}
 \setcounter{Hfootnote}{0}
-\setcounter{lstlisting}{0}
 \setcounter{lstnumber}{1}
 \setcounter{theorem}{0}
 \setcounter{section@level}{1}
+\setcounter{lstlisting}{0}
 }