overloaded function and (apparently) recursive calls
m
when compiling the attached code, two compilers complain about a
recursive call for "f" (ifort and nag), while a third one accepts the
code (gfrotran). My impression is that the code is fine, since in
practice there are no recursive call, but I would appreciate your
comments.
Best regards,
Marco
module mod_test
implicit none
type ta
integer :: n
end type ta
interface f
module procedure f0, f
end interface
contains
pure function f0(n) result(y)
integer, intent(in) :: n
type(ta) :: y
y%n = n
end function f0
pure function f(p,q) result(y)
integer, intent(in) :: p,q
type(ta) :: y
y = f(p+q)
end function f
end module mod_test
michael...@compuserve.com
The function 'f' is referencing itself -- a recursive call. You
probably mean to reference f0 from within f; the use of generic names
is restricted to be outside the module that defines them.
HTH
Mike Metcalf
m
Thank you Mike, yes, my point is that the call to the generic f is
resolved as a call to f0, after which there is no recursion. I am not
sure what you mean by
the use of generic names
> is restricted to be outside the module that defines them.
>
Do you mean that the generic name can never be used in the module
where the generic is defined? And also, does the fact that the
specific functions collected in a generic have a PUBLIC or PRIVATE
attribute have any impact on the availability of the generic in
modules which use it?
Thank you,
Marco
paul.rich...@gmail.com
Dear Mike,
> The function 'f' is referencing itself -- a recursive call. You
> probably mean to reference f0 from within f; the use of generic names
> is restricted to be outside the module that defines them.
I cannot find this last in the standard; or, at least, 14.1.2.3 does
not contain anything that I would interpret this way. 14.1.2 seems to
me to explicitly allow the generic name to be used within the
containing module. Before I post a bug report in gfortran, I wish to
be sure of my grounds:-)
For the record, Lahey agrees with gfortran.
Cheers
Paul
michael...@compuserve.com
Sorry, yes, you're right that generic names are accessible from within
the module, but not in this case where Section 12.5.2.2 states (at
lines 30-32 on p. 207): "If RESULT is specified, the name of the
result variable of the function is <result-name>, ..., and all
occurrences of the function name in <execution-part> in the scoping
unit are recursive function references." (Prior to that it specifies
that the recursive specifier is required for a recursive call.)
Regards,
Mike Metcalf
Richard Maine
> Sorry, yes, you're right that generic names are accessible from within
> the module, but not in this case where Section 12.5.2.2 states (at
> lines 30-32 on p. 207): "If RESULT is specified, the name of the
> result variable of the function is <result-name>, ..., and all
> occurrences of the function name in <execution-part> in the scoping
> unit are recursive function references."
Hmm. Intriguing. That looks to me like an error in the standard. I'd
guess that it overlooked the case where the function name is also the
name of a generic, in which case the name could be a non-recursive
reference to the generic.
I see nothing obviously wrong with the code (and I sure wouldn't go
"fixing" a compiler that allowed it without submitting an interp request
first).
In support see 16.4.1.3 of f2003. That's the section on host
association. It has a tedious list of the exact syntax items that block
host association. If the host association were blocked in this case, I'd
expect to see it mentioned there. Instead,
1. I don't see it in the long numbered list. Maybe I overlooked it, as
the list is long and painful to carefully read, but I don't see it.
2. Even if it were in the list, the line after the numbered list says
that it is a list of cases where nongeneric names are inaccessible. I
see nothing that says a generic name would be inaccessible.
It seems to be that there must be an error in either 12.5.2.2 or
16.4.1.3, as they look inconsistent on this point to me. I'm guessing it
is 12.5.2.2 that is in error, but I'd think an interp request in order.
Thinking a little further along this line, I contemplate what might
happen if you had a generic name in the host and used that name for
something other than a procedure name. Since the local declaration does
not block access to generic names from the host, I think that what you
would then have is illegal code because you were using the same name for
a generic and for something else; that is allowed only in the special
case of the something else being a specific in the generic.
I personaly advise against the practice of making a specific procedure
with the same name as the generic. The standard allows it, but I think
that it gives rise to confusions at least in reading the code. Looks to
me like this is a case where it is confused even in the standard (and in
some compilers, though one might debate which ones).
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain