[Patch, Fortran] SELECT TYPE with associate-name

[Tobias Burnus]

On 10/07/2009 12:25 PM, Daniel Kraft wrote:
> I thought about ASSOCIATE a little before I decided to implement
> BLOCK, and my opinion is that ASSOCIATE is probably a little more
> complicated, unfortunatly.  If I understand it correctly, you also can
> give variables an associate-name and use it later to set the variable,
> rather than just reading some value.

I do no see any difference to SELECT TYPE. In both cases you have "name
=> expression". If the right-hand side expression is definable, one can
assign to it. If it is not definable, the standard requires that one
(the compiler) rejects that the "name" is used for assignments (or as
intent-out variable or ...).

Additionally, in both cases, one has to think about aliasing:
  associate ( a => b)
     a = 5
     b = 7
(or equivalently with SELECT TYPE when on operating on components of the
base type). If "b" is restricted pointer (e.g. an allocatable) then even
if "a" is not restricted, there is a problem with the alias analysis. I
am actually not sure that it always works properly. It could well be that

a%comp%i = 5  ! e.g. via default initialization
select type (c => a%comp)
 type is(t)
    c%i = 7
end select
print *, (a%comp%i

is mishandled since one modifies only "c" but that cannot modify
"a%comp" as "a" is restricted and thus a%comp%i is still 5.


Additionally, one has to be careful that:

a = 5
associate( a=>b)
  deallocate(b) ! or "deallocate(a)"
  b = 7 ! allocate on assignment
end associate
print *,a ! shall print 7

works. Currently, it does for CLASS as one creates a pointer to the
CLASS and thus operates on a$data which is the same for "a" and "b". For
associate and for CLASS(*) one needs to be more careful.

> So in this case I think you either need to add a copying-back at the
> end or do the association with pointers.
I think that's what happens with SELECT TYPE currently.

> My thoughts were to introduce a local variable just as you did for
> associating names to values (like function results or other
> calculations) but when the target is a EXPR_VARIABLE, copy the
> expression and substitute it directly at compile time for the
> associate-name;
That would be a possibility which makes the restricted vs.
non-restricted pointer and also the allocate issue easier. I think we
will need to do something like that.Regarding whether to do this now or
wait for next stage 1, I think we should in general wait as this is not
really a bugfix; on the other hand, for me it would also be ok to do it
quickly now, if others are also of this opinion.

> BTW, as I did BLOCK, I would also volunteer to work on ASSOCIATE (next
> stage 1) if you want to work on other stuff then and bugfixing now.
I would be great if you would work on ASSOCIATE and this part of SELECT
TYPE (also taking CLASS(*) conceptually into account).

Tobias