[J3] Question on parent component naming

[Bader, Reinhold]

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
> >
>