[Swift-commit] r3813 - text/parco10submission

[noreply at svn.ci.uchicago.edu]

Author: hategan
Date: 2010-12-21 15:13:02 -0600 (Tue, 21 Dec 2010)
New Revision: 3813

Modified:
   text/parco10submission/paper.tex
Log:
an alternate take on the swift rationale

Modified: text/parco10submission/paper.tex
===================================================================
--- text/parco10submission/paper.tex	2010-12-19 12:11:38 UTC (rev 3812)
+++ text/parco10submission/paper.tex	2010-12-21 21:13:02 UTC (rev 3813)
@@ -3,9 +3,13 @@
 
 \usepackage{graphicx}
 
-\usepackage{color}
+\usepackage{xcolor}
+\usepackage{framed}
 \newcommand{\katznote}[1]{ {\textcolor{cyan}   { ***Dan:   #1 }}}
 
+\definecolor{shadecolor}{RGB}{240,255,200}
+\newenvironment{msection}{\begin{shaded}}{\end{shaded}}
+
 \journal{Parallel Computing}
 \makeatletter
 \g at addto@macro\@verbatim\small
@@ -87,7 +91,6 @@
 
 \katznote{are swift tasks idempotent?  are swift scripts are deterministic (maybe?)  deadlock-free? (no)}
 
-
 Swift is a scripting language designed for composing ordinary
 application programs (serial or parallel) into distributed,
 parallelized applications for execution on grids and supercomputers
@@ -131,6 +134,93 @@
 
 \subsection*{Rationale}
 
+\begin{msection}
+The main goal of Swift is to allow the composition coarse grained
+processes. Such a composition will be termed \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
+same time maintaining data determinism. 
+
+The exact number of processing units available on such shared resources
+varies with time. In order to take advantage of as many processing units
+as possible during the execution of a Swift program, it is necessary to
+be flexible in the way the execution of individual processes is
+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
+referential transparency, and one may readily extend the concept to
+encompass arbitrary processes without difficulty.
+
+The referential transparency requirement suggests that an appropriate
+course of action in building a language allowing process composition is
+to define a correspondence between the familiar concept of a function
+and a process. We do so in Swift by representing input data and process
+parameters as function parameters and output data as return values,
+while processes are represented by functions.
+
+This duality allows the formal specification of process behavior. When
+writing as part of a program:
+\begin{verbatim}
+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
+fundamentally does: produce a rotated version of the original. 
+
+Indeed, there is no strict requirement in the specification of the Swift
+language dictating that functions be implemented as command-line
+applications. They can equally consist of library calls or functions
+written in Swift itself, as long as they are side-effect free. A soft
+restriction arises from the desire to distribute the execution of
+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.
+
+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
+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
+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
+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)
+readily accommodates Monte Carlo processes. However, further discussion
+is necessary if optimizations (such as memoization) are employed.
+Second, referential transparency and lack of side-effects are not
+equivalent concepts. For example, it is possible for a referentially
+transparent function to employ side-effects as part of its
+implementation. While this is not currently possible within Swift
+itself, it is also not readily obvious that such a feature would
+contradict the main goals of Swift, and therefore is not ruled out as a
+possible future development.
+
+
+\end{msection}
+
+
 The emergence of large-scale production computing infrastructure such
 as clusters, grids and high-performance computing (HPC), and the
 inherent complexity of programming on these systems, necessitates a