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

[Bill Long]

Van Snyder wrote:

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


> The second choice will result in a feature request for a "these things
> don't overlap" declaration that would have effect in the construct or
> scope in which it appears.  It therefore couldn't tell the compiler that
> you know the values of i..n are such that there's no overlap in
> x(i:j:k)=x(l:m:n).
> 
> An alternative is an execution construct that only allows assignment
> statements in its body and says "there is no overlap in any of the
> contained assignments."

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.

Malcolm's suggestion of wrapping the assignment in a procedure also 
works.  If the procedure in an internal procedure, or in the same 
module, it will very likely get inlined and the overhead avoided.

Cheers,
Bill


> 
> I think it would be simpler to add the restrictions than to invent a new
> declaration or construct (especially since I've already drafted the
> interp paper).
> 

-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101