(j3.2006) Finalization ordering question

Malcolm Cohen malcolm
Mon Oct 22 06:11:02 EDT 2007

I'm not really following this, but anyway...

Michael opined:
>     The entity X(3) is an array.  Therefore it doesn't have a parent
> 	component, although its type does.  Right?

Wrong.  The parent component is X%T.

> 	Structures (which are scalars) have components, and
> 	derived types have components, but arrays only have elements.

Wrong.  Array%Scalar is a well-recognised idiom since F90 (there are even
examples in the standard).

> In sum:  I don't think the standard even spells out what to do
> for Bill's case, so we need an interp.

There is only a "need" for an interp if you want to change what it says...

> Kurt's paper 99-108r1 in meeting 148

Is, sorry to say, irrelevant since we scrapped that approach and started
 from scratch.  These things are not exactly trivial to get right, and there
were many problems with the original approach with its hideous "pseudo
elemental" strategy.

Anyway, although the F2003 ordering requirements differ from 99-108r1,
they are certainly a lot smaller - most of it is in processor-dependent

Bill originally said:
> 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 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 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)
   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.

You are right about it requiring all the FE components to be finalised
before any of the FT ones.  I don't recall offhand all the detailed  
made in the design process, but I do recall that we (mostly) wanted to
minimise the ordering requirements.  Requiring the parent component
finalisation to follow the new components is the main (only?) reason
for step 3 to follow step 2 (so that those final subroutines can
still depend on the contents of the parent component).  Maybe there
was some argument about wanting them to be able to depend on the contents
of the parent components of the rest of the entity - that's not
completely unimaginable (it's less far-fetched than some of the suggestions
I heard at the time!).

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.

> The user can specify different final routines for scalar and eachrank of  
> array objects. As far as I can tell, said routines can docompletely  
> different things for each rank.

Right, and this is completely unlike how user generics work
everywhere else.

> This provides for lots ofshot-in-the-foot opportunities, and in the  
> hands of a bad programmercould lead to almost incomprehensible code.

Right, that's so completely unlike things like, say, the GOTO statement.
What can we have been thinking.

As for Aleks "finalizers are not like destructors in the same way that
constructors are not like constructors", I can only say that  
C++ destructors
were not the first invention of the concept, various languages have had
various kind-of-similar-but-different-in-detail features, and obviously
finalizers are in fact addressing the same kind of problem that destructors
are addressing, and I myself would never say they were not.  Obviously,
they *WERE* added to the language to add "destructors", but Fortran is not
C++ and so the details are naturally somewhat different, not to mention
that our design decisions were not motivated by the same goals that the
C++ ones were.

BTW, on the rank issue, IMPURE ELEMENTALs are probably the right
solution for the sensible user (or even PURE ones if they can do the job,
which sadly enough is not usually the case for finalizers).

Malcolm Cohen, Nihon Numerical Algorithms Group KK, Tokyo, Japan.

More information about the J3 mailing list