[RFC] Implementing ASSOCIATE

[Daniel Kraft]

Hi Janus,

thanks for your comments!

Janus Weil wrote:
>> Second, if a name is associated to a variable (i.e., some EXPR_VARIABLE in
>> the gfortran code), it may also be used in assignment-contexts and changes
>> the referenced variable (or array section, derived-type component or what
>> ever).  I think the best way to handle this situation is by keeping a
>> special "compile time" table of those names and replace each occurence with
>> a copy of the original gfc_expr when resolving the tree (or even when
>> parsing, at least directly in the front-end before code is generated).  This
>> should have the semantics we want and need for the standard (e.g., basically
>> that the associate-name has all the same attributes as the variable it
>> references).
> 
> I'm not sure if I understand your implementation plan correctly (and
> if I agree with it).
> 
> I think the easiest thing to do (and this is also what we do for
> SELECT TYPE) is to have a local variable for the associate name
> (inside of a hidden BLOCK), which is initialized according to the
> association statement and then can be used in arbitrary manner (no
> need to check for "write access").
> 
> Then one doesn't need any "compile time table", whatever you mean by
> that. The implementation could be the same for both cases, with
> additional checks for the first case.

But if the user actually changes that hidden variable, you also want to 
have the change reflected in what the variable is associated with.  So:

INTEGER :: x(5)

x = 0
ASSOCIATE (y => x(2))
   y = 42
END ASSOCIATE

! x should be (/ 0, 42, 0, 0, 0 /)

No?  I don't see how this is accomplied with what you suggest.  Except 
of course, if the hidden variable is always a pointer or you add a 
copy-back right at the end of the associate block.  Pointer is probably 
not possible here because then x would also need to be TARGET which it 
is not (and need not be, AFAIK); and copy-back is another possibility, 
where I'm not sure if we should rather do that.

Or would the current implementation also handle the situation above 
correctly (if applied to ASSOCIATE)?  If so, please clarify how :)

>> What do you think about this plan, did I miss some problems or anything?
>>  Janus, I believe that for SELECT TYPE, you already do the first item but
>> not the second -- is this correct?
> 
> Err, no. Actually it's the other way around. For SELECT TYPE we only
> do the second type up to now. When it comes to polymorphic
> expressions, the first type is pretty limited I would say. The only
> examples that come to my mind are functions with polymorphic return
> value and polymorphic operators (maybe there are more).

Ok I see, and this totally makes sense of course...

Yours,
Daniel

-- 
Done:  Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Kni-Mon-Pri