[RFC] Implementing ASSOCIATE

[Daniel Kraft]

Hi all,

as my first smaller project (before I'll have more time during the 
summer and holidays) I'd like to work on implementing the ASSOCIATE 
construct as well as finishing the SELECT TYPE construct.

My proposed implementation strategy is like this:

Basically, there are two cases that have to be distinguished:  For one, 
names may be associated with expressions, such as "x => 2 * COS (0.25 + 
Y)" -- in this case, the value is calculated at the beginning of the 
construct and x may be used within it to represent the result.  I think 
for this, we can internally translate the ASSOCIATE to a BLOCK construct 
and generate an assignment at the beginning to set it.

However, this value is (obviously) disallowed from being changed; thus I 
think we have to add a new symbol attribute that identifies the variable 
as such generated associate-name so that we can diagnose errors when the 
user tries to set it.

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).

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?  Is there anything related to 
your implementation or maybe special to SELECT_TYPE and polymorphism 
that I need to consider with the above plan?

I want to implement ASSOCIATE first and later extend the current SELECT 
TYPE support.  Maybe I'll split the patch if it becomes large into a 
parsing and implementation piece or rather only supporting the first 
type of association and later the second, but we'll see.

Yours,
daniel

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