[J3] Question on parent component naming

Tue Apr 9 17:44:17 UTC 2024

Hi Malcolm, 

> -----Ursprüngliche Nachricht-----
> Von: J3 <j3-bounces at mailman.j3-fortran.org> Im Auftrag von Malcolm
> Cohen via J3
> Gesendet: Dienstag, 9. April 2024 10:53
> An: 'General J3 interest list' <j3 at mailman.j3-fortran.org>
> Cc: Malcolm Cohen <malcolm at nag-j.co.jp>
> Betreff: Re: [J3] Question on parent component naming
> 
> Hi Reinhold,
> 
> Yes, I think an interp is probably in order. Use renaming is intended for name
> clash aversion, not for kludging parent component names.

Agreed, but the discussion is not about renaming parent components, 
but about determining what the parent component name is, once and for all, 
under the given circumstances.

> 
> If people really want to do renaming of the parent component, and there is a
> use case, I would think that we should support that directly rather than
> kludge it.
> 
> Not that I like that idea much either. The idea that *the same* ancestor
> component would have different names in different blocks of a SELECT TYPE,
> depending on how/where the extension was done, just seems like it would
> confuse people, not help them.

I agree that this is a bad idea, but this is orthogonal to the issue at hand.

Cheers, 
Reinhold

> 
> Cheers,
> --
> ..............Malcolm Cohen, NAG Oxford/Tokyo.
> 
> -----Original Message-----
> From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Bader,
> Reinhold via J3
> Sent: Tuesday, April 9, 2024 5:04 PM
> To: General J3 interest list <j3 at mailman.j3-fortran.org>
> Cc: Bader, Reinhold <Reinhold.Bader at lrz.de>; Malcolm Cohen
> <malcolm at nag-j.co.jp>
> Subject: Re: [J3] Question on parent component naming
> 
> OK, so John's citing of 14.2.2 is not relevant for component specs because all
> entities covered according to 14.2.2 para 2 are of class(1)?
> 
> Here is a variant of the program that, given Malcolm's view, should compile:
> 
> MODULE mod
>    TYPE :: t
>       REAL, POINTER :: p(:) => null()
>    END TYPE
> 
> END MODULE
> MODULE mod_ext
>    USE mod, my_t => t
> 
>    TYPE, EXTENDS(my_t) :: td
>      REAL :: data(3)
>    END TYPE
> END MODULE
> PROGRAM ref_parent
>    USE mod
>    USE mod_ext, ONLY : td
> 
>    TYPE(td), TARGET :: o_my_t
> 
>    o_my_t%t = t(o_my_t%data)
> 
>    o_my_t%data = [ 1., 2., 3. ]
> 
>    IF ( all(o_my_t%p == o_my_t%data) ) THEN
>       WRITE(*,*) 'OK'
>    ELSE
>       WRITE(*,*) 'FAIL'
>    END IF
> END PROGRAM
> 
> It would, however, be nice if the standard had some explicit statement
> (maybe in 9.4.2?) concerning the use of the type name as a class(1) versus a
> class(2) entity.
> Also, 7.5.7.2 para 2 should be more clearly worded.
> 
> Since there currently exists a portability issue, should this be an interp
> request?
> 
> Regards
> Reinhold
> 
> > -----Ursprüngliche Nachricht-----
> > Von: J3 <j3-bounces at mailman.j3-fortran.org> Im Auftrag von Malcolm
> > Cohen via J3
> > Gesendet: Dienstag, 9. April 2024 01:52
> > An: 'General J3 interest list' <j3 at mailman.j3-fortran.org>
> > Cc: Malcolm Cohen <malcolm at nag-j.co.jp>
> > Betreff: Re: [J3] Question on parent component naming
> >
> > Oops, I forgot to say that it is always the name of the type given in
> > the type definition that is used in other contexts where the name
> > matters,
> e.g.
> > in type equivalence.
> >
> > Cheers,
> > --
> > ..............Malcolm Cohen, NAG Oxford/Tokyo.
> >
> > -----Original Message-----
> > From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of John Reid
> > via J3
> > Sent: Tuesday, April 9, 2024 12:51 AM
> > To: General J3 interest list <j3 at mailman.j3-fortran.org>
> > Cc: John Reid <john.reid9 at talktalk.net>
> > Subject: Re: [J3] Question on parent component naming
> >
> > Reinhold,
> >
> > I believe that your program is standard-conforming. 14.2.2, para 7
> > says
> >
> > An accessible entity in the referenced module is associated with one
> > or more accessed entities, each with its own identifier. These
> > identifiers are
> >   . the identifier of the entity in the referenced module if that
> > identifier appears as an only-use-name or as the defined-operator of a
> > generic-spec in any only for that module, . each of the local-names or
> > local-defined- operators that the entity is given in any rename for
> > that module,  and . the identifier of the entity in the referenced
> > module if that identifier does not appear as a use-name or
> > use-defined-operator in any rename for that module.
> >
> > This is saying that rename really does renaming. The entity is known
> > by its new name and is not known by its original name. So your code
> > behaves like this code
> >
> > PROGRAM ref_parent
> >
> >
> >     TYPE :: my_t
> >
> >        REAL, POINTER :: p(:) => null()
> >
> >     END TYPE
> >
> >     TYPE, EXTENDS(my_t) :: td
> >
> >       REAL :: data(3)
> >
> >     END TYPE
> >
> >     TYPE(td), TARGET :: o_my_t
> >
> >     o_my_t%my_t = my_t(o_my_t%data)  ! (x)
> >
> >     ! o_my_t%t = my_t(o_my_t%data)       ! (y)
> >
> > END PROGRAM
> >
> > which looks good to me, but not if you replace (x) by (y).
> >
> > I think NOTE 1 in 7.5.7.1 is just doing what notes do - clarifying
> > what has already been defined normatively.
> >
> > Cheers,
> >
> > John.
> >
> >
> >
> >
> > Bader, Reinhold via J3 wrote:
> > >
> > > Dear J3,
> > >
> > > consider the following program:
> > >
> > > MODULE mod
> > >
> > >    TYPE :: t
> > >
> > >       REAL, POINTER :: p(:) => null()
> > >
> > >    END TYPE
> > >
> > > END MODULE
> > >
> > > PROGRAM ref_parent
> > >
> > >    USE mod, my_t => t
> > >
> > >    TYPE, EXTENDS(my_t) :: td
> > >
> > >      REAL :: data(3)
> > >
> > >    END TYPE
> > >
> > >    TYPE(td), TARGET :: o_my_t
> > >
> > >    o_my_t%my_t = my_t(o_my_t%data)  ! (x)
> > >
> > >    ! o_my_t%t = my_t(o_my_t%data)       ! (y)
> > >
> > > END PROGRAM
> > >
> > > Two compilers accept this code. Two other compilers tell me that
> > > my_t is not a parent component of o_my_t, at (x)
> > >
> > > One of those two others accepts the variant statement (y), the other
> > > one crashes when (y) is used.
> > >
> > > I tend to believe that the above is conforming, but this is based on
> > > non-normative evidence (NOTE 1 in 7.5.7.1 of 24-007).
> > >
> > > Any opinions?
> > >
> > > Regards
> > >
> > > Reinhold
> > >
> >
> 