Add authors, minor changes

paper/2-background.tex

@@ -1,4 +1,3 @@
-\clearpage
 \section{Background}\label{sec-background}
 
 Build systems automate the execution of simple repeatable tasks for individual
@@ -178,6 +177,7 @@ \subsection{\Excel: dynamic dependencies at the cost of minimality}
 self-tracking further in~\S\ref{sec-tracking-aspects}.
 
 \begin{figure}[h]
+\vspace{-2mm}
 \begin{subfigure}[b]{0.90\linewidth}
 \centerline{\includegraphics[scale=0.28]{fig/shake-example.pdf}}
 \caption{Dependency graph produced after the previous build.}
@@ -190,7 +190,7 @@ \subsection{\Excel: dynamic dependencies at the cost of minimality}
 \vspace{-2mm}
 \caption{Dynamic dependencies example: create \cmd{README} and add it to the
 list of release documents \cmd{docs.txt}.\label{fig-shake}}
-\vspace{-3mm}
+\vspace{-4mm}
 \end{figure}
 
 \subsection{\Shake: dynamic dependencies with no remorse}

paper/3-abstractions.tex

@@ -90,6 +90,7 @@ \subsection{Common vocabulary for build systems}\label{sec-vocabulary}
 also contains information maintained by the build system itself, which persists
 from one invocation of the build system to the next -- its ``memory''.
 
+\vspace{-2mm}
 \paragraph{Task description} Any build system requires the user to specify how to
 compute the new value for one key, using the (up to date) values of its
 dependencies. We call this specification the \emph{task description}.  For
@@ -170,10 +171,8 @@ \subsection{The Build abstraction}\label{sec-general-build}
 The signature is very straightforward.  Given a task description, a target key,
 and a store, the build system returns a new store in which the value of the
 target key is up to date. What exactly does ``up to date'' mean?  We answer
-that precisely in \S\ref{sec-build-correctness}.
+that precisely in \S\ref{sec-build-correctness}. Here is a simple build system:
 
-\noindent
-Here is a simple build system:
 \vspace{1mm}
 \begin{minted}[xleftmargin=10pt]{haskell}
 busy :: Eq k => Build Monad () k v
@@ -413,9 +412,10 @@ \subsection{Correctness of a build system} \label{sec-build-correctness}
 indefinitely given a cyclic \hs{task}. Some build systems provide a limited
 support for cyclic tasks, see~\S\ref{sec-iterative-compute}.
 
-% The above definition of correctness needs to be adjusted to accommodate
-% non-deterministic tasks and shallow cloud builds; we address this
-% in sections~\S\ref{sec-non-determinism} and~\S\ref{sec-cloud-aspects}, respectively.
+The presented definition of correctness needs to be adjusted to accommodate
+non-deterministic tasks and shallow cloud builds, as will be discussed
+in sections~\S\ref{sec-non-determinism} and~\S\ref{sec-cloud-aspects},
+respectively.
 
 \subsection{Computing dependencies}\label{sec-deps}\label{secdeps}
 
@@ -425,12 +425,15 @@ \subsection{Computing dependencies}\label{sec-deps}\label{secdeps}
 has no such syntax tree. Yet, remarkably, we can use the polymorphism of a
 \hs{Task}~\hs{Applicative} to find its dependencies \emph{without doing any of
 the actual work}. Here is the code:
+
+\vspace{1mm}
 \begin{minted}[xleftmargin=10pt]{haskell}
 dependencies :: Task Applicative k v -> k -> [k]
 dependencies task key = case task (\k -> Const [k]) key of
                             Nothing         -> []
                             Just (Const ks) -> ks
 \end{minted}
+\vspace{1mm}
 
 Here \hs{Const} is a standard Haskell type defined in Fig.~\ref{fig-types}. We
 instantiate \hs{f} to \hs{Const}~\hs{[@@k]}.  So a value of type \hs{f}~\hs{v},
@@ -494,7 +497,7 @@ \subsection{Computing dependencies}\label{sec-deps}\label{secdeps}
 corresponding key. The \hs{task} returns the value of type
 \hs{Maybe}~\hs{(@@WriterT}~\hs{[@@k]}~\hs{m}~\hs{v)}, which we unwrap by applying
 \hs{runWriterT} to the contents of \hs{Maybe}.
-Here is an example of \hs{track}ing monadic tasks when \hs{m}~\hs{=}~\hs{IO}:
+Below we give an example of \hs{track}ing monadic tasks when \hs{m}~\hs{=}~\hs{IO}.
 
 \vspace{1mm}
 \begin{minted}[xleftmargin=10pt]{haskell}

paper/4-build.tex

@@ -23,6 +23,7 @@ \subsection{Respecting the dependency order}
 distinct approaches to respecting the dependency order. This subsection explores
 their properties and possible implementations.
 
+\vspace{-2mm}
 \subsubsection{Topological}\label{sec-topological}
 
 The topological approach pre-computes a linear order, which when followed, ensures
@@ -34,6 +35,7 @@ \subsubsection{Topological}\label{sec-topological}
 which requires the build system to choose \hs{c}~\hs{=}~\hs{Applicative}, ruling
 out dynamic dependencies.
 
+\vspace{-2mm}
 \subsubsection{Reordering}\label{sec-reordering}
 
 The topological approach has two downsides: it is limited to \hs{Applicative}
@@ -48,6 +50,7 @@ \subsubsection{Reordering}\label{sec-reordering}
 meaningful work, then abort. However, in the case of an \hs{Applicative} system,
 that work is zero.
 
+\vspace{-2mm}
 \subsubsection{Recursive}\label{sec-recursive}
 
 An alternative approach, utilised by the \hs{busy} build system
@@ -56,7 +59,7 @@ \subsubsection{Recursive}\label{sec-recursive}
 been built, you can obtain a minimal build system.
 
 This approach requires that a task may be started, then during that execution
-another task will have to be run. Assuming a an IO-driven task structure,
+another task will have to be run. Assuming an IO-driven task structure,
 that requires suspending a running task, which can be done with cheap
 green threads and blocking (the original approach of \Shake) or using
 continuation-passing style (what \Shake does currently). An alternative approach to
@@ -68,6 +71,7 @@ \subsection{Determining out-of-date keys} \label{sec-out-of-date}
 The second aspect, determining what to rebuild, can be addressed in one of three
 fundamental ways, with a number of tweaks and variations within them.
 
+\vspace{-2mm}
 \subsubsection{A dirty bit}\label{sec-dirty-bit}
 
 The idea of a dirty bit is to have one piece of persistent
@@ -120,6 +124,7 @@ \subsubsection{A dirty bit}\label{sec-dirty-bit}
 \Make can approximate early cutoff by not modifying the result file, and not marking it clean,
 but then it will rerun in every subsequent build.
 
+\vspace{-2mm}
 \subsubsection{Verifying traces}\label{sec-verifying-traces}
 
 An alternative way to determine if a key is dirty is to record what state the

paper/5-implementations.tex

@@ -181,13 +181,16 @@ \subsection{\Excel}\label{sec-implementation-excel}
 While not required for \Excel, we have implemented build systems using
 \hs{reordering} which use verifying and constructive traces, effectively turning
 \Excel into a cloud build system and ensuring \hs{reordering} is not overly
-fitted to \Excel alone (additional implementations will be submitted to the
-Artefact Evaluation).
+fitted to \Excel alone.
+%  (additional implementations will be submitted to the
+% Artefact Evaluation).
 
 In reality \Excel works slightly differently (as far as we are able to ascertain) --
 on a change it propagates the dirty bits forward using the \hs{dynamicDependencies}, then only checks if the current \hs{key} is dirty. While both methods are equivalent, merely changing the interleaving, our approach allows us to model more of the behaviour of \Excel.
 
+\vspace{-2mm}
 \subsection{\Shake}\label{sec-implementation-shake}
+\vspace{-1mm}
 
 The \Shake approach for dependency tracking involves recording traces and verifying them, for which we use the \hs{Trace} type defined in \ref{sec-verifying-traces}. Complete code is given in \S\ref{fig-shake-implementation}, split into three functions:
 
@@ -245,7 +248,9 @@ \subsection{\Shake}\label{sec-implementation-shake}
 \vspace{1mm}
 \end{figure}
 
+\vspace{-2mm}
 \subsection{\Bazel}\label{sec-implementation-bazel}
+\vspace{-1mm}
 
 \begin{figure}
 \begin{minted}[fontsize=\small]{haskell}
@@ -273,12 +278,9 @@ \subsection{\Bazel}\label{sec-implementation-bazel}
 Now we have seen all three dependency schemes, we can directly reuse \hs{topological} to define \Bazel. Furthermore, as \Bazel is a tracing build system, we can reuse \hs{Trace} and \hs{traceMatch}, along with the \hs{Traces} type from \S\ref{sec-constructive-traces}. With these pieces in place, the implementation of \Bazel is given in Fig.~\ref{fig-bazel-implementation}. We first figure out the possible results given the current state. If there are no recorded traces for the current dependencies we run it and record the results, otherwise grab a suitable result from the \hs{contents} cache.
 
 The program presented above captures certain aspects of \Bazel, but the real implementation makes one important additional assumption on \hs{Task} -- namely that it is \textit{deterministic}. With that assumption \Bazel is able to create the result hash in a trace by hashing together the result hashes of the dependencies and the key -- as the mapping between dependencies and results is deterministic. As a consequence \Bazel can compute the results of traces locally, without looking at \hs{Traces} (potentially saving a roundtrip to the server). To model this change in the code would require storing an additional transient piece of information \hs{done} of type \hs{Map}~\hs{k}~\hs{(Hash}~\hs{v)}, storing the computed hashes so far this run. With that available, \hs{getHash}~\hs{key}~\hs{s} would become:
-
 \begin{minted}[xleftmargin=10pt]{haskell}
 hash (key, [ done Map.! d | d <- ds ])
 \end{minted}
-
-\noindent
 And that new hash would have to be stored in \hs{done}.
 
 \subsection{Cloud \Shake}\label{sec-implementation-cloud-shake}
@@ -305,7 +307,7 @@ \subsection{Cloud \Shake}\label{sec-implementation-cloud-shake}
 \end{minted}
 \vspace{-2mm}
 \caption{An implementation of Cloud \Shake using our framework.}\label{fig-cloudshake-implementation}
-\vspace{-2mm}
+\vspace{-4mm}
 \end{figure}
 
 The differences from \hs{bazel} are minor~--~the dependency scheme has changed
@@ -314,13 +316,15 @@ \subsection{Cloud \Shake}\label{sec-implementation-cloud-shake}
 gained a list of keys, and the checking calls \hs{fetch} to get the result
 instead of accessing the store directly.
 
+\vspace{-1mm}
 \subsection{Smarter \hs{[Trace]} data structures}\label{sec-smart-traces}
+\vspace{-1mm}
 
 In the examples above, we have used \hs{[Trace}~\hs{k}~\hs{v]} to capture a list
 of traces~--~however, using a list necessarily means that finding the right trace
 takes $O(n)$. For each of the \hs{Trace} based systems it is possible to devise
 a smarter representation, which we sketch below. Note that these implementations
-do not reduce calls to \hs{compute}, merely overheads in the build system itself.
+do not avoid calls to \hs{compute}, merely overheads in the build system itself.
 
 \begin{enumerate}
 \item Any system using verifying traces, e.g. \Shake, is unlikely to see significant benefit from storing more than one \hs{Trace} per key\footnote{There is a small chance of a benefit if the dependencies change but the result does not, and then the dependencies change back to what they were before.}. Therefore, such systems can store \hs{Map}~\hs{k}~\hs{(Trace}~\hs{k}~\hs{v)}, where the initial \hs{k} is the \hs{key} field of \hs{Trace}.

paper/7-related.tex

@@ -167,4 +167,4 @@ \subsection{Profunctor Optics}\label{sec-related-optics}
 \hs{dependencies} are very much based on observations from that field of work.
 Alas, we have been unable to remove the \hs{Maybe} used to encode whether a file
 is an input, without complicating other aspects of our definition. Furthermore,
-the \hs{Build} operation lacks any further such symmetry.
+the \hs{Build} abstraction lacks any further such symmetry.

paper/comment.cut

@@ -0,0 +1,9 @@
+  %% contents suppressed with 'anonymous'
+  %% Commands \grantsponsor{<sponsorID>}{<name>}{<url>} and
+  %% \grantnum[<url>]{<sponsorID>}{<number>} should be used to
+  %% acknowledge financial support and will be used by metadata
+  %% extraction tools.
+  Thank you for reading and feedback!
+
+  Andrey Mokhov is funded by a Royal Society Industry Fellowship on the topic
+  ``Towards Cloud Build Systems with Dynamic Dependency Graphs''.

paper/main.tex

@@ -1,9 +1,9 @@
 %% For double-blind review submission, w/o CCS and ACM Reference (max submission space)
-\documentclass[acmsmall,review,anonymous]{acmart}\settopmatter{printfolios=true,printccs=false,printacmref=false}
+% \documentclass[acmsmall,review,anonymous]{acmart}\settopmatter{printfolios=true,printccs=false,printacmref=false}
 %% For double-blind review submission, w/ CCS and ACM Reference
 %\documentclass[acmsmall,review,anonymous]{acmart}\settopmatter{printfolios=true}
-%% For single-blind review submission, w/o CCS and ACM Reference (max submission space)
-%\documentclass[acmsmall,review]{acmart}\settopmatter{printfolios=true,printccs=false,printacmref=false}
+% For single-blind review submission, w/o CCS and ACM Reference (max submission space)
+\documentclass[acmsmall,review]{acmart}\settopmatter{printfolios=true,printccs=false,printacmref=false}
 %% For single-blind review submission, w/ CCS and ACM Reference
 %\documentclass[acmsmall,review]{acmart}\settopmatter{printfolios=true}
 %% For final camera-ready submission, w/ required CCS and ACM Reference
@@ -48,6 +48,7 @@
 \usepackage[utf8]{inputenc}
 \usepackage[T1]{fontenc}
 \usepackage{xspace}
+\usepackage{fancyhdr}
 
 % Haskell code snippets and useful shortcuts
 \usepackage{minted}
@@ -86,63 +87,64 @@
 %% [Short title] Title
 \title[Build Systems \`a la Carte]{Build Systems \`a la Carte}
 % \titlenote{with title note}
-% \subtitle{Subtitle}
+\subtitle{(Under review, feedback is sought)}
 % \subtitlenote{with subtitle note}
 
-%% Author information
-%% Contents and number of authors suppressed with 'anonymous'.
-%% Each author should be introduced by \author, followed by
-%% \authornote (optional), \orcid (optional), \affiliation, and
-%% \email.
 %% An author may have multiple affiliations and/or emails; repeat the
 %% appropriate command.
 %% Many elements are not rendered, but should be provided for metadata
 %% extraction tools.
-
-%% Author with single affiliation.
-\author{First1 Last1}
-\authornote{with author1 note}          %% \authornote is optional;
-                                        %% can be repeated if necessary
-\orcid{nnnn-nnnn-nnnn-nnnn}             %% \orcid is optional
+\author{Andrey Mokhov}
 \affiliation{
-  \position{Position1}
-  \department{Department1}              %% \department is recommended
-  \institution{Institution1}            %% \institution is required
-  \streetaddress{Street1 Address1}
-  \city{City1}
-  \state{State1}
-  \postcode{Post-Code1}
-  \country{Country1}                    %% \country is recommended
+  \department{School of Engineering}
+  \institution{Newcastle University}
+  \city{Newcastle upon Tyne}
+  \country{United Kingdom}
 }
-\email{[email protected]}          %% \email is recommended
+\email{[email protected]}
 
-%% Author with two affiliations and emails.
-\author{First2 Last2}
-\authornote{with author2 note}          %% \authornote is optional;
-                                        %% can be repeated if necessary
-\orcid{nnnn-nnnn-nnnn-nnnn}             %% \orcid is optional
+\author{Neil Mitchell}
 \affiliation{
-  \position{Position2a}
-  \department{Department2a}             %% \department is recommended
-  \institution{Institution2a}           %% \institution is required
-  \streetaddress{Street2a Address2a}
-  \city{City2a}
-  \state{State2a}
-  \postcode{Post-Code2a}
-  \country{Country2a}                   %% \country is recommended
+  \institution{Digital Asset}
+  \country{United Kingdom}
 }
-\email{[email protected]}         %% \email is recommended
+\email{[email protected]}
+
+\author{Simon Peyton Jones}
 \affiliation{
-  \position{Position2b}
-  \department{Department2b}             %% \department is recommended
-  \institution{Institution2b}           %% \institution is required
-  \streetaddress{Street3b Address2b}
-  \city{City2b}
-  \state{State2b}
-  \postcode{Post-Code2b}
-  \country{Country2b}                   %% \country is recommended
+  \institution{Microsoft Research}
+  \city{Cambridge}
+  \country{United Kingdom}
 }
-\email{[email protected]}         %% \email is recommended
+\email{[email protected]}
+
+%% Author with two affiliations and emails.
+% \author{First2 Last2}
+% \authornote{with author2 note}          %% \authornote is optional;
+%                                         %% can be repeated if necessary
+% \orcid{nnnn-nnnn-nnnn-nnnn}             %% \orcid is optional
+% \affiliation{
+%   \position{Position2a}
+%   \department{Department2a}             %% \department is recommended
+%   \institution{Institution2a}           %% \institution is required
+%   \streetaddress{Street2a Address2a}
+%   \city{City2a}
+%   \state{State2a}
+%   \postcode{Post-Code2a}
+%   \country{Country2a}                   %% \country is recommended
+% }
+% \email{[email protected]}         %% \email is recommended
+% \affiliation{
+%   \position{Position2b}
+%   \department{Department2b}             %% \department is recommended
+%   \institution{Institution2b}           %% \institution is required
+%   \streetaddress{Street3b Address2b}
+%   \city{City2b}
+%   \state{State2b}
+%   \postcode{Post-Code2b}
+%   \country{Country2b}                   %% \country is recommended
+% }
+% \email{[email protected]}         %% \email is recommended
 
 \begin{abstract}
 Build systems are awesome, terrifying -- and unloved.
@@ -174,8 +176,7 @@
 \ccsdesc[500]{Software and its engineering~General programming languages}
 \ccsdesc[300]{Social and professional topics~History of programming languages}
 %% End of generated code
-
-% \keywords{functional programming, build systems}
+% \keywords{build systems, functional programming, algorithms}
 
 \maketitle
 
@@ -195,7 +196,10 @@
   %% \grantnum[<url>]{<sponsorID>}{<number>} should be used to
   %% acknowledge financial support and will be used by metadata
   %% extraction tools.
-  We would like to thank ...
+  Thank you for reading and feedback!
+
+  Andrey Mokhov is funded by a Royal Society Industry Fellowship on the topic
+  ``Towards Cloud Build Systems with Dynamic Dependency Graphs''.
 \end{acks}
 
 \bibliography{refs}