[J3] Question on parent component naming
Bader, Reinhold
Reinhold.Bader at lrz.de
Thu Apr 11 12:36:01 UTC 2024
Hi Malcolm, J3 /interp,
attached an interp draft. Since the discussion veered to "parent component renaming" at some point,
let me note that the issue is about "parent component naming", under specific circumstances.
Maybe there was only a misunderstanding, in which case it might be possible to get this issue resolved without
/interp involvement at the next meeting.
Cheers,
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 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.
>
> 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
> > >
> >
>
-------------- next part --------------
To: J3 J3/##-###
From: Reinhold Bader & John Reid
Subject: Interp on parent component naming
Date: 2024-Apr-11
References: 24-007
Example
~~~~~~~
Consider the following program:
MODULE mod
TYPE :: t
REAL :: scalar = 4.
END TYPE
END MODULE
PROGRAM ref_parent
USE mod, my_t => t
TYPE, EXTENDS(my_t) :: td
REAL :: data(3) = [ 1., 2., 3. ]
END TYPE
TYPE(td) :: my_object
TYPE(my_t) :: my_t_object
! write(*,*) my_t_object, my_object%t ! (x)
write(*,*) my_t_object, my_object%my_t ! (y)
END PROGRAM
Observations
~~~~~~~~~~~~
Some compilers build the above program as given. Others complain
that "my_t is not a component of my_object"; they only compile
an alternative version in which statement (y) is replaced by
statement (x).
Questions
~~~~~~~~~
(Q1) What is the name of the parent component of "my_object" in
the main program?
(Q2) Does the program as given above conform to the standard?
Answers
~~~~~~~
(A1) The name of the parent component is "my_t".
Reason: 24-007, 7.5.7.2 para 2 has
"An extended type has a scalar, nonpointer, nonallocatable,
parent component with the type and type parameters of the
parent type. The name of this component is the parent type name."
The parent type name has been locally established by renaming
(see also 7.5.7.1 NOTE 1), as specified in 24-007, 14.2.2 para 2:
"The USE statement provides the means by which a scoping unit
accesses named data objects, nonintrinsic types, procedures,
abstract interfaces, generic identifiers, and namelist groups in
a module.", in combination with 14.2.2 para 7, specifically
second bullet:
" An accessible entity in the referenced module is associated
with one or more accessed entities, each with its own
identifier. These identifiers are
* [elided]
* each of the local-names or local-defined-operators that the
entity is given in any rename for that module, ..."
(A2) Yes.
Suggested edits to 24-007, and author's comments
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
No edits to the normative text are needed.
We believe that edits to the standard would be needed in case J3/interp
comes to the conclusion that statement (x) is the correct one in the
example program.
SUBMITTED BY: Reinhold Bader and John Reid
HISTORY: 24-nnn m233 Submitted
More information about the J3
mailing list