[Swift-commit] r2411 - text/hpdc09submission

noreply at svn.ci.uchicago.edu noreply at svn.ci.uchicago.edu
Fri Jan 9 06:09:35 CST 2009 

Author: benc
Date: 2009-01-09 06:09:34 -0600 (Fri, 09 Jan 2009)
New Revision: 2411

Modified:
   text/hpdc09submission/paper.latex
Log:
cross references from the introduction into meatier sections; rearrangement of variables / dataset typing intro. Remove table of operator and built in procedures/functions as unnecessarily verbose. Move library paragraph to future section

Modified: text/hpdc09submission/paper.latex
===================================================================
--- text/hpdc09submission/paper.latex	2009-01-09 11:06:15 UTC (rev 2410)
+++ text/hpdc09submission/paper.latex	2009-01-09 12:09:34 UTC (rev 2411)
@@ -95,8 +95,9 @@
 encapsulates the invocation of ``ordinary programs'' - technically, POSIX
 \emph{exec()} operations - in a manner that explicitly specifies the files
 and other arguments that are the inputs and outputs of each program
-invocation. This formal but simple specification of data inputs and
-outputs enables Swift to provide four critical features not provided
+invocation. This formal but simple model (elaborated on in section
+\ref{LanguageEnvironment})
+enables Swift to provide four critical features not provided
 by scripting languages like Perl, Python, or the various command-line shells:
 
 \begin{itemize}
@@ -117,35 +118,15 @@
 sections. [TODO: we will need to adjust between how much to specify
 here, and how much to state just before each construct is introduced.
 
-\emph{Dataset typing and mapping model}. Swift provides for the high level
-specification of collections of data and of how those collections should
-be processed by component programs. It provides a structured data-type
-model for representing collections of files and directories that are
-passed to Swift procedures, and a mapping model to convert between the
-physical representation of data on storage systems and the logical
-representation of data structures in the abstract Swift programming
-model.
-
-Swift itself does not specify how the physical data environment is
-implemented. This specification is instead left up to a set of
-mappers.
-
 \emph{Execution of atomic procedures}. Underlying this is an
 implementation to execute scripts on grid and other platforms,
 providing built-in site selection, data management and
 reliability. Swift scripts can be tested on a single local
-workstation. The same script can then be executed on a cluster, one o
+workstation. The same script can then be executed on a cluster, one or
 more grids of clusters, and on large scale parallel supercomputers
-such as the Sun Constellation (ref) or the IBM Blue Gene / P.
+such as the Sun Constellation (ref) or the IBM Blue Gene/P. More information
+about the implementation is found in section \ref{Execution}.
 
-Swift programs can also span environments: ...explain
-
-Swift is implemented by compiling to a Karajan program, which provides
-several benefits. A notable benefit visible to users is that of
-providers. This enbles the Swift execution model to be extended by
-adding new data providers and job execution providers. This is
-explained in more detail in section \ref{ExecutingSites}: Executing on a remote site.
-
 \emph{Minimalist nature of Swift}. As a scripting language, Swift is
 intentionally designed to be a sparse, minimal language. Its primary
 purpose is to coordinate, throttle, and sequence the execution of
@@ -163,29 +144,30 @@
 Swift programs typically contain very little code to manipulate data
 directly.
 
-\emph{Procedure composition and Libraries}. Swift programs are composed
-starting with ``atomic'' procedures, and then higher level procedures are
-composed as pipelines of sub-procedures. The basic structure of a
-composite procedure is a graph of calls to other procedures.
 
-\emph{Variables, single assignment and data flow}. Swift variables hold
-primitive values, or references to datasets, which are files or
-collections of files. Variables are ``single assignment'', which is the
-basis for Swift's model of procedure chaining (TODO execution ordering?). Procedures are executed
-when their input variables are all set. Procedures are chained by specifying
-that an output variable of one procedure is passed as the input
-variable to the second procedure.
 
-This dataflow model means that within a Swift program, procedures are
-executed when their data is available - which is not necessarily in
-source-code order.
 
-Swift procedure arguments are lists of such variables, and return lists
-of such variables. Swift does not yet have a notion of
-libraries. Swift programs execute as if all procedures called in the
-script are present in a single logical source file and are thus passed
-to the Swift virtual machine all at once.
+\emph{Variables, data flow and procedures}. Swift variables hold
+primitive values, or collections of files.
+Variables are \emph{single assignment}, which is the
+basis for Swift's model of procedure chaining.
+Procedures are executed when their input parameters are all defined (i.e.
+have a value).
+Procedures are chained by specifying that an output variable of one
+procedure is passed as the input variable to the second procedure. This 
+dataflow model means that within a script, procedures are not executed
+in source-code order; instead they are executed as input data becomes
+available.
 
+Variables are given a type, and when they contain collections of files,
+are associated with a \emph{mapper} which indicates how the layout of
+data files is associated with the logical representation in the Swift
+data model. See section \ref{LanguageTypes}.
+
+Swift programs are composed
+starting with \emph{atomic procedures} which execute component programs,
+and then higher level procedures are composed as pipelines of sub-procedures.
+
 \subsection{Rationale for creating Swift}
 
 \emph{TODO: This section needs much polishing/condensing.}
@@ -455,6 +437,10 @@
 declared with the \verb|app| keyword, as they invoke other SwiftScript
 procedures rather than a component program.
 
+The basic structure of a composite procedure is a graph of calls to
+other procedures. (TODO: does talking about call graphs make sense in
+the context of programming language-style descriptions?)
+
  \begin{verbatim}
  (file output) process (file input) {
    file intermediate;
@@ -491,6 +477,7 @@
 TODO: talk about anonymous mapping somewhere - a mappers section...
 
 \subsection{More about types}
+\label{LanguageTypes}
 
 Each variable and procedure parameter in SwiftScript is strongly typed.
 Types are used to structure data, to aid in debugging and program
@@ -578,66 +565,13 @@
 TODO mappings may be to URLs, not only to local filesystem files; and more
 explicit description of what mapping is.
 
-\subsection{Operators, built-in procedures, functions and mappers}
+\subsection{Swift mappers}
+Swift contains a number of built-in mappers. A representative sample
+of these is listed in table \ref{mappertable}.
 
-SwiftScript has a number of built in operators, procedures, functions
-are very briefly described in tables \ref{optable}, \ref{proctable}
-and \ref{mappertable}.
-
 \begin{table}[htb]
-\begin{tabular}{|c|p{2in}|}
-\hline
-+ - * & usual mathematical operations \\
-\hline
-== != > < & \\
->= <= & usual comparison operations \\
-\hline
-! \&\& || & usual boolean operations \\
-\hline
-/ & floating point division \\
-\hline
-\%/ \%\% & integer division and mod \\
-\hline
-( ) & parentheses \\
-\hline
-\end{tabular}
-\caption{SwiftScript operators}
-\label{optable}
-\end{table}
-
-%  ops:  @ [ ] .
-
-\begin{table}[htb]
 \begin{tabular}{|r|p{2in}|}
 \hline
-readData & \\
-readData2 & read data into a structure from a file \\
-\hline
-trace & output trace debugging information \\
-\hline
- at arg & returns a named commandline argument \\
-\hline
- at extractint & reads an integer from a file \\
-\hline
- at filename & \\
- at filenames & returns the filename(s) that are mapped to an expression \\
-\hline
- at regexp \\
-\hline
- at strcat \\
-\hline
- at strcut \\
-\hline
- at toint \\
-\hline
-\end{tabular}
-\caption{SwiftScript procedures and functions}
-\label{proctable}
-\end{table}
-
-\begin{table}[htb]
-\begin{tabular}{|r|p{2in}|}
-\hline
 \verb|single_file_mapper| & maps a single explicitly named file \\
 \hline
 \verb|filesys_mapper| & maps files matching a pattern into an array \\
@@ -651,6 +585,7 @@
 \end{table}
 
 \subsection{The execution environment for component programs}
+\label{LanguageEnvironment}
 
   A SwiftScript \verb|app| declaration describes how a component
 program is invoked. In order to ensure the correctness of the 
@@ -716,10 +651,13 @@
 section (change titles...)
 
 \section{Execution}
+\label{Execution}
+Swift is implemented by compiling to a Karajan program, which provides
+several benefits. A notable benefit visible to users is that of
+providers. This enbles the Swift execution model to be extended by
+adding new data providers and job execution providers. This is
+explained in more detail in section \ref{ExecutingSites}: Executing on a remote site.
 
-TODO could briefly describe the execution layer here? how much depth is
-interesting?
-
 \subsection{Executing on a remote site}
 \label{ExecutingSites}
 
@@ -1253,7 +1191,19 @@
 Could existing programs execute Swift calls through a library
 approach?  The answer to this is certainly ``yes''. (?)
 
+\subsection{Swift library / source code management}
 
+
+(TODO benc: unclear what is meant by this paragraph. it was originally in the
+introduction, but as it appears to talk about something which does not (yet?)
+exist, then it is probably better being absorbed into the future section)
+
+  Swift does not yet have a notion of libraries. Swift programs execute as
+if all procedures called in the script are present in a single logical
+source file and are thus passed to the Swift virtual machine all at once.
+
+
+
 \section{Implementation status}
 
   TODO: list how Swift can be downloaded here. describe development group?

More information about the Swift-commit mailing list