Re: F2003 Finalization -- progress and problems

[Daniel Kraft <d at domob dot eu>]

Tobias Burnus wrote:
> let's start with the simpler stuff.

Thanks Tobias for your first answers!

> Daniel Kraft wrote:
> > d) when a procedure is called that is not in a module (does not have an
> > interface?) its formal-argument list in the tree is NULL (as this
> > information is not known, I suppose).  How should we in this case
> > determine which arguments are INTENT(OUT) and need finalization before
> > the call?
> When the interface is implicit, one can regard the arguments as 
> INTENT(INOUT) [though there is a fine destinction between INTENT(INOUT) 
> and no INTENT with regards to definability]; in any case there is no 
> need to finalize the argument. Note a procedure has always an interface 
> in Fortran  - the distrinction is only between explicit and implicit.

Ok, so in this case I'll assume INTENT(INOUT) and don't finalize the 
arguments.

> > WRITE (*,*) x + foobar (x)
> >
> > Is this allowed?
> I forgot whether modifying the items in an I/O list is invalid or the 
> result is only implementation-dependent,  but FINALizing "x" here should 
> be OK.

I was more thinking about the expression "x + foobar (x)" in itself 
rather than the I/O; that's because foobar (x) changes the value of x 
and I wanted to know whether it was defined or not if the first x had 
the earlier or later value.

I came to this because at the moment I will finalize x because of giving 
it to INTENT(OUT) before the whole statement the function-call happens 
(this is rather easy without having to fiddle around breaking the 
statement down)--now I want to know if this is legal or if I have to 
finalize it only directly before the call.

> > What's about calling an ELEMENTAL-procedure with a INTENT(OUT) argument
> > on an array?  Should the array be finalized as a whole or each element
> > seperatelly before the call?
> I think if there is an array finalizing subroutine, I'd simply call it 
> otherwise, one could either first finalize all elements and call then 
> the elemental procedure, or one could finalize an element and then call 
> the elemental procedure with this element. The result should be the same 
> as "the values of the elements, if any, of the result are the same as 
> would have beenn obtained if the scalar function had been applied 
> separately, in any order, to the corresponding elements of each array 
> actual element." Note especially the "in any order".

I was unsure about whether to call the array-finalizer routine or the 
scalar one for each element.  As in theory they could be totally 
different and I think the standard should somehow define which one ought 
to be called.  But maybe this isn't the case and we "are free to 
choose"?  I'd find it more intuitive if we finalized the whole array as 
for the user an ELEMENTAL-procedure is just like one taking a whole 
array.  So try to finalize the array on a whole before the call and any 
scalarization of it.

> +    ! XXX: Scalars can be allocatable, too, can't they?
>
> In Fortran 95: No, in Fortran 2003: Yes. In gfortran: No. Most of the 
> time it does not make sense to allocate scalars, exceptions are 
> characters with "len=:" where it is useful. Analogously for derived 
> types with  LEN type  parameters.

Ok, so I'll leave this from the test.  Maybe I could add a TODO, but I 
think this test isn't really vital as this should work anyway.  I just 
wanted some distinction and different tests.

> +    TYPE(yes_t), ALLOCATABLE :: alloc_vector(:)
> +    ! alloc_vector is deallocated automatically here
> +    ! XXX: Or not?

BTW, I was a bit surprised when I first read about this nice feature of 
automatic deallocation (and automatic allocation the like)--Fortran 
isn't C++ :D

I saw the deallocation code in the dumped tree, but no finalization 
happening there at the moment...  So I'll have to track down where this 
deallocation is done and insert finalization code there, but shouldn't 
be too difficult.


Thanks so long,

Daniel

--
Done:     Bar-Sam-Val-Wiz, Dwa-Elf-Hum-Orc, Cha-Law, Fem-Mal
Underway: Ran-Gno-Neu-Fem
To go:    Arc-Cav-Hea-Kni-Mon-Pri-Rog-Tou