[Swift-commit] r3832 - text/parco10submission

[noreply at svn.ci.uchicago.edu]

Author: hategan
Date: 2010-12-27 18:17:14 -0600 (Mon, 27 Dec 2010)
New Revision: 3832

Modified:
   text/parco10submission/paper.tex
Log:
alternate language section

Modified: text/parco10submission/paper.tex
===================================================================
--- text/parco10submission/paper.tex	2010-12-28 00:16:36 UTC (rev 3831)
+++ text/parco10submission/paper.tex	2010-12-28 00:17:14 UTC (rev 3832)
@@ -201,6 +201,10 @@
 exists: lazy futures (futures whose computation is delayed until a value
 is first needed).
 
+A useful side effect of using a futures based evaluation strategy is that
+automatic parallelization is achieved without the need to resort to
+dependency analysis, which is known to be a non-trivial engineering task.
+
 A number of issues may be noted at this point. First, there exist a
 certain class of processes that may break referential transparency,
 while still producing ``valid'' results. An example would be Monte Carlo
@@ -268,6 +272,112 @@
 \section{The Swift language}
 \label{Language}
 
+\begin{msection}
+
+\subsection{Language facilities}
+
+At the core of the Swift language are function definitions, of which 
+two types exist:
+\begin{description}
+\item[External functions] (also called ``atomic'') are functions whose
+implementations are not written in Swift. Currently external functions
+are implemented as command-line applications.
+\item[Internal functions] (also called ``compound'') are functions 
+implemented in Swift.
+\end{description}
+
+In addition to functions, the Swift language provides conditional
+execution through the \emph{if} and \emph{switch} statements as well as
+a \emph{foreach} construct used for iterating over arrays of data.
+{\color{red} Note: I'm skipping \emph{iterate} on purpose. We should
+deprecate it since it's hard to understand and everything that can be
+done with it can also be done with \emph{foreach}}
+
+The \emph{if} and \emph{switch} statements are rather standard, but 
+\emph{foreach} merits more discussion. Similar to \emph{Go}
+(\ref{GOLANG}) and\emph{Python}, its control ``variables'' can be both
+an index and a value. The syntax is as follows:
+
+\begin{verbatim}
+foreach v[, k] in array {
+  ...
+}
+\end{verbatim}
+
+This is necessary because Swift does not allow the use of mutable state 
+(i.e. variables are single-assignment), therefore one would not be able
+to write statements such as \verb|i = i + 1|.
+
+We provide a few examples of some standard functions seen in functional
+languages and the corresponding Swift implementation using
+\emph{foreach}:
+
+\begin{description}
+\item[b = map(f, a)]
+\begin{verbatim}
+
+foreach v, k in a {
+  b[k] = f(v);
+}
+\end{verbatim}
+
+\item[c = zipWith(f, a, b)]
+\begin{verbatim}
+
+  foreach v, k in a {
+    c[k] = f(v, b[k]);
+  }
+\end{verbatim}
+
+\item[r = foldr(f, v0, a)]
+\begin{verbatim}
+
+  r[0] = v0;
+  foreach v, k in a {
+    r[k + 1] = f(r[k], v);
+  }
+\end{verbatim}
+\end{description}
+
+\subsection{Data model}
+
+Swift provides two basic classes of data types:
+\begin{description}
+\item[Primitive types] (e.g. \emph{integer}, \emph{string}) are types
+provided by the Swift runtime. Standard operators are defined for
+primitive types, such as addition, multiplication, concatenation, etc.
+
+\item[Mapped types] are types of data for which some external 
+implementation exists. Swift provides a mechanism to describe
+isomorphisms between instances of Swift data structures and subsets in
+the  external implementation. This mechanism is called ``mapping''  and
+specific instances of isomorphisms are called ``mappers''. Currently the
+only external implementation is a POSIX-like filesystem. However  the
+``external'' data type can be used to accommodate any external data that
+Swift cannot and should not directly handle. Swift mapped types can be
+seen as generalizations of reference types in traditional languages in
+that reference types are language representations of data stored in
+internal memory, in contrast with primitive (value) types for which no
+explicit storage is generally specified.
+\end{description}
+
+
+There is no syntactic distinction between primitive types and reference
+types. In addition, the semantic differences between the two classes of
+types is kept to a minimum.
+
+Data can be organized in so called ``composite types''. Swift provides
+facilities to aggregate data into \emph{arrays} and \emph{structures}.
+This can be done recursively in that arrays of arrays, structures
+containing structures,  arrays of structures as well as structures
+containing arrays are possible. Any types that have no internal
+structure  (i.e. non-composite types) are called ``atomic types''.
+
+Atomic mapped types do not specify any information about the structure of
+the data. It is up to the user to assign a ``proper'' type to external
+data. Consequently Swift must and does implement nominal type equivalence.
+\end{msection}
+
 The Swift programming model is data-oriented: it encapsulates the
 invocation of ``ordinary programs''---technically, POSIX {\tt exec()}
 operations---in a manner that explicitly specifies the files and other
@@ -315,6 +425,7 @@
 
 \subsection{Language basics}
 
+
 A Swift script describes data, application components, invocations
 of applications components, and the inter-relations (data flow)
 between those invocations, using a C-like syntax.