(j3.2006) (SC22WG5.4160) Question about our design for associate names

Jim Xia jimxia
Fri Feb 5 10:46:48 EST 2010


> > It would be useful if I could get the "no overlap" semantics with an
> > associate construct, something like
> > 
> >   associate ( a => newField ( :, :, &
> >             &                 1+lowerLon : lowerLon+grid%noLons, &
> >             &                 1+lowerLst : lowerLst+grid%noLsts, &
> >             &                 :, : ), &
> >             & b => grid%field )
> >     a = b
> >   end associate
> > 
> > which of course I can write but it doesn't help anything because we
> > didn't apply the argument restrictions to associate names.
> > 
> > Do we want to
> > 
> > (1) add the restrictions to associate names
> >     (a) by way of an interp against 2003,
> >     (b) in 2008 and announce an incompatible change, or
> >     (c) in 2013 and announce an incompatible change, or
> > (2) not add the restrictions?
> > 
> 
> I would certainly vote for (2).  It has two major advantages:  It does 
> not change the current concept that associate constructs are just a 
> mechanism for creating aliases to simplify expressions, and, more 
> important, it would not suddenly invalidate existing codes.


Yes, I'll vote for (2) too.  From the text in the standard describing the 
construct, I can not deduce a conclusion that associate-name and selector 
pair in an ASSOCIATE construct should behavior similarly to actual-arg vs. 
dummy-arg as if in a function call.



> Why not use DO CONCURRENT?   The way people handled the original problem 

>   before was to put an 'ivdep' or 'concurrent' directive in front of the 

> array assignment as a way to tell the compiler there would be no 
> cross-iteration dependencies if the assignment was written out as a loop 

> nest (and hence no temp needed).  DO CONCURRENT does just that.  Pretty 
> close to the same amount of typing and a lot more clear as to what the 
> programmer intends.


Why not FORALL?  I know this suggestion may make me unpopular here.  But 
there is no compiler supports DO CONCURRENT yet, and there is no evidence 
at this point that DO CONCURRENT construct is anything better than FORALL. 
 I hope I'm wrong here though :-)



Cheers,


Jim Xia

XL Fortran Compiler Test
IBM Toronto Lab at 8200 Warden Ave, Markham, On, L6G 1C7
Phone (905) 413-3444  Tie-line 313-3444
email: jimxia at ca.ibm.com
D2/YF7/8200 /MKM

http://www.ibm.com/software/awdtools/fortran/xlfortran
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://j3-fortran.org/pipermail/j3/attachments/20100205/a42490c7/attachment.htm>



More information about the J3 mailing list