Renaming module procedures
in [Fortran]
|
Prev: ENTRY statement
Next: Namelist/module-question
From: Richard Maine on 30 Sep 2009 11:56 helvio <helvio.vairinhos(a)googlemail.com> wrote: > Do you mean my try at using a generic interface? (I think that's how > they're called) :/ Yep. > module mod > implicit none > private > public :: func, subr > contains > > function func() result(res) > real :: res > real, parameter :: one = 1. > res = one > end function func > > subroutine subr(x) > interface newname > function func() > end function func > end interface > real, intent(out) :: x > x = newname() > end subroutine subr > > end module mod Your problem here is that you are using an interface body for func. You can't do that for a module procedure. A module procedure already has an explicit interface anywhere that it is accessible; separately specifying its interface would be a kind of duplicate declaration that is not allowed. Your interface body for func *OVERRIDES* the func from the module, telling the compiler to look instead for an external function named func. There is no such external function, which then causes the error message you saw. This is the kind of thing that the MODULE PROCEDURE statement is for. (Or better, the more general PROCEDURE statement without the MODULE restriction, but that's an f2003 feature). It just says to use the procedure whose interface is already known, rather than respecifying the interface. Using it, your interface block would be interface newname module procedure func end interface I don't think I've ever actually used a module procedure statement other than in the global scope of the module, but it ought to work as well in a module subroutine, I'd think (without checking). As an aside, one doesn't "normally" use a generic interface just for renaming; it is more to allow multiple procedures to share the same name. It can sort of be used for renaming, but as that isn't really the purpose, some gotchas can result. For example, you can't pass a generic procedure as an actual argument. I'm not sure whether renaming was the sole purpose of it here or whether that was just the result of (helpful) simplification for posting. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: helvio on 30 Sep 2009 12:12 On Sep 30, 4:56 pm, nos...(a)see.signature (Richard Maine) wrote: > This is the kind of thing that the MODULE PROCEDURE statement is for. > (Or better, the more general PROCEDURE statement without the MODULE > restriction, but that's an f2003 feature). It just says to use the > procedure whose interface is already known, rather than respecifying the > interface. Using it, your interface block would be > > interface newname > module procedure func > end interface > > I don't think I've ever actually used a module procedure statement other > than in the global scope of the module, but it ought to work as well in > a module subroutine, I'd think (without checking). Yeah, I tried with and without the 'module interface' statement, none worked. I know that in a module the explicit interface for internal procedures is done by the compiler, and the programmer shouldn't do a thing. I knew it was a long shot, but I thought that since they have the same scope, then it was worth a try. > As an aside, one doesn't "normally" use a generic interface just for > renaming; it is more to allow multiple procedures to share the same > name. It can sort of be used for renaming, but as that isn't really the > purpose, some gotchas can result. For example, you can't pass a generic > procedure as an actual argument. I'm not sure whether renaming was the > sole purpose of it here or whether that was just the result of (helpful) > simplification for posting. What I wanted to know was exactly that: to know how to rename the function FUNC *inside* the subroutine SUBR, when both procedures are contained within the same module. I tried to use the interface as a trick for renaming, but that obviously doesn't work. But it's not a big deal, it was just a curiosity. ;) Thank you all! -- helvio
From: Richard Maine on 30 Sep 2009 12:43 helvio <helvio.vairinhos(a)googlemail.com> wrote: > Yeah, I tried with and without the 'module interface' statement, none > worked. Well, it is a module "procedure statement", not "module interface". I'm not sure whether the "typo" was just in your posting or actually in the code. If it was actually in the code, then that would explain it not working. If you speled it correctly in the code, it ought to work (even though, as I noted, I consider that a bit of a strange use of generics). Well, since you did post a very nice self-contained sample, I'll go ahead and try it. (Hmm. Your original crashed one of the compilers I tried; time for a bug report). I changed the interface body to a module procedure statement. It then works fine on the Nag compiler. G95 bitches about the module procedure func "never appearing in a module". But g95 also works fine if I move the interface block up into the global scope of the module. Apparently I'm not the only one who normally does things like that just in the module scope, but I think it is supposed to work in either place. Will have to check for sure and then likely submit a bug report to Andy... if he is still around. Someone else mentioned not having heard from him for a while, and I notice the web site suddenly stopped getting updates about 3 months ago. I hope he's ok. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: helvio on 30 Sep 2009 13:07 On Sep 30, 5:43 pm, nos...(a)see.signature (Richard Maine) wrote: > Well, it is a module "procedure statement", not "module interface". I'm > not sure whether the "typo" was just in your posting or actually in the > code. Sorry, it's a typo in my post, I wrote MODULE PROCEDURE in my code. > It then works fine on the Nag compiler. I don't have the NAG compiler... :/ > G95 bitches about the module procedure func "never appearing in a > module". But g95 also works fine if I move the interface block up into > the global scope of the module. Same thing happened when I compiled it with mine g95. -- helvio
From: Richard Maine on 30 Sep 2009 13:16
helvio <helvio.vairinhos(a)googlemail.com> wrote: > On Sep 30, 5:43 pm, nos...(a)see.signature (Richard Maine) wrote: > > G95 bitches about the module procedure func "never appearing in a > > module". But g95 also works fine if I move the interface block up into > > the global scope of the module. > > Same thing happened when I compiled it with mine g95. I just finished submitting a bug report on that. I'm wondering if the module procedure statement accidentally blocks the host association of the procedure (and thus messes itself up). -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain |