PROCEDURE with implicit interface as actual argument
Janus Weil
I'm wondering whether the following Fortran code is legal:
program myProg
PROCEDURE () :: proc3
call proc4( proc3 )
CONTAINS
subroutine proc4( arg1 )
PROCEDURE(real) :: arg1
print*, 'the func: ', arg1(0)
end subroutine proc4
end program myProg
gfortran currently rejects this with
call proc4( proc3 )
1
Error: Type/rank mismatch in argument 'arg1' at (1)
while ifort accepts it. So, is this program valid with respect to the
Fortran 2003 standard or not?!? (assuming that proc3 is provided
externally ...)
Cheers,
Janus
Richard Maine
I think it is ok, although it is tricky enough that it doesn't shock me
for a compiler to get it wrong (particularly a compiler that doesn't
claim to fully support f2003). It is also tricky enough that I'd easily
believe I could have missed or missinterpreted something in the standard
that prohibits it.
The declaration of proc3 in the main program declares it to be a
procedure, but leaves it unspecified whether it is a subroutine or a
function. I don't like allowing such vagueness in the PROCEDURE
statement. I recall arguing against that particular feature in f2003.
Hmm. Now if it is unspecified whether it is even a function or a
subroutine, what does that say about it's type? If it turns out to be a
function, does that mean implicit typing rules must apply? Or does it
also have unspecified type? Arghh. It's too early for me to be sure on
that part. I can state with assurance that I wouldn't do that. The
standard conformance I'm far less certain on, though I lean towards it
being ok.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
Tobias Burnus
>> I'm wondering whether the following Fortran code is legal:
>> program myProg
>> PROCEDURE () :: proc3
>> call proc4( proc3 )
>> CONTAINS
>> subroutine proc4( arg1 )
>> PROCEDURE(real) :: arg1
>> print*, 'the func: ', arg1(0)
>> end subroutine proc4
>> end program myProg
>>
>
> for a compiler to get it wrong (particularly a compiler that doesn't
> claim to fully support f2003). It is also tricky enough that I'd easily
> believe I could have missed or missinterpreted something in the standard
> that prohibits it.
Analogously one can create such a program:
module m
implicit none
contains
subroutine sub(a)
interface
function a(x)
real :: a, x
intent(in) :: x
end function a
end interface
print *, a(4.0)
end subroutine sub
end module m
use m
implicit none
EXTERNAL foo ! implicit interface
call sub(foo) ! sub's argument has an explicit interface
end
And ask whether it is valid. NAG f95, Lahey, and gfortran reject that
program, openf95, sunf95, g95 and ifort accept it.
I think the question is really boils down to understand what the
following means:
"12.4.1.3 Actual arguments associated with dummy procedure entities"
[...]
"If the interface of the dummy argument is explicit, the characteristics
listed in 12.2 shall be the same for the associated actual argument and
the corresponding dummy argument"
Is "external" or "procedure()" a carte blanche which always fits? Or
does one need in this case an explicit interface? I'm somehow also
inclined that this only means a constraint to the user that the
interface has to match and not that the interface has to be explicit.
But given that NAG and Lahey have a good record of giving valid error
messages ...
Tobias
Richard Maine
...
> >> program myProg
> >> PROCEDURE () :: proc3
> >> call proc4( proc3 )
> >> CONTAINS
> >> subroutine proc4( arg1 )
> >> PROCEDURE(real) :: arg1
> >> print*, 'the func: ', arg1(0)
> >> end subroutine proc4
> >> end program myProg
> >>
> Analogously one can create such a program:
> "If the interface of the dummy argument is explicit,...
Well, that applies to your version, but not directly to the original,
which did not have an explicit interface. I agree the questions are
simillar, but at least the original one can't all boil down to the
interpretation of something that starts with a conditional that is false
for that case. Admitedly, the answers might come out the same by
parallel reasoning.
Tobias Burnus
>> I think the question is really boils down to understand what the
>> following means:
>>
>> "12.4.1.3 Actual arguments associated with dummy procedure entities"
>> [...]
>> "If the interface of the dummy argument is explicit,...
>
> Well, that applies to your version, but not directly to the original,
> which did not have an explicit interface. I agree the questions are
> interpretation of something that starts with a conditional that is false
> parallel reasoning.
Somehow I missed that. For implicit interfaces, one has:
"If the interface of the dummy argument is implicit and either the name
of the dummy argument is explicitly typed or it is referenced as a
function, the dummy argument shall not be referenced as a subroutine and
the actual argument shall be a function, function procedure pointer, or
dummy procedure."
For a simple EXTERNAL or PROCEDURE() I think that quite explicitly
allows it; for "PROCEDURE(), POINTER" I would argue that it is valid as
well, though arguably less obvious. (If the target is a function - does
this make the pointer automatically a function procedure pointer? I
think that's intended but I am not sure that's written as such.)
If I replace the explicit interface in my example by "real, external ::
a" I get the same result: NAG f95 and gfortran reject the program, g95,
ifort and openf95 accept the program.
Richard, do you agree with my conclusion for _my_ unmodified program and
for my program modified as above (implicit interface for a dummy, but
typed as real and used as function) is valid, which means that NAG f95,
Lahey and gfortran have too strict checking? For the original example
you were leaning towards it being ok - are you now more certain about it
or less or equally?
Thanks for your always helpful judgments!
Tobias
Glen Herrmannsfeldt
(snip)
> The declaration of proc3 in the main program declares it to be a
> procedure, but leaves it unspecified whether it is a subroutine or a
> function. I don't like allowing such vagueness in the PROCEDURE
> statement. I recall arguing against that particular feature in f2003.
That vagueness goes back to (at least) Fortran 66, though.
As far as I know, function names have to be used for calling
functions, and subroutine names fur subroutines, but the routine
passing the name as an argument doesn't need to know.
> Hmm. Now if it is unspecified whether it is even a function or a
> subroutine, what does that say about it's type? If it turns out to be a
> function, does that mean implicit typing rules must apply? Or does it
> also have unspecified type? Arghh. It's too early for me to be sure on
> that part. I can state with assurance that I wouldn't do that. The
> standard conformance I'm far less certain on, though I lean towards it
> being ok.
-- glen
Richard Maine
> "If the interface of the dummy argument is implicit and either the name
> of the dummy argument is explicitly typed or it is referenced as a
> function, the dummy argument shall not be referenced as a subroutine and
> the actual argument shall be a function, function procedure pointer, or
> dummy procedure."
Which, is a bit of long-winded standard-speak for what I'd translate as
"if you do things only make sense for functions, then it darn well
better be a function."
> For a simple EXTERNAL or PROCEDURE() I think that quite explicitly
> allows it; for "PROCEDURE(), POINTER" I would argue that it is valid as
> well, though arguably less obvious. (If the target is a function - does
> this make the pointer automatically a function procedure pointer? I
> think that's intended but I am not sure that's written as such.)
>
> If I replace the explicit interface in my example by "real, external ::
> a" I get the same result: NAG f95 and gfortran reject the program, g95,
> ifort and openf95 accept the program.
>
> Richard, do you agree with my conclusion for _my_ unmodified program and
> for my program modified as above (implicit interface for a dummy, but
> typed as real and used as function) is valid, which means that NAG f95,
> Lahey and gfortran have too strict checking? For the original example
> you were leaning towards it being ok - are you now more certain about it
> or less or equally?
I think it is ok, but I've got the same waffly (sp?, but then maybe it
isn't a word at all) uncertainty as I had before. I can't make a more
certain judgement from looking at isolated quotes. I'd actually have to
go peruse the standard (which I'm feeling too lazy to do right now),
because there is the possibility that there might be something elsewhere
that has the effect of forbidding something of this. I can't look at one
quote and conclude that it means that another one doesn't exist - unless
that one quote is pretty explicit about saying that something is
allowed, and I don't see that degree of explicitness in what you quoted.
I see an implication, but it isn't what I'd call explicit.
In this kind of question, I don't feel I can just rely on my intuition,
because I find the whole idea of declaring something quite that vaguely
to be a bit coubnter-intuitive. So it takes actual reading of the darned
document.
Richard Maine
> Richard Maine wrote:
> (snip)
>
> > The declaration of proc3 in the main program declares it to be a
> > procedure, but leaves it unspecified whether it is a subroutine or a
> > function. I don't like allowing such vagueness in the PROCEDURE
> > statement. I recall arguing against that particular feature in f2003.
>
> That vagueness goes back to (at least) Fortran 66, though.
Yes, I know. That doesn't mean I have to like it or to favor extending
it. And I don't.
paul.rich...@gmail.com
Maybe the vagueness in the standard argues that Richard's point, "if
you do things only make sense for functions, then it darn well better
be a function." had better appear in a warning?
Cheers
Paul
Glen Herrmannsfeldt
I wrote this one some time ago, which I believe should be legal,
but some compilers (and maybe some people) disagree.
Note that fun is only called as a function, and sub only as
a subroutine.
external sub,fun
call test(sub,.true.,x)
call test(fun,.false.,y)
write(*,*) x,y
end
subroutine test(f,select,xy)
logical select
if(.not.select) xy=f(1.23)
if(select) call f(xy)
return
end
subroutine sub(x)
x=3.4
return
end
function fun(x)
fun=4.5
return
end