Re: why doesn't this compile ?

Richard E Maine wrote:
[...]
Up though f95, there are 2 options for specifying a specific procedure in a generic interface block. You either have an interface body or use a module procedure statement. If you have a procedure whose interface is already explicit, but which is not a module procedure, then this is awkward. 

    Before I read this response, but after rereading the "compilation
 problem" thread, I modified the OP's original code (single program,
 no module) to drop the interface bodies from the interface for "f"
 and and replace them by what you'd have if these were in a module:

-----------------
program test_array_arguments

  implicit none

  ! This interface allows us to pass both rank 1 and rank 2 arrays to the
  ! function f.
  interface f
      module procedure f_1, f_2            ! <<<==========
  end interface f

  integer, dimension(2,3) :: x
[...]
---------------------

 Even though "module procedure" didn't make intuitive sense outside
 a module(!) that was all I could think to do.

    Again on Alpha/VMS 7.3-1 with HP Fortran V7.6-3276-48D52,
 compiling with,

	f90/stand=f95 TEST_ARRAY_ARGUMENTS2

 was successful with no errors, and the program produced the same
 results as the "modulized" version now on the OP's web site.
 (Compiling with /standard=f90 produced this error:

----------------------
end interface f
.................^
%F90-W-WARNING, A generic-spec included on an end-interface-stmt is not standard
Fortran 90. [F]
at line number 12 in file TEST_ARRAY_ARGUMENTS2.F90;1
----------------------

 But simply removing the "f" at the end of "end interface" allowed
 successful compilation and produced the same outout...)

     My question whether the VMS Fortran compiler support of
 "module procedure" in the main program is a compiler *extension*,
 or is this standard-conforming F95?  What about F2003??

In f2003, this is solved by dropping the keyword "module" from the module procedure statement. The restriction to module procedures was silly in the first place; the only thing important was that an explicit interface be accessible. Of course, the keyword "module" is still allowed for compatibility with existing code (and in that case, it is restricted to being a module procedure just because it is strange to have a "module procedure" statement refer to something that isn't). But there will probably be little reason for using the "module" keyword in new f2003 code except for issues of compatibility with f90/f95 compilers; it doesn't add any useful functionality. 

     Which begs the question: how *would* you define an generic
 interface to program-contained procedures under F95?  I'd like
 to see an example of the awkwardness, both for education and
 for entertainment. :-) :-)

	-Ken
--
I don't speak for Intel, Intel doesn't speak for me...

Ken Fairfield
D1C Automation VMS System Support
who:   kenneth dot h dot fairfield
where: intel dot com
.

Relevant Pages

  • Re: ALLOCATABLE or POINTER
    ... INTERFACE foo ... !MODULE PROCEDURE fooalloc,fooptr! ... depends on the compiler and even the version of the compiler: ... understand: ambiguous interface. ...
    (comp.lang.fortran)
  • Re: Essential Features
    ... end module funcs ... IntelFortran Compiler for IntelEM64T-based applications, ... internal1.f90: Error: Procedure name in MODULE PROCEDURE statement must ... get away with the MODULE PROCEDURE statement where the PROCEDURE ...
    (comp.lang.fortran)
  • Re: compilation problem with module function interface definition
    ... The module compiles cleanly with the interface block commented out. ... > type obj ... module procedure create_obj1 end interface ... But I wonder as to the reason why the compiler does not include the function type when dealing resolving polymorphisms? ...
    (comp.lang.fortran)
  • Re: Use of interface within module?
    ... Should the interface be used within the ... -| subroutine plot_a ... The interface block is required so that the compiler can ... -|so the module procedure statement suffices in this case. ...
    (comp.lang.fortran)
  • Re: Proposal: NOEXTERNAL
    ... subroutine differently from what the interface says. ... For modules the compiler spits the dummy when you call your module procedure with an incorrect interface. ... For submodules, the compiler should spit the dummy when it sees that the module interface definition is different from the submodule one. ...
    (comp.lang.fortran)