(j3.2006) Ian Harvey complains about F08/0142 (can't have a submodule of module with no separate module procedures)

[Bill Long]

On Jan 4, 2016, at 9:12 AM, Lionel, Steve <steve.lionel at intel.com> wrote:

> I am just passing this on, though I did reply in the newsgroup that several implementers (including us) said that the overhead of not having the constraint was considerable.
>  
> Steve Lionel
> Intel Developer Support
> Merrimack, NH
> 
> 


Ian says:

> Intepretation F08/0142, currently before J3, deals in part with the 
> topic of this thread (it was the inspiration for the original post). In 
> its current form I don't think the draft response to that interpretation 
> is accurate, and I think it potentially introduces a pointless annoyance 
> into the language.
> 
> The body text of that interpretation states:
> 
> If a module declares no separate module procedure, it cannot
> have a useful submodule as such a submodule has nothing to
> provide. Its module procedures and variables cannot be
> referenced by any program.

?

> 
> MODULE m
> IMPLICIT NONE
> INTERFACE
> MODULE SUBROUTINE pointless ; END SUBROUTINE pointless
> END INTERFACE
> INTEGER, PRIVATE :: x
> CONTAINS
> MODULE SUBROUTINE pointless ; END SUBROUTINE pointless
> END MODULE m
> 
> SUBMODULE (m) sm
> IMPLICIT NONE
> CONTAINS
> SUBROUTINE set_it(arg) BIND(C)
> USE, INTRINSIC :: ISO_C_BINDING, ONLY: C_INT
> INTEGER(C_INT), INTENT(IN), VALUE :: arg
> x = arg
> END SUBROUTINE set_it
> FUNCTION get_it() BIND(C)
> USE, INTRINSIC :: ISO_C_BINDING, ONLY: C_INT
> INTEGER(C_INT) :: get_it
> get_it = x
> END FUNCTION get_it
> END SUBMODULE sm

OK, I can buy that the Interp?s argument has holes.  It is possible to access submodule procedures without having an interface in the ancestor module. However, this seems like a bit of an artificial use of submodules.  Instead of

module m
! declare some types
end module m

submodule (m) sm

! define some BIND(C) procedures that depend on the types from module M (host associated).  Otherwise there is no connection to M. 

end submodule sm


why not do this instead:

module sm
  use m

! define some BIND(C) procedures that depend on the types from module M (use associated). 

end module sm

You would not actually need to USE sm anywhere (if all the calls to the procedures are from C), so the compilation cascade is avoided anyway. And you still have all the benefits of the procedures automatically being able to see each others interfaces.   I don?t see any advantage of the submodule version, and the module sm version seems more natural. 


I can accept that the current wording of the Interp  answer is not accurate.  But I don?t think it follows that there is useful capability being removed by the new constraint.


Cheers,
Bill




Bill Long                                                                       longb at cray.com
Fortran Technical Support  &                                  voice:  651-605-9024
Bioinformatics Software Development                     fax:  651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101