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

[Michael Wilde]

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