(j3.2006) (SC22WG5.5372) AW: Question on PURE subroutines
Van Snyder
Van.Snyder
Thu Dec 4 18:50:46 EST 2014
On Thu, 2014-12-04 at 23:43 +0000, Bader, Reinhold wrote:
>
> > -----Urspr?ngliche Nachricht-----
> > Von: j3-bounces at mailman.j3-fortran.org [mailto:j3-bounces at mailman.j3-
> > fortran.org] Im Auftrag von Van Snyder
> > Gesendet: Donnerstag, 4. Dezember 2014 22:57
> > An: j3
> > Betreff: Re: (j3.2006) (SC22WG5.5369) Question on PURE subroutines
> >
> > On Thu, 2014-12-04 at 21:45 +0000, Bill Long wrote:
> > > On Dec 4, 2014, at 2:03 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:
> > >
> > > > On Thu, 2014-12-04 at 16:55 +0000, Bader, Reinhold wrote:
> > > >> Hello all,
> > > >>
> > > >>
> > > >>
> > > >> consider the program
> > > >>
> > > >>
> > > >>
> > > >> module mod_proc_cont_01
> > > >>
> > > >> implicit none
> > > >>
> > > >> type :: cont
> > > >>
> > > >> real, pointer :: p(:) => null()
> > > >>
> > > >> end type cont
> > > >>
> > > >> real, target :: p(2)
> > > >>
> > > >> contains
> > > >>
> > > >> pure subroutine pf(x)
> > > >>
> > > >> type(cont), intent(inout) :: x
> > > >>
> > > >> integer :: i
> > > >>
> > > >>
> > > >>
> > > >> if (associated(x%p)) then
> > > >>
> > > >> x%p = [ (real(2*i), i=1, size(x%p)) ]
> > > >>
> > > >> end if
> > > >>
> > > >> end subroutine pf
> > > >>
> > > >> end module mod_proc_cont_01
> > > >>
> > > >> program proc_cont_01
> > > >>
> > > >> use mod_proc_cont_01
> > > >>
> > > >> implicit none
> > > >>
> > > >> type(cont) :: xx
> > > >>
> > > >>
> > > >>
> > > >> p = [ 1.0, 2.0 ]
> > > >>
> > > >> xx%p => p
> > > >>
> > > >> call pf(xx)
> > > >>
> > > >> write(*,*) p
> > > >>
> > > >> end program proc_cont_01
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> It appears to conform to the Fortran 2008 standard; it is accepted by
> > > >> the compilers available to me. Yet it
> > > >>
> > > >> appears to implement a side effect in a PURE procedure. Was this
> > > >> intended? If not, would adding the following
> > > >>
> > > >> text in 007 fix the problem?
> > > >>
> > > >>
> > > >>
> > > >> [312:30] After "any designator", add " with the POINTER attribute or "
> > > >
> > > > Assuming this is in the first line of C1283 in F08, it goes a bit too
> > > > far. It effectively prevents meaningful use of pointers within pure
> > > > procedures.
>
>
> Agreed. Locally declared objects should still work.
>
> > > >
> > > > For example, if you have several local variables upon which the code
> > > > needs to act in several places, instead of repeating the test throughout
> > > > the code, do the test once and associate a pointer with the necessary
> > > > variable. The proposed change to C1283 would make it impossible to
> > > > assign a value using that pointer.
> > >
> > >
> > > The issue that Reinhold points out is the case of a pointer appearing
> > > in a variable definition context when its target is not a local
> > > variable, but one that is declared in the specification part of a
> > > module. We prohibit direct definition of such a variable in a pure
> > > procedure, so to seems reasonable to also prohibit definition of a
> > > pointer associated with such a variable.
>
> NOTE 12.49 ("pure procedures for morons") seems to think along the same lines ...
> so if the program is determined to stay conforming, perhaps some rewording of
> that NOTE is needed?
Note 12.50 ("Pure subroutines for morons") observes that side effects to
INTENT(OUT), INTENT(INOUT) and pointer dummy arguments are permitted.
Do we want to eliminate pointer dummy arguments from that permission?
That would be a new feature, needing WG5 debate and approval. It could
result in some presently-compliant programs becoming noncompliant.
> > We constrain against direct assignment to such a variable in a pure
> > procedure, but not against indirect assignment, for example, if a dummy
> > argument is a pointer. Reinhold's example is no different from one
> > where the pointer is the dummy argument, not a component of the dummy
> > argument.
>
> The case of a pointer dummy argument would also be covered by the augmented restriction
> (see below for an improved version).
>
> >
> > There are in fact no nonconstraint prohibitions involving what can be
> > done within pure procedures. We cannot constrain against what Reinhold
> > wants to prohibit without crippling the use of pointers within pure
> > procedures.
>
> How about following improved edit:
>
> [312:30] After "any designator", add " with the POINTER attribute and a base object that is a dummy argument, as well as
> any designator "
>
> Cheers
> Reinhold
>
> >
> > Prohibiting this behavior other than by constraint would be a new thing.
> >
> > >
> > > Cheers,
> > > Bill
> > >
> > >
> > >
> > > >
> > > > I'm not convinced this is an undesirable side effect, but if it is, a
> > > > much more elaborate prohibition would be needed, to prevent a pointer
> > > > component of a dummy argument from appearing in a variable definition
> > > > context or as the data target in a pointer assignment statement.
> > > >
> > > >> Cheers
> > > >>
> > > >> Reinhold
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> _______________________________________________
> > > >> 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
More information about the J3
mailing list