Gfortran internal tree structure

[Daniel Kraft]

Paul Richard Thomas wrote:
> Daniel,
> 
> 
>>  What do you think about writing a (maybe just quite summarizing)
>> documentation about how gfc_code statements and gfc_expr expressions have to
>> be structured for IF, DO, things like "a+5" or "ALLOCATED(arr)" and whatever
>> comes to mind?  Or is there already such documentation and I missed it?
> 
> Don't think, just do!  yes, yes!

I've had a quick look at the current gfc-internals.texi now, and I think 
I should at least be able to enhance the gfc_code-section a bit (with 
details about this block-chaining); the current explanation does not 
make me understand anything...  This will hopefully make me understand 
it myself better :)  BTW, there's mentioned in a comment the possibility 
to include an image; how should that be done, are there any 
preferences/requirements on the format?  PNG, SVG, MetaPost (or what 
it's called)?  Not that I promise I can come up with something useful...

Another thing would be to create a gfc_expr structure next to the 
gfc_code one; I think those two should be the most important ones, but 
maybe also gfc_symbol might be of interest?  (Variables, derived-types, 
procedures are all symbols, right?)

Ok, now the disclaimer:  I can't promise anything...  And of course, 
there'll surely be lots of mistakes if I finally come up with a 
documentation-patch here, as I'm probably not aware of many things myself :D

>> If you want and I find time, I volunteer to start this in parallel to my
>> coding; but I think for that I need at least a good reviewer as I'm not
>> myself a guru on this topic :)  Additionally, if you think that's a good
>> idea, I could write builder-functions (maybe in a new code file
>> build-tree.c); for instance, given a code-block and a condition, build a
>> complete (resolved?) IF-gfc_code block; and similar for other constructs and
>> expressions (build a less-than expression given two operands or a
>> function-call given the list of actual argument expressions and the
>> symbl/symtree/name.  These could serve both as a secondary documentation on
>> how such an expression really looks like and be used to combine this logic
>> where it's used in the code (during parsing and at places like my
>> finalization routines during resolution).
> 
> This is done, of course, in the parser.  Whether it would be
> worthwhile to extract builder functions from the parser, both for
> maintainability and clarity, I do not know.  This is effictively done
> in array.c and arith.c.

I just thought that this could help, too, as if such methods were 
available one would not even need to know the exact format of the 
internal structures for doing things like I'm trying to do for 
finalization (generating code during, eg., resolution).  And that would 
make it easier to change the tree structure should that be neccessary 
without having to modify all those places were code is generated; but 
maybe at the moment I'm the only one...

> Incidentally, dump-parse-tree.c could do with updating and, I have no
> doubt, could always stand some improvement in the format.

I'll have a closer look at this file during working on the 
documentation, and if I have some ideas, I'll work it out.  Just one 
thing:  How can I even use those dump-functions?  I've already wanted to 
do that some times but not found out...

Daniel

-- 
Done:     Bar-Sam-Val-Wiz, Dwa-Elf-Hum-Orc, Cha-Law, Fem-Mal
Underway: Ran-Gno-Neu-Fem
To go:    Arc-Cav-Hea-Kni-Mon-Pri-Rog-Tou