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

[Kurt W Hirchert]

On 1/4/2016 2:50 PM, Bill Long wrote:
> On Jan 4, 2016, at 2:24 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:
>
>> On Mon, 2016-01-04 at 19:52 +0000, Bill Long wrote:
>>> 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
>>>
>> A submodule can access private entities of its ancestor.
> Valid point.  So, the benefit of Ian?s example is to allow separation of the BIND(C) procedures (to prevent compilation cascades) while allowing them to still have access to private entities in the module.   That does seem like a reasonable use case.
>
> Cheers,
> Bill
It seems an utterly unreasonable case to me.  Given that a module like m 
is complete unto itself. I find it completely unacceptable that someone 
could "hack into" its private data and procedures simply writing a 
submodule that claims that module as its ancestor. Fortunately, it 
appears to me that these examples do not conform to the standard.  As I 
read F2008, C1506 in 15.5.2 precludes such "back door" access to 
submodules through binding labels.

-Kurt

Disclaimer:  Only the earliest exploratory work on submodules had been 
done at the time I retired, so it is entirely possible that I am missing 
or badly misreading something here.