Cleanup.

Geoffrey Challen
1 parent 9330201e
Showing 3 changed files with 76 additions and 79 deletions
.ispell_english
introduction.tex
maybe.tex
+Android
+APIs
 app
+apps
+Wifi
 \section{Introduction}
-All programmers must deal with uncertainty about runtime environments. 
-For example, the most appropriate algorithm for a given task may 
-depend on inputs 
-that are unknown when the function is written, and its performance may 
-depend on device-specific features that are impossible for the developer to
+All programmers must deal with uncertainty about runtime environments. For
+example, the most appropriate algorithm for a given task may depend on inputs
+that are unknown when the function is written, and its performance may depend
+on device-specific features that are impossible for the developer to
 anticipate. In other cases, real-world testing may be required to choose
-between several approaches; This has led to the popularity of so-called AB
-or split testing.
-
-Uncertainty is especially problematic for mobile app programmers:
-Specific device features, such as
-accurate location from GPS, may or may not be available. Networks come and go,
-and their properties may change, from fast and free Wifi links to slower or
-metered mobile data connections. Energy may be plentiful or nearly exhausted,
-depending on the device's battery capacity and the user's energy consumption
-and charging patterns. These constantly fluctuating exogenous conditions
-make writing effective mobile apps particularly challenging.
-
-The most typical approach to address this problem is to force the
-programmer to implement the required adaptation themselves.
+between several approaches, which has led to the popularity of split testing.
+
+Uncertainty is especially problematic for mobile app programmers. Specific
+device features, such as accurate GPS location, may or may not be available.
+Networks come and go and their properties change: from fast and free Wifi
+links to slower metered mobile data connections. Energy may be plentiful or
+scarce, depending on the device's battery capacity and the user's energy
+consumption and charging patterns. These constantly fluctuating exogenous
+conditions make writing effective mobile apps particularly challenging.
+
+Today programmers are forced to anticipate these changing conditions at
+development time and implement the required adaptation themselves.
 Figure~\ref{fig-example-if} shows an example of an Android app attempting to
 adapt to the device's battery level by establishing regular- and low-battery
-code paths, with the latter attempting to save energy---by utilizing a slower
-but more energy-efficient algorithm, computing an approximation instead of an
-exact result, or deferring the computation.
-
-\sloppypar{ Unfortunately, this approach has several serious weaknesses. The
-most important is perhaps the least obvious: It is unclear that the
-different code paths achieve the desired result. There may be no differences
-between the alternatives (neither conserves energy), the alternative
-designed to conserve energy may actually consume more due to bugs or
-incorrect assumptions, or the result may also depend on some other factor not
-considered by the programmer, such as the type of network the device is
-connected to.}
+code paths, with the latter attempting to save energy, possibly by utilizing
+a slower but more energy-efficient algorithm, computing an approximate
+result, or deferring the computation.
+
+Unfortunately, this approach has several serious weaknesses. The most
+important is perhaps the least obvious: it is unclear that the different code
+paths achieve the desired result. There may be no differences between the
+alternatives (neither conserves energy), the alternative designed to conserve
+energy may actually consume more due to bugs or incorrect assumptions, or the
+result may also depend on some other factor not considered by the programmer,
+such as the type of network the device is currently using.
 In addition, adaptive programming frequently requires arbitrary decision
 thresholds chosen before deployment. Even if the two code paths shown in
@@ -51,15 +47,15 @@ if (plugged == false &amp;&amp; batteryLevel &lt; 10) {
 }
 \end{minted}
-\vspace*{-0.2in}
+\vspace*{-0.1in}
-\caption{\textbf{Typical Error-prone Energy Adaptation.} The threshold is
-arbitrary and the attempt to conserve energy may not work sometimes, for some
-users, or at all.}
+\caption{\textbf{Typical Error-Prone Energy Adaptation.} The threshold is
+arbitrary and the attempt to conserve energy succeed only at certain times,
+only for certain users, only on certain devices, or never.}
 \label{fig-example-if}
-\vspace*{-0.2in}
+\vspace*{-0.1in}
 \end{figure}
@@ -70,14 +66,14 @@ these common tasks require writing large amounts of error-prone boilerplate
 code, including APIs to adjust values at runtime and code to retrieve
 settings from remote servers.
-The root of the problem is that when it comes to the scope and effects of
-exogenous runtime conditions, \textbf{today's languages force programmers
-to be certain at a moment when they cannot be}, at compile time.
-This weakness is only exacerbated by the amount of variation across different 
-mobile devices. Our solution is simple: (1) Provide developers with a
-way to express structured uncertainty as sets of equivalent options,
-and (2) Use this structure to enable a robust array of downstream tools for 
-resolving uncertainty by selecting among options provided by the developer.
+The root of the problem is that \textbf{today's languages force programmers to
+be certain at a moment when they cannot be}: at development time. While this
+problem is endemic to existing programming languages, when developing mobile
+apps it is magnified by the amount of variation developers must confront. Our
+solution is simple: (1) provide developers with a way to express
+\textit{structured uncertainty}, and (2) use the resulting flexibility to
+enable a large array of downstream tools for resolving uncertainty by
+choosing from the alternatives provided by the developer.
 \begin{figure}[t]
@@ -91,31 +87,30 @@ maybe {
 \vspace*{-0.2in}
-\caption{\textbf{Example Use of the \texttt{maybe} Statement.} }
+\caption{\textbf{Example \texttt{maybe} Statement}}
 \label{fig-example-maybe}
 \vspace*{-0.2in}
 \end{figure}
-In this paper, we focus on the challenge of providing developers with
-a language construct for expressing structured uncertainty: The 
-\texttt{maybe} statement. \texttt{maybe} statements allow programmers to 
-express sets of equivalent options for both data and control-flow.
-Figure~\ref{fig-example-maybe} shows a simple case of a \texttt{maybe} case
-statement applied to our earlier example. Instead of being forced to choose,
-being forced to attempt to implement the decision process, or even required
-to evaluate multiple options, the programmer is free to offer two or more
-alternatives that are different but both correct, although one may be
-preferable. At runtime only one will be used during any given execution, with
-the system choosing the alternative that saves energy when it is appropriate
-to do so. Note that the branch that a \texttt{maybe} statement takes
-is not random; Rather, it tries to make the best choice and not just any choice.
+In this paper, we present a novel a language construct for expressing
+structured uncertainty: the \texttt{maybe} statement. \texttt{maybe}
+statements allow programmers to express sets of equivalent alternatives for
+both data and control-flow. Figure~\ref{fig-example-maybe} shows a simple
+case of a \texttt{maybe} case statement applied to our earlier example.
+Instead of being forced to choose, being forced to attempt to implement the
+decision process, or even required to evaluate multiple alternatives, the
+programmer is free to offer two or more alternatives that are different but
+both correct, although one may be preferable. At runtime only one will be
+used during any given execution, with the system both determining the energy
+tradeoffs produced by multiple alternatives and activating energy-saving
+alternatives when appropriate.
 How that choice is made is discussed in the remainder of our paper. We begin
 by providing a more complete description of the \texttt{maybe} statement in
-Section~\ref{sec-maybe}. Section~\ref{sec-certainty} describes several 
-techniques for collapsing compile-time uncertainty into the required runtime 
-certainty. We continue by
-briefly describing several example use cases in Section~\ref{sec-usage} and related work in Section~\ref{sec-related}.
-We conclude in Section~\ref{sec-conclusion}.
+Section~\ref{sec-maybe}. Section~\ref{sec-certainty} describes several
+techniques for collapsing compile-time uncertainty into the required runtime
+certainty. We continue by briefly describing several example use cases in
+Section~\ref{sec-usage} and related work in Section~\ref{sec-related}. We
+conclude in Section~\ref{sec-conclusion}.
 \section{\texttt{\large maybe} Statement Semantics}
 \label{sec-maybe}
-\sloppypar{To begin, we provide a brief overview of the semantics of the
-\texttt{maybe} statement, describing how it can express structured
-uncertainty in variable values and runtime execution. We refer to each of the
-values a \texttt{maybe} variable can take and each of the a paths a
-\texttt{maybe} code block can execute as an \textit{alternative}.
+To begin, we provide a brief overview of the semantics of the \texttt{maybe}
+statement, describing how it can express structured uncertainty in variable
+values and runtime execution. We refer to each of the values a \texttt{maybe}
+variable can take and each of the a paths a \texttt{maybe} code block can
+execute as an \textit{alternative}.
+
+Note that structured uncertainty is not randomness. The \texttt{maybe}
+statement indicates that during any given execution one alternative may be
+better than the others---even if the developer or system are not sure which
+alternative to use.
 \begin{figure}[t]
 \begin{minted}[fontsize=\footnotesize]{java}
@@ -51,17 +56,10 @@ else { cleanUpAfterSlowAlg(ret); }
 Variables can be used to represent uncertainty. Examples include an integer
 storing how often a timer should trigger communication with a remote server,
-or a string containing the name of a policy used to coordinate multiple
-code blocks through the app. 
-% Note that at present the \texttt{maybe}
-% statement controlling code blocks described below does not include features
-% required to coordinate multiple code blocks, and so if this functionality is
-% required, multiple \texttt{if-else} statements branching on a
-%\texttt{maybe}-derived variable can be used. 
-Figure~\ref{fig-maybeexamples}
-shows examples of an integer that can take on values between 1 and 16, and a
-string that be set to either ``auto'', ``quality'', or ``perf''.
-A s
+or a string containing the name of a policy used to coordinate multiple code
+blocks through the app. Figure~\ref{fig-maybeexamples} shows examples of an
+integer that can take on values between 1 and 16, and a string that be set to
+either ``auto'', ``quality'', or ``perf''.
 \subsection{Controlling Code Flow}