This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [PATCH, Fortran] preparing procedure pointers
- From: "Janus Weil" <jaydub66 at googlemail dot com>
- To: "Tobias Schlüter" <tobias dot schlueter at physik dot uni-muenchen dot de>
- Cc: "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>, "Tobias Burnus" <burnus at net-b dot de>, "Paul Thomas" <paulthomas2 at wanadoo dot fr>
- Date: Sat, 5 Apr 2008 14:37:24 +0200
- Subject: Re: [PATCH, Fortran] preparing procedure pointers
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=2CTN+g3MABMpCBggYVV1dp4a1GE8Cm9s52OCwDEYVPQ=; b=yBp1rXZwlxsr8fqLB7rmIdqgfdYoKYqkdh6Hv7nZsdj6V4zi8xPytfgQZfx/4zMuU5ueSrLEHRVLw6jXthgOUOMYCgY0ii5IdoOYj2flA5NfYtHAz7dKnnd4kjSXnvHFrehYatmxCn5UNkULGO3wBWym7jfKV9V7skbDMs9uRL4=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=wAZCa3Sq0mbJZqoWc5hDA5W3sqWimmieD1Ibo6BYSlLoN4kB0kyiuqQHUtXVxKJed6AsvLdf3X4HdeGLRscDRD3JWB3ekFjMbVHZHdb3Dy+Su0qtI0r9pBNkchj7IXQKVqwn9aC6buybCWaDD2iQ9IYZbwSKJYm+oULuxinDqgE=
- References: <854832d40804041457s26c46250x143d48ef93502d2b@mail.gmail.com> <47F6A71E.3070406@physik.uni-muenchen.de>
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