[J3] Question on parent component naming

[John Reid]

Reinhold,

Let's go into private mode. I don't like arguing in public, specially 
with Malcolm.

Malcolm said "Renaming does not change the name of the components. It 
just adds a local name for the remote name." This is not relevant. The 
only component accessed in your original example is p. In any case, the 
standard is already clear -- 14.2.2 para 2 says "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."

I just do not see any need for an interp. (but there is a bug in the Nag 
compiler, IMHO).

Or is it that your original example does not illustrate the problem that 
you see?

Cheers,

John.



Bader, Reinhold via J3 wrote:
> 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
>>>