This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
GENERIC bindings
Hi Tobias!
I'm just writing down what comes to my mind about type-bound procedures
in gfc-internals.texi, and hopefully I manage to get dump-parse-tree.c
quite acceptable tomorrow, too.
Then I can start thinking about the next steps.
Daniel Kraft wrote:
Committed as rev. 139724. I'll start working on the documentation
stuff tomorrow, hopefully :) GENERIC or PROCEDURE(interface) will be
the next things to follow that (PROCEDURE(interface) can't be
implemented without abstract types, IIRC? Or did I misunderstand this?)
I would start with GENERIC, esp. with "GENERIC :: procname =>" [the
ASSIGNMENT() and OPERATOR() are less useful, but probably quite easy
when procname works]. I see more value in this than in abstract types,
especially as long as CLASS does not work. (Personal opinion, change the
order if you think abstract interfaces are more useful or you like
implementing them more.)
Well, as suggested (and I agree here, AFAIK) abstract types are much
simpler to implement; that would be an advantage :D On the other hand,
I'd like GENERIC more, too. I'll think about it and if I believe I've
got enough understanding to do it, I'll start with that.
Abstract types should be rather trivial to implement: One simply does
not allow "TYPE(abstract_type)". When resolving an abstract type, one
needs to check that that type is not BIND(C) or SEQUENCE (because then
it is not extensible, cf. C428).
Any you are right with regards to procedure(interface). The standard has:
Actually I've to admit that I just thought about this because you
mentioned it once. Up to now I've only read very briefly over the
standard regarding both GENERIC and PROCEDURE(interface) with DEFERRED.
So far as I see it, for GENERIC we have this semantics:
GENERIC :: name => proc1, proc2, proc3
and then CALL myobj%name (arg1, arg2) should call the one of those three
procedures matching the arguments, right? And as I understand the
standard, the thing above could also be written:
GENERIC :: name => proc1
GENERIC :: name => proc2, proc3
as long as all generics with the same name do have the same
access-specifier. I do not, however, really understand why the "in the
specification part of a module" is with this clause (C459 in the draft
F2003 standard).
I guess there's already some code available to be reused for handling of
GENERICs, right? I suppose I need a method to check that each of the
procedures bound to a generic name is distinguishable by its interface
(16.2.3: Restrictions on generic declarations), as well as a method to
find the right binding for an actual arglist--and those two are probably
already available. At least I hope so...
Next I suppose I'll have to extend gfc_typebound_proc to have an
attribute whether this binding is generic and in that case a whole
symtree/linked-list/whatever of binding-targets instead of just one, right?
What do you think, or did I misunderstand something? Admittedly I do
not yet know much about GENERICs in general in Fortran.
BTW, it seems that GENERIC bindings do not override but extend the
inherited bindings. Does this mean that DEFERRED and NON_OVERRIDABLE
are errors on generic bindings? So far I couldn't find this "exactly"
in the standard, but it would make sense, wouldn't it?
Enough confusion for today,
Daniel
PS: How long do I have time for GENERIC until stage 3? Or would it be
ok to post a "partial" patch before August, 31st and continue working on it?
--
Done: Arc-Bar-Cav-Sam-Val-Wiz, Dwa-Elf-Gno-Hum-Orc, Law-Neu-Cha, Fem-Mal
To go: Hea-Kni-Mon-Pri-Ran-Rog-Tou