Re: [Patch, Fortran] PR fortran/38936: ASSOCIATE for derived-types and RFC

[Mikael Morin <mikael dot morin at sfr dot fr>]

Hello,

On Sunday 10 October 2010 13:36:56 Daniel Kraft wrote:
> Hi all,
> 
> the attached (simple...) patch helps with ASSOCIATE to derived-types.
> Namely, it allows to access components of associate-names with
> derived-type targets in certain cases.  I hope that this covers a lot
> (or most) of the real-world useful cases, but unfortunately it does not
> do so for all possibilities (see the test-case change and the XFAIL'ed
> new test for what it does and when it fails).
> 
> The problem is that in order to parse component references, we have to
> know a symbol's typespec (the corresponding derived-type) during parse
> time, but sometimes it is only evaluated during resolution what type the
> associate-target has.  I do not see a good way to implement this
> fully...  Two possible approaches come to mind:
> 
> * Somehow "combine" parsing and resolution such that for instance
> certain stuff that is finished parsing can already be resolved (like the
> definitions in the main program in associate_9 and the assocoiate-target
> expressions) while before other parts of a compilation-unit are parsed
> (in this case, the body of the ASSOCIATE).  This sounds very intrusive,
> though, and we should probably discuss this in detail before trying
> anything like it.  Or can we try to resolve just the few
> associate-target expressions (gfc_resolve_expr) even though the "real"
> resolution is done later?  But I guess we have to resolve things like
> the called function symbols, interfaces, ... to make this work in the
> general case.
I doubt this can work in the general case. Contained functions for example are 
going to be a problem as they can be used before they are defined. 

> 
> * Adapt the parsing of component-references such that maybe first only
> names as strings are parsed and accepted in any case, and they are
> mapped to actual components and all that checked during resolution.
> This sounds like the better of those two approaches to me, although it
> is still quite intrusive. 
I agree.

> And maybe this introduces some ambiguities in
> parsing, when we no longer use the information whether something is a
> derived-type or not?  (But off-hand, I do not see any such case right now.)
Well, I don't know; the code paths would be probably very different indeed.
Anyway, the parse time checks would have to be moved at resolution time, so 
the error reporting should not change that much from a user point of view.
As a general comment, I would say that for statements that are syntactically 
correct, but violate some constraints of the standard, we should emit an 
error, but not reject the statement as a whole. 
So, hem, back to your concern, hem, hem, well, hem, you'll see...

Mikael