(j3.2006) Finalization ordering question

[Bill Long]

Malcolm Cohen wrote:
> I'm not really following this, but anyway...
>
>
>   
...

> Array%Scalar is a well-recognised idiom since F90 (there are even
> examples in the standard).
>
>
> Bill originally said:
>   
>> 4.5.6.2 seems to say the finalizations has to be done in this order:
>>
>> Step 2:  x(1)%fe,  x(2)%fe, x(3)%fe
>> Step 3:  x(1)%ft,  x(2)%ft,  x(3)%ft
>>     
>
> There is nothing in 4.5.6.2 about array element ordering, so I think this
> is clearly (maybe obviously) processor-dependent.  In fact if there are two
> components that have final subroutines (say FE and FE2), the wording in
> 4.5.6.2 allows Step 2 to be done in the order
>    FE of x(1), x(2), x(3) then FE2 of x(1), x(2), x(3)
> or
>    FE of x(1), FE2 of x(1), FE of x(3), FE2 of x(2), FE of x(2), FE2 of x(3)
> etc.  Admittedly that part of the wording is less clear, but I don't see
> an ordering requirement there.  As to whether it is better to interleave
> the procedures or the array elements, I'd say it depends.
>   

Right.  I meant the ordering only in the vertical direction (Step 2 
before Step 3).  However,  I'm not yet completely clear on the intention 
of the requirement in Step 3 that "the parent component is finalized".  
In this example, is the parent component finalized by a single call to 
the rank-1 final routine for type ft, with argument x(:)%ft, or is it 
finalized by three calls to the scalar final routine for type ft?  Step 
2 explicitly lays out when arrays are chopped into elements to be 
finalized separately, but Step 3 does not.

> Personally, I'd probably lean towards having the order processor-dependent:
> sometimes depth-first is best, sometimes breadth-first.  But that might be
> inconvenient for some users... on balance I'd rather not go back into the
> finalization swamp sifting through the various conflicting options and
> opinions to reexamine our choice of what we thought was the best way out
> at the time.
>
>   

Processor-dependent sounds nice to me, but only if I'm sure it is not 
ambiguous.  Since final routines for different ranks can have different 
effects, it's dicey to be too processor-dependent.

Cheers,
Bill



-- 
Bill Long                                   longb at cray.com
Fortran Technical Support    &              voice: 651-605-9024
Bioinformatics Software Development         fax:   651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120