[Swift-devel] strange behavior evaluating function call as trace arg

Mihael Hategan hategan at mcs.anl.gov
Thu Feb 5 11:46:34 CST 2009


On Thu, 2009-02-05 at 11:34 -0600, Michael Wilde wrote:
> OK, thanks, that helps me get closer, but Im not quite there yet.
> 
> The "automatic parallelization scheme" (i.e. the swift dataflow model) 
> works by chaining together lvalues, correct? In other words, it is the 
> setting of lvalues that enables a statement waiting on a variable to get 
> a value to execute. Is that correct?

Somewhat. It's is the existence of the lvalue that allows a consumer and
a producer to synchronize on the same thing.

> 
> Conceptually, one could view the dataflow model as existing solely in 
> the memory of the swift interpreter.  The creation of files is in some 
> sense a side effect of executing app procedures, and the creation of 
> files within an app() and the consequent execution of assignment 
> operations then results in lvalues being set, which enables execution of 
> any statement waiting on an lvalue to proceed. The assignment operations 
>   can be explicit (lvalue=value) or implicit (procedure return).

Yes.

> 
> To fully understand this, you need to go further into the details of 
> mapping, scoping, procedure activation/completion, array closing, and 
> single assignment.
> 
> So to take a few steps in that direction:
> 
> Question: are the following tuples the correct abstract representations 
> of lvalues and dshandles?

There is no "lvalue" distinct from "handle". The term was used by Ben to
refer to what looks like lvalues in the Swift scripts.

> 
> lvalue: type, *handle, state (set/unset) - same as handle==null?
> handle: type, value(if simple type), mapping

In the light of my sayings above:

handle: type, state, who_is_waiting_on_this, value?, mapping?

> 
> Question: how are arrays and structures represented in this model?

Structs are handles with fields, which are also handles. Arrays are
structs with dynamic fields (i.e. you can add fields/elements at
run-time).

> 
> Getting this into writing in a concise and correct form would be useful 
> for gaining a full understanding of Swift and also help in the language 
> paper.

It's useful as far as there is usefulness in people besides us
understanding how Swift works in detail at the expense of our time spent
writing the document.

> 
> Is it reasonable to put this into latex form and jointly edit until 
> we're satisfied with it?
> 
> If so, I will do that.
> 
> It could go into a version of the language paper that we post on the 
> site, while we submit a condensed version to a conference.
> 





More information about the Swift-devel mailing list