diff --git a/introduction.tex b/introduction.tex index 5b53f8a..67cf855 100644 --- a/introduction.tex +++ b/introduction.tex @@ -85,27 +85,29 @@ maybe { } \end{minted} -\vspace*{-0.2in} +\vspace*{-0.1in} -\caption{\textbf{Example \texttt{maybe} Statement}} +\caption{\textbf{Example \texttt{maybe} Statement.} The programmer provides +multiple equivalent alternatives.} \label{fig-example-maybe} -\vspace*{-0.2in} +\vspace*{-0.1in} \end{figure} 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. +structured uncertainty: the \texttt{maybe} statement. \texttt{maybe} allows +the programmer to express and structure their uncertainty by providing two or +more different \textit{alternatives} which together implement multiple +approaches to runtime adaptation, possibly by making the same +energy-performance or energy-accuracy tradeoffs described previously. +Figure~\ref{fig-example-maybe} shows how our earlier example can be easily +rewritten to use a \texttt{maybe} statement. However, unlike the previous +example \texttt{maybe} does rely on the developer to implement a decision +process or correctly anticipate the effects of each alternative. Instead, the +\texttt{maybe} system makes runtime choices about which alternative to use by +measuring the tradeoffs produced by each alternative and (in this case) +activating an energy-saving alternative 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 diff --git a/maybe.tex b/maybe.tex index f0f6024..1e4e6b7 100644 --- a/maybe.tex +++ b/maybe.tex @@ -1,11 +1,10 @@ \section{\texttt{\large maybe} Statement Semantics} \label{sec-maybe} -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 or paths a \texttt{maybe} code block can execute as an -\textit{alternative}. +To begin we provide an overview of the \texttt{maybe} statements semantics, +describing how it structures uncertainty in variable values and runtime +execution. We refer to each of the values a \texttt{maybe} variable can take +or paths a \texttt{maybe} code block can execute as an \textit{alternative}. \begin{figure}[t] \begin{minted}[fontsize=\footnotesize]{java} @@ -89,38 +88,30 @@ annotations. We will return to post-mortem evaluation in Section~\ref{sec-certainty}. -\subsection{Programming With \texttt{\large maybe}} +\subsection{Discussion} We have yet to determine how well programmers will be able to use the new \texttt{maybe} construct. At some level, \texttt{maybe} statements are -similar to the common \texttt{if-else} construct. At the bottom of the -statement, the programmer may not be sure which block was executed. Of -course, with \texttt{if-else} blocks it can be determined which block was -executed by examining the branch conditions. When working with the -\texttt{maybe} statement, the developer must set a variable inside each -\texttt{maybe} block if downstream code depends on which alternative was -chosen, as in Figure~\ref{fig-maybeexamples}. Alternatively, programmers may -use a \texttt{maybe} variable to select a policy, and employ the traditional -\texttt{if-else} construct to direct control flow based on the \texttt{maybe} -variable. - -\subsection{When Not To Use \texttt{\large maybe}} -% 10/13 by OK: -% We don't discuss dependencies between maybe statements anywhere else, so I'm -% killing the ref here. It's still true that we're creating an exponential -% search space of possibilities; so the same text is getting re-purposed for -% that. +similar to the common \texttt{if-else} construct in that at the bottom of the +statement the programmer may not be sure which block was executed. However, +while with \texttt{if-else} blocks it can be determined which block was +executed by examining the branch conditions, \texttt{maybe} statements +require developers record which alternative was used if downstream code +depends on the decision. Alternatively, programmers may use a \texttt{maybe} +variable to select a policy and employ traditional \texttt{if-else} +statements to direct control flow based on the \texttt{maybe} variable. + While \texttt{maybe} is a powerful programming tool, it is important that it -be used sparingly. In the case where no dependencies exist between the +be used sparingly. In the case where dependencies exist between the alternatives expressed by separate \texttt{maybe} statements, each -\texttt{maybe} expands the overall configuration space exponentially and +\texttt{maybe} may expand the overall configuration space exponentially which makes the resulting process of determining the best alternative much more complicated. Compile-time analysis may be required to ensure that downstream optimization remains feasible. The most important guideline for when \textit{not} to use \texttt{maybe} usage is when a decision is not app-specific, and should instead be -made by a library or service. As an example, \texttt{maybe} should +refactored into a library or service. As an example, \texttt{maybe} should not be used to decide which networking interface to use to send a packet. To the degree that one app shares the same objectives as others---say, to minimize latency---a @@ -128,10 +119,8 @@ service should be performing adaptation on behalf of all apps using the merged network interfaces, possibly through the use of its own internal \texttt{maybe} statements. -\subsection{Other Approaches to Adaptation} - -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. +Finally, 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.