Re: PROCEDURE with implicit interface as actual argument

Richard Maine wrote:
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
similar, 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. Admittedly, the answers might come out the same by
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
.

Relevant Pages

  • Attribute for unused dummy arguments
    ... A procedure interface may be predefined or shared by several distinct procedures. ... Dummy arguments with INTENTare often present as dummy arguments for the single purpose of deallocating and/or default-initializing their components. ... With this background, would it make sense to add an attribute to the language which asserts that a particular implementation of the procedure does not reference a particular dummy in its body? ... Probably it is not sufficiently important for a language extension, but I am a bit annoyed of accumulating compiler warnings from this source. ...
    (comp.lang.fortran)
  • Re: calling a subroutine with optional arguments
    ... I have a question about calling a subroutine with optional arguments. ... present when invoking a procedure with an explicit interface. ... the dummy argument, that's simply not true. ...
    (comp.lang.fortran)
  • Re: Are procedure dummy arguments ignored in generic procedure resolution?
    ... > procedures via an interface block or an external statement, ... > a value of that implicit type or a subroutine if the dummy argument ... > has no declaration in the interface block. ... block or an external statement. ...
    (comp.lang.fortran)
  • Re: Extending types and ambiguous interfaces
    ... With these signatures and a generic interface I get a message that the ... "If the reference is consistent with a nonelemental reference to one ... declared type of "class". ... "A dummy argument is type, kind, and rank compatible, or TKR ...
    (comp.lang.fortran)
  • Re: Extending types and ambiguous interfaces
    ... "If the reference is consistent with a nonelemental reference to one ... of the specific interfaces of a generic interface that has that name ... declared type of "class". ... "A dummy argument is type, kind, and rank compatible, or TKR ...
    (comp.lang.fortran)