[Swift-devel] could we set the job sequence without a file dependency?

[Ian Foster]

interestingly, Mike's suggestion of compiling to dummy sequencing  
variables is how we implemented SEQ in PCN (I believe)

On Mar 24, 2009, at 12:23 PM, Michael Wilde wrote:

> I too think that it would be good to be able to say "sequential"  
> without explicitly wiring in the synchronization primitives. Since  
> we can do what we need in this regard for the moment, this is less  
> urgent but reasonable to discuss to put in the hopper for language  
> evolution dscussion.
>
> Towards that end, a few questions:
>
> - does Karajan already support the necessary constructs to easily  
> generate a seq{} block or proc?
>
> - if not, does it make sense to provide a seq construct that  
> essential compiles into the same as a user would generate doing this  
> manually today with externals? Somewhat of a syntactic sugaring  
> approach?
>
> > seq {
> >     A();
> >     B();
> > }
>
> "compiles" to:
>
> (ext1, r1) = A(v1);
> (ext2, r2) = B(v2,ext1);
>
> I am somewhat delighted with the externals, in the sense that we can  
> express what needs to be done for some real applications. But if the  
> simpler syntax is "low cost" to implement, its worth considering (in  
> my opinon) if it doesnt break things or open a can of messy worms.  
> But its low priority.
>
> I dont want to get too deep into this just yet; lets treat it as  
> food for language-evolution discussion.
>
> On 3/24/09 12:08 PM, Ian Foster wrote:
>> Only in a round-about way. Maybe that is ok, it is just less  
>> intuitive than say:
>> seq {
>>    A();
>>    B();
>> }
>> (IMHO)
>> Ian.
>> On Mar 24, 2009, at 12:02 PM, Ben Clifford wrote:
>>>
>>> you can express sequencing. that's what extern lets you do.
>>>
>>> On Tue, 24 Mar 2009, Ian Foster wrote:
>>>
>>>> These discussions are very reminiscent of PCN, where we had many  
>>>> of the same
>>>> issues.
>>>>
>>>> A reason then for wanting sequencing was for output.
>>>>
>>>> We introduced a sequential operator, which had the advantage that  
>>>> people could
>>>> say more directly what they meant.
>>>>
>>>>
>>>> On Mar 24, 2009, at 9:06 AM, Ben Clifford wrote:
>>>>
>>>>>
>>>>> On Tue, 24 Mar 2009, Zhao Zhang wrote:
>>>>>
>>>>>> Say, Job A is broadcasting common data shared for all jobs. And  
>>>>>> Job B only
>>>>>> needs to know that Job A is done, so he could read the common  
>>>>>> data.
>>>>>
>>>>> ok, so there is a data dependency.
>>>>>
>>>>> You can externals (like Mike has been using on the swift-user  
>>>>> list) to
>>>>> represent data dependencies like that.
>>>>>
>>>>> app (external commonData) A() {
>>>>> ...
>>>>> }
>>>>>
>>>>> app B(external commonData) {
>>>>> ...
>>>>> }
>>>>>
>>>>> external d = A();
>>>>> B(d);
>>>>>
>>>>> d represents your shared data set - by declaring it as  
>>>>> 'external' you say
>>>>> that Swift should do data dependency handling, but should not  
>>>>> attempt to
>>>>> manage the data itself.
>>>>>
>>>>> d is mapped to the data, but in your head, rather than in Swift.
>>>>>
>>>>> -- 
>>>>> _______________________________________________
>>>>> Swift-devel mailing list
>>>>> Swift-devel at ci.uchicago.edu <mailto:Swift-devel at ci.uchicago.edu>
>>>>> http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel
>>>>
>> ------------------------------------------------------------------------
>> _______________________________________________
>> Swift-devel mailing list
>> Swift-devel at ci.uchicago.edu
>> http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel