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]

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


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