[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