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

[Michael Wilde]

Thanks.

But regarding:

 >> 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.

...my intent is not to probe the internals but rather to understand how 
to *use* the language. Its not how swift works, but how to work with 
swift. I use it quite a bit and yet I'm continually discovering new 
things about it, and finding that some of my understandings were incorrect.

Thus I find it increasingly important to pin down the language 
specification in a form that lets users understand it thoroughly. Its 
not that complex, yet it has many subtleties and surprises, due both to 
parallelism and to the handling of external data.

Such a spec is also helpful in discussing changes and enhancements.

I think that the user guide, or some doc hanging off of it, is the place 
to capture this.


On 2/5/09 11:46 AM, Mihael Hategan wrote:
> 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.
>>
> 
>