This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, Fortran] preparing procedure pointers


2008/4/5, Tobias Schlüter <tobias.schlueter@physik.uni-muenchen.de>:
>  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?

Well, I don't know. In principle procedure pointers could be
identified uniquely by having the attributes "attr.procedure" and
"attr.pointer". But of course one could think about adding
BT_PROCEDURE_POINTER to make the distinction clearer. Right now I
would think that this is not really needed, but I haven't given this
much thought yet.

Anyway I think this is independent of the patch I just sent, which is
more of a fix to my PROCEDURE implementation from last year (with
things like procedure pointers and type-bound procedures in mind), and
of course does not yet implement procedure pointers.


>  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.

I don't care about the name a lot. If you have a better suggestion we
can surely change this.

Btw, is it possible that there is a documentation error in gfotran.h?
In the declaration of gfc_symbol I found the following:

  /* The interface member points to the formal argument list if the
     symbol is a function or subroutine name.  If the symbol is a
     generic name, the generic member points to the list of
     interfaces.  */

I think this mistakes the 'interface' member with the 'formal' member,
right? After all it cannot refer to the 'interface' member, which I
introduced last year, and which I want to move to gfc_typespec with
this patch I just sent. This piece of documentation clearly does not
come from me.


>  ps how's theoretical high-energy physics doing?

Actually it's rather theoretical nuclear/hadron physics for me. And
I'm still writing my diploma thesis on in-medium properties of vector
mesons and dilepton production in a BUU transport model, which I will
finish this summer.

Cheers,
Janus


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]