Re: [RFC] type safe trees

[Neil Booth <neil at daikokuya dot co dot uk>]

Nathan Sidwell wrote:-

> In this case the KLASS of such an expression node would be 'e'. To extend 
> it,
> you'd do something like,
> 	#ifndef GTY
> 	class dyadic_expr ('2'): expr
> 	{
> 	  expr_t ops[2];
> 	};
> 	#else
> 	#include "dyadic_expr_t.h"
> 	#endif
> and that'd declare a new structure and acessor macro for the ops array. It
> also overrides the static klass value with '2'.  We'll also allocate a new
> code for this structure, so we can recognise it in the class hierarchy.
> 
> To define an actual PLUS_EXPR node, we do not need to define a new 
> structure,
> but map a new tree code onto an existing structure.  Here's the syntax for 
> that
> 	#ifndef GTY
> 	class plus_expr = dyadic_expr;
> 	#else
> 	#include "plus_expr_t.h"
> 	#endif
> and to override the klass value, you'd say
> 	class gt_expr ('<') = dyadic_expr;
> 
> This system will allow language frontends to declare new tree nodes which
> are first-class citizens.

I think this is really getting unnecessarily messy, and your last
sentence reveals what is IMO the real issue.  That we're trying to
design a front-end representation for all front ends.  The semantics
of trees are weakly defined at present and cause a lot of problems.
As language support of GCC increases, and people like Joseph want to
get ever more particular about the types of diagnostics that a given
front end emits, this is going to become increasingly unmaintainable.

We really need front-end specific data structures, lowered to a common
representation (I suspect gimple).  It would even solve the current
Kenner thread, though he may disagree.  Leave front ends to mind
their own business; then if I fix things in C I don't have to worry
about breaking something in Ada about which I have absolutely no clue.

Of course, it's a massive amount of work to do this, given how trees
are now grossly intertwined with GC and PCH.  However, I think we're
doing GC and PCH wrong too, and it's all just different manifestations
of the same fundamental problem.

Neil.