[Swift-commit] r3818 - text/parco10submission

[noreply at svn.ci.uchicago.edu]

Author: dsk
Date: 2010-12-22 09:02:23 -0600 (Wed, 22 Dec 2010)
New Revision: 3818

Modified:
   text/parco10submission/paper.tex
Log:
minor changes to new rationale section


Modified: text/parco10submission/paper.tex
===================================================================
--- text/parco10submission/paper.tex	2010-12-22 02:08:21 UTC (rev 3817)
+++ text/parco10submission/paper.tex	2010-12-22 15:02:23 UTC (rev 3818)
@@ -123,22 +123,18 @@
 component programs on grids and other parallel platforms, providing
 automated site selection, data management, and reliability.
 
-This paper goes into greater depth than prior
-publications~\cite{Swift_2007} in describing the Swift language, how
-its implementation handles large-scale and distributed execution
-environments, and its contribution to distributed and parallel computing.
-\katznote{Alternative: Swift has been described previously~\cite{Swift_2007} ;
+Swift has been described previously~\cite{Swift_2007};
 this paper goes into greater depth in describing the Swift language, how
 its implementation handles large-scale and distributed execution
-environments, and its contribution to distributed and parallel computing.}
+environments, and its contribution to distributed and parallel computing.
 
 \subsection*{Rationale}
 
 \begin{msection}
 The main goal of Swift is to allow the composition of coarse grained
-processes. Such a composition will be termed \emph{Swift program}. A
+processes. Such a composition is termed a \emph{Swift program}. A
 secondary goal is to parallelize and manage the execution of a Swift
-program on shared collections of resources (i.e. Grids), while at the
+program on shared collections of resources (e.g., grids), while at the
 same time maintaining data determinism. 
 
 The exact number of processing units available on such shared resources
@@ -148,7 +144,7 @@
 parallelized. Having the results be independent of the way the processes
 are parallelized implies that the processes must, for the same input,
 produce the same output, irrespective of the time, order or location in
-which they are "executed". This characteristic is reminiscent of
+which they are ``executed''. This characteristic is reminiscent of
 referential transparency, and one may readily extend the concept to
 encompass arbitrary processes without difficulty.
 
@@ -165,9 +161,9 @@
 rotatedImage = rotate(image, angle);
 \end{verbatim}
 the semantics are defined in terms of the specification of the function
-"rotate" when supplied with specific parameter types, and whether the
-implementation can be described as a "library call" or a "program
-invocation" changes nothing with respect to what the piece of program
+``rotate'' when supplied with specific parameter types, and whether the
+implementation can be described as a ``library call'' or a ``program
+invocation'' changes nothing with respect to what the piece of program
 fundamentally does: produce a rotated version of the original. 
 
 Indeed, there is no strict requirement in the specification of the Swift
@@ -178,32 +174,32 @@
 functions across a collection of heterogeneous resources, which, with
 the advent of projects such as TeraGrid, suggests an implementation in
 which functions are applications readily executable on them through the
-careful employment of Grid middleware.
+careful employment of grid middleware.
 
 Having established the constraint that Swift functions must in general
 be referentially transparent, and in order to preserve referential
 transparency at different levels of abstractions within the language, it
 follows that the appropriate form for the Swift language is functional.
-We choose to make the Swift language purely functional (i.e. disallow
-side-effects in the language) in order to prevent the difficulties that
-arise from having to track side-effects to ensure determinism in complex
+We choose to make the Swift language purely functional (i.e., we disallow
+side effects in the language) in order to prevent the difficulties that
+arise from having to track side effects to ensure determinism in complex
 concurrency scenarios.
 
 It is already known that functional programming allows consistent
 implementations of evaluation strategies different from the widespread
 eager evaluation, a fact readily apparent in lazily evaluated languages
 such as Haskell and Miranda. In order to achieve automatic
-parallelization in Swift, instead of thunking (i.e. suspended
-computations) which yields lazy evaluation, we employ futures, which
-results in eager parallelism. In this process, we trade the ability to
+parallelization in Swift, instead of using thunks (i.e., suspended
+computations), which yield lazy evaluation, we employ futures, which
+result in eager parallelism. In this process, we trade the ability to
 efficiently deal with infinite structures for the ability to minimize
 computation time. It must, however, be noted that a middle ground
 exists: lazy futures (futures whose computation is delayed until a value
 is first needed).
 
 A number of issues may be noted at this point. First, there exist a
-certain class of processes which may break referential transparency,
-while still producing "valid" results. An example would be Monte Carlo
+certain class of processes that may break referential transparency,
+while still producing ``valid'' results. An example would be Monte Carlo
 processes. Under the assumption that eager evaluation of compositions of
 Monte Carlo processes also produces valid results, an eager Swift
 implementation (which is the case with the current implementation)