(j3.2006) Question about submodule using its ancestor modue
Daniel C Chen
cdchen
Thu Nov 20 10:27:32 EST 2014
I think the modified code is still OK.
I think what C1271 really wants to say is the procedure-name must be
declared to be a separate module procedure in the ancestor module or one of
its ancestor submodules. Even though it may be 'overridden' by the
use-association, but it doesn't seem it will change the functionality after
all.
BTW, as the modified code, is it correct to say that 'sub' is 'declared' in
'm2' even though 'm2' just accesses 'sub' via use-association and the
actual declaration of 'sub' is in 'm1'?
Thanks,
Daniel
XL Fortran Development - IBM Toronto Software Lab
Phone: 905-413-3056
Tie: 969-3056
Email: cdchen at ca.ibm.com
http://www.ibm.com/software/awdtools/fortran/xlfortran
From: "Bader, Reinhold" <Reinhold.Bader at lrz.de>
To: fortran standards email list for J3 <j3 at mailman.j3-fortran.org>
Date: 11/19/2014 17:21
Subject: Re: (j3.2006) Question about submodule using its ancestor modue
Sent by: j3-bounces at mailman.j3-fortran.org
> -----Urspr?ngliche Nachricht-----
> Von: j3-bounces at mailman.j3-fortran.org [mailto:j3-bounces at mailman.j3-
> fortran.org] Im Auftrag von Bill Long
> Gesendet: Mittwoch, 19. November 2014 22:26
> An: fortran standards email list for J3
> Betreff: Re: (j3.2006) Question about submodule using its ancestor modue
>
> I agree with Daniel that USE association is supposed to override HOST
> association.
OK, 16.5.1.4 para 2. I'd gotten too firmly into my mind that submodules
have host access as a matter of principle ...
> However, then consider a modified case:
>
> module m1
> interface
> module subroutine sub(n)
> integer :: n
> end subroutine sub
> end interface
> end module m1
>
> module m2
> use m1
> end module m2
>
> submodule (m1) foo
> use m2
>
> contains
>
> module subroutine sub(n)
> integer :: n
> n = n + 1
> end subroutine sub
>
> end submodule foo
>
>
> and the constraint on the name of a submodule procedure:
>
> C1271 (R1239) The procedure-name shall have been declared to be a
separate
> module procedure in the containing
> program unit or an ancestor of that program
unit.
>
>
> SUB is declared to be a separate module procedure in module m2, but m2 is
not
> an ancestor of submodule foo. All entities in m1 are blocked in foo from
host
> association because of the USE of m2. If we're OK with the idea that
the
> declaration of the separate module procedure can come from a module that
is
> not an ancestor of the submodule containing the implementation, then this
code
> is OK. But I don't think that is what C1271 is intended to say.
I agree this second example is non-conforming. The only
way to avoid this situation then seems to be to say
use m2, only :
which would return access by host to sub from foo, and therefore not
violate the
constraint any more. Do further problematic examples exist?
>
> Cheers,
> Bill
>
>
>
>
>
>
> On Nov 19, 2014, at 10:03 AM, Daniel C Chen <cdchen at ca.ibm.com> wrote:
>
> > I agree with Reinhold that the code should be conforming. However, I
think
> the use association should override the host association. It should have
the
> same effect as
> > Program main
> > Use m
> > Contains
> > Subroutine sub()
> > Use m
> > End
> > End :
> >
> > Thanks,
> >
> > Daniel
> >
> > XL Fortran Development - IBM Toronto Software Lab
> > Phone: 905-413-3056
> > Tie: 969-3056
> > Email: cdchen at ca.ibm.com
> > http://www.ibm.com/software/awdtools/fortran/xlfortran
> >
> > <graycol.gif>"Bader, Reinhold" ---11/19/2014 04:03:38---Hello Bill, my
take is
> that the code is conforming, and that host association overrides
> >
> > From: "Bader, Reinhold" <Reinhold.Bader at lrz.de>
> > To: fortran standards email list for J3
<j3 at mailman.j3-fortran.org>
> > Date: 11/19/2014 04:03
> > Subject: Re: (j3.2006) Question about submodule using its
ancestor
> modue
> > Sent by: j3-bounces at mailman.j3-fortran.org
> >
> >
> >
> > Hello Bill,
> >
> > my take is that the code is conforming, and that host association
overrides
> > use association in this context. Because the module must anyway be
compiled
> > before the submodule is, there doesn't appear to be a circularity
problem.
> > I don't think ambiguities can arise (consider the analogous case
> >
> > m1 uses b
> > m2 uses b
> > a uses m1 and m2
> > ).
> >
> > The case of indirect referencing is actually the interesting use case:
Say you
> have
> > an abstract type in m1. This will typically be extended in some other
> > module m2, which needs to use m1. On the other hand, for full
dependency
> > inversion, m1 needs to provide e.g. a procedure to create an object.
This often
> > will imply that the complete inheritance tree must be dealt with, i.e.
the
> procedure
> > specifically needs type information stored in m2. Hence, to avoid
circular
> module
> > references, the procedure needs to be put into a submodule, which uses
m2,
> and therefore
> > indirectly also m1.
> >
> > Cheers
> > Reinhold
> >
> >
> > > -----Urspr?ngliche Nachricht-----
> > > Von: j3-bounces at mailman.j3-fortran.org [mailto:j3-bounces at mailman.j3-
> > > fortran.org] Im Auftrag von Bill Long
> > > Gesendet: Mittwoch, 19. November 2014 00:06
> > > An: fortran standards email list for J3
> > > Betreff: (j3.2006) Question about submodule using its ancestor modue
> > >
> > >
> > > Is the USE statement in the submodule below conforming?
> > >
> > > module m1
> > > real :: x
> > > end module m1
> > >
> > > submodule (m1) bar
> > > use m1
> > > end submodule bar
> > >
> > > Option 1: It is OK, since the USE of m1 in the submodule blocks all
host
> > > association of objects in module m1, so no ambiguity.
> > >
> > > Option 2: No. The submodule is an extension of m1 and this amounts to
a
> > > recursive access to the module.
> > >
> > >
> > > I suspect Option 2 would promote better code and fewer mistakes.
> Particularly if
> > > "use m1" were instead "use m2" where m2 included a USE of m1.
> > >
> > >
> > > Cheers,
> > > Bill
> > >
> > >
> > > Bill Long
longb at cray.com
> > > Fortran Technical Suport & voice:
651-605-9024
> > > Bioinformatics Software Development fax:
651-605-9142
> > > Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101
> > >
> > >
> > > _______________________________________________
> > > J3 mailing list
> > > J3 at mailman.j3-fortran.org
> > > http://mailman.j3-fortran.org/mailman/listinfo/j3
> > _______________________________________________
> > J3 mailing list
> > J3 at mailman.j3-fortran.org
> > http://mailman.j3-fortran.org/mailman/listinfo/j3
> >
> >
> > _______________________________________________
> > J3 mailing list
> > J3 at mailman.j3-fortran.org
> > http://mailman.j3-fortran.org/mailman/listinfo/j3
>
> Bill Long
longb at cray.com
> Fortran Technical Suport & voice:
651-605-9024
> Bioinformatics Software Development fax:
651-605-9142
> Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101
>
>
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3
_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org
http://mailman.j3-fortran.org/mailman/listinfo/j3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20141120/f601e2b7/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://mailman.j3-fortran.org/pipermail/j3/attachments/20141120/f601e2b7/attachment-0001.gif
More information about the J3
mailing list