[Swift-commit] r3858 - text/parco10submission

[noreply at svn.ci.uchicago.edu]

Author: hategan
Date: 2011-01-05 15:39:39 -0600 (Wed, 05 Jan 2011)
New Revision: 3858

Modified:
   text/parco10submission/paper.tex
Log:
added some comments

Modified: text/parco10submission/paper.tex
===================================================================
--- text/parco10submission/paper.tex	2011-01-05 20:52:24 UTC (rev 3857)
+++ text/parco10submission/paper.tex	2011-01-05 21:39:39 UTC (rev 3858)
@@ -150,6 +150,10 @@
 
 As a language, Swift is simpler than most scripting languages because it does not replicate the capabilities that existing scripting languages like Perl, Python, and shells do very well, but instead makes it easy to call such scripts as small applications.
 % say: it has fewer statements, limited data types and a compact library of useful support primitives. It can be extended using built-in functions coded in Java, and by mappers coded as Java built-ins or as external scripts. These functions execute in parallel as part of expression evaluation in the same mapper as externally called application programs or scripts do.
+% Mihael thinks that we should not claim that Swift is "simpler". The language is as complete as a language can
+% be and the monentary lack of libraries is independent of the language. Most functional languages are simpler
+% than Swift.
+
 Swift can execute scripts that perform tens of thousands of program
 invocations on highly parallel resources, and handle the unreliable
 and dynamic aspects of wide-area distributed resources. Such issues are handled by Swift's runtime system, and are not manifest in the user's scripts.
@@ -163,6 +167,14 @@
 %keep: discuss kthread/function duality; dont confuse with the parameter issue?
 Swift enables users to specify process composition by representing processes as functions, where input data files and process parameters become function parameters and output data files become function return values. %\katznote{these are really Karajan threads - forward link to that?  - what do we call these in this paper?} A Swift script is a graph of function calls - each function call ... see section~\ref{Execution}.
 %
+% Mihael thinks that the graph of function calls is not quite appropriate since this may
+% project an overly simplified view. Swift allows
+% this graph to be built dynamically. For that matter, any parallel program will end up 
+% having a trace that can be represented as a graph. And any purely functional program
+% will have a graph representing dependencies (and again, that graph may be a non-trivial
+% thing built at run-time). It so happens that, using futures, we make the dependency
+% graph also be the trace of the execution graph.
+%
 Swift also
 provides a high level representation of collections of data (used as
 function inputs and outputs) and a
@@ -188,6 +200,12 @@
 automatic parallelization is achieved without the need for
 dependency analysis, which would significantly complicate the Swift implementation.
 
+% Mihael thinks it's more powerful to say that dependency analysis
+% is a complex issue for any non-functional language. It is not that
+% some swift constraints make dependency analysis complex, but 
+% the very idea of dependency analysis when allowing side-effects
+% is complex.
+
 We believe that the missing feature in current scripting languages is
 sufficient specification and encapsulation of inputs to, and outputs
 from, a given application, such that an execution environment could
@@ -232,6 +250,9 @@
 
 %keep: how best to state process/function duality?  Each invocation of a function is a process; all functions run in parallel; foreach loops are unfolded and run in parallel; essentially the entire program is unfolded. (Note: iterate stops this behavior and is thus useful; address scalability issues of this and future graph partitioning; how throttling keeps this manageable.
 
+% re iterate. foreach can also stop this behavior if there are inter-iteration dependencies
+% 
+
 %This duality allows the formal specification of process behavior. In the following Swift statement, the semantics are defined in terms of the specification of the function
 %``rotate'' when supplied with specific parameter types:
 %\begin{verbatim}
@@ -257,6 +278,9 @@
 %careful employment of grid middleware.
 
 %decide: is referential transparency relevant?
+
+% Referential transparency is THE relevant thing! The other things follow from it.
+
 %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
@@ -268,6 +292,14 @@
 
 %discuss: is lazy vs eager relevant? What does it really mean to swift?
 
+% in procedural programming you can only do eager evaluation. The minute
+% you eliminate side-effects, generalized lazy, future and lazy-future
+% strategies become immediately possible. From a theoretical standpoint,
+% in order to validate the swift idea, we only need to point out that
+% we can see app invocations as pure function invocations and then
+% ride on the functional train to get to automatic parallelization
+% via futures.
+
 % consider: In this process, we trade the ability to efficiently deal with infinite structures for the ability to minimize computation time. I think this pertains to the "unroll everything" strategy.
 
 \hide{A number of issues may be noted at this point. First, there exist a