[J3] Question on parent component naming

Tue Apr 9 10:42:06 UTC 2024

I agree that an interp is in order for this. I think the opinions on
both sides have some merit.

> 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

Agreed, although I tend to recommend against software designs that
require the use of SELECT TYPE. But I also think the name of the parent
component of child_type in the following example might be a bit
confusing to the casual reader.

MODULE m1
  TYPE :: my_type
  END TYPE
END MODULE

MODULE m2
  USE m1, ONLY: parent_type => my_type
END MODULE

MODULE m3
  USE m2, ONLY: parent_type
  TYPE, EXTENDS(parent_type) :: child_type
  END TYPE
END MODULE

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

I can think of two possible reasons that someone may want to be able to
rename derived types.

1. It may be more meaningful for a library to refer internally to a
type by one name, but make it "public" by a different name. It would
them be a bit surprising to a consumer of that library when they
extended such a type and the parent component had an unfamiliar name.
E.g. my example above. I don't have any "real world" example for this
though.

2. A derived type that had a component or type-bound procedure with the
same name as the type would otherwise be inextensible, but for
seemingly esoteric reasons. I.e.

MODULE m1
  TYPE :: inextensible
    integer :: inextensible
  END TYPE
END MODULE

MODULE m2
  USE m1, ONLY: extensible_now => inextensible
  TYPE, EXTENDS(extensible_now) :: child
  END TYPE
END MODULE

When and where would a compiler give an error message for something
like the above? But again, I don't believe I've ever seen a "real
world" example of this, and of course you could do the rename the
opposite direction to make the type inextensible under the new name.

Mostly just food for thought/discussion. I don't have a strong
preference one way or the other.

Regards,
Brad

On Tue, 2024-04-09 at 17:53 +0900, Malcolm Cohen via J3 wrote:
> 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.
> 
> 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.
> 
> 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
> > > 
> > 
> 
> 