[PATCH, Fortran] preparing procedure pointers

[Tobias Schlüter]

Janus Weil wrote:
> Hi all,
> when I implemented PROCEDURE statements last year, I introduced a new
> field named "interface" into "gfc_symbol", which should point to the
> symbol which a PROCEDURE gets its interface from. Back then I wasn't
> quite sure whether to put this new field into "gfc_symbol" or
> "gfc_typespec", and decided somehow to put it into "gfc_symbol" (see
> http://gcc.gnu.org/ml/fortran/2007-08/msg00357.html and follow-ups).
> Actually now I think that this was a mistake, and it would have been
> better to put it into "gfc_typespec". One reason for this is that one
> would also like to use this same field for type-bound procedures,
> which is not possible if it sits in "gfc_symbol", since type-bound
> procedures are "components" of a derived type/class and would be
> represented by "gfc_component". Moreover there are no really
> convincing reasons that this field should be in "gfc_symbol". And in
> g95, which has procedure pointers already implemented, this field is
> also in the typespec.
> Does everyone agree with me in this argumentation? Or are there any
> other arguments against it? If not, I think we should change this
> before starting to implement procedure pointers etc. The attached
> patch does just that. It is rather mechanical and doesn't produce any
> regressions in the gfortran testsuite on i686-pc-linux-gnu. Ok for
> trunk?

When I saw the patch last year I thought (I don't remember if I voiced 
this) that the right thing to do would be to make procedure pointers 
types in their own rights (i.e. add BT_PROCEDURE_POINTER to enum bt, 
link to another gfc_typespec or gfc_interface much in the same way 
BT_DERIVED is handled).  This is fairly similar conceptually to your 
change, but it might make the distinction clearer in the code.  Have you 
thought about this approach?  Do you think there's a reason to prefer 
this or yours?

Otherwise, I think your patch is fine, as it is indeed fairly 
mechanical.  On a bikeshedding level, I'm not sure if I like the name 
"interface" for the field, as interfaces are of a different type in 
gfortran, namely gfc_interface.

Cheers,
- Tobi

ps how's theoretical high-energy physics doing?