Re: [RFC] Implementing ASSOCIATE

[Daniel Kraft <d at domob dot eu>]

Hi Mikael,

Mikael Morin wrote:
> On 08.05.2010 16:32, Daniel Kraft wrote:
> > 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;
> The value is disallowed to being _assigned to_. However, it can change 
> (I think) if Y changes in your previous example. Otherwise, I don't see 
> the point compared to a block construct with a temporary variable.

I do think this is only the case when the name is associated with a 
variable; there, I agree, but this is not what I was talking about.

The standard says that one has to evaluate the expressions at the 
beginning of the block, so I don't think that the value should change 
when Y changes.  Should 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).
> As a start, one could use a naive implementation which stores the TREE 
> expression in the associate_symbol->backend_decl so that a reference to 
> the associate_symbol will just paste the expression. This way, there is 
> no need to distinguish between variable and expression.
> One can add later optimizations, with dependency analysis, etc.

This is what I'm proposing to do, although not with the TREE but rather 
replace the names earlier in the compilation process by the gfc_expr's. 
 But the idea is exactly that.

Thanks,
Daniel

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