[J3] type definitions

Mon Aug 15 06:45:52 UTC 2022

The first sentence of paragraph 3 of subclause 8.7 states

In each scoping unit, there is a mapping, which may be null, between each of the letters A, B, ..., Z and a type (and type parameters).  Are you saying that that sentence is in error for scoping units that are derived type definitions?

Robert Corbett

> On Aug 14, 2022, at 11:34 PM, Robert Corbett <rpcorbett at att.net> wrote:
> 
> I take it you think my two examples are not standard conforming.
> 
> The first sentence of paragraph 3 of subclause 8.7 states
> 
> In each scoping unit, there is a mapping, which may be null,
> 
>>> On Aug 14, 2022, at 7:12 PM, Malcolm Cohen via J3 <j3 at mailman.j3-fortran.org> wrote:
>>> 
>> 
>> Hi Robert,
>>  
>> There is no default mapping for derived type definitions.
>> There has never been a default mapping specified in the standard for derived type definitions.
>>  
>> That is because there is no entity in the scope of a derived type definition that is implicitly typed in that definition.
>>  
>> A named variable (which is what we are talking about) that appears in a derived type definition, must be being accessed there by host association: that is, its “inclusive scope” must be the host of the derived type definition. If the scope rules do not say that clearly enough (and I must admit that a quick look didn’t turn up anything helpful), then they need to be fixed.
>>  
>> If the variable name appears in the host scoping unit before the derived type definition, this is already clear. So what we have here is one of two things:
>> the variable appears first in the derived type definition, or
>> the variable appears only in (one or more) derived type definitions.
>>  
>> Assuming that these are valid situations, they are both completely useless functionality, as such a variable is only being used in an intrinsic inquiry function reference.
>>  
>> (And when I look at old standards, it is not even clear that these situations are valid. But there is no explicit requirement for a variable being accessed by host association from a derived type definition to be declared prior to the definition. Perhaps there should be? In which case, those examples would be invalid.)
>>  
>> Cheers,
>> --
>> ..............Malcolm Cohen, NAG Oxford/Tokyo.
>>  
>> From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Robert Corbett via J3
>> Sent: Monday, August 15, 2022 8:13 AM
>> To: Malcolm Cohen via J3 <j3 at mailman.j3-fortran.org>
>> Cc: Robert Corbett <rpcorbett at att.net>
>> Subject: Re: [J3] type definitions
>>  
>>  
>> I do not think that the scope rules
>> specify the default IMPLICIT mapping
>> for derived type definitions.
>> Paragraph 3 of subclause 8.7
>> specifies how to determine the
>> default mapping for program units,
>> interface blocks, BLOCK constructs,
>> internal subprograms, and module
>> subprograms.  I think that would
>> be a good place to specify how to
>> determine the default mapping for
>> type definitions.
>>  
>> Robert Corbett
>> On Thursday, August 11, 2022 at 05:37:52 PM PDT, Malcolm Cohen via J3 <j3 at mailman.j3-fortran.org> wrote:
>>  
>>  
>> Hi Robert,
>> 
>>  
>> 
>> Country comments from both the US and UK on draft Fortran 2018 complained that those words were wrong, confusing, and unnecessary. So we deleted them.
>> 
>>  
>> 
>> The scoping rules are not defined by the IMPLICIT statement. All the IMPLICIT statement does is say what the type and type parameters are. That is all it should say.
>> 
>>  
>> 
>> Attempting (and failing btw) to duplicate the scoping rules in the middle of the IMPLICIT statement subclause is not a good idea.
>> 
>>  
>> 
>> <<<  
>> 
>> In the 2023 draft, rules for determining the
>> default implicit mapping do not cover the
>> case of type definitions.
>> 
>> >>>  
>> 
>>  
>> 
>> That would be because the scope of X is not the type definition.
>> 
>>  
>> 
>> And it is not the 2023 draft: this was paper 17-232 applied to the Fortran 2018 draft.
>> 
>>  
>> 
>> If the scoping rules are not sufficiently clear, it is the scoping rules that deserve improvement. Under no circumstances should we consider reintroducing scoping rules to the IMPLICIT statement subclause.
>> 
>>  
>> 
>> I can well believe that the scoping rules deserve attention; this is a fundamental, and difficult topic, and we changed how they worked (not just how they were described) in F2008 and again in F2018.
>> 
>>  
>> 
>> But this is not a simple case of the editor forgetting to make an edit.
>> 
>>  
>> 
>> Cheers,
>> 
>> --
>> 
>> ..............Malcolm Cohen, NAG Oxford/Tokyo.
>> 
>>  
>> 
>> From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Robert Corbett via J3
>> Sent: Friday, August 12, 2022 5:55 AM
>> To: General J3 interest list <j3 at mailman.j3-fortran.org>
>> Cc: Robert Corbett <rpcorbett at att.net>
>> Subject: Re: [J3] type definitions
>> 
>>  
>> 
>>  
>> 
>> After applying Corrigendum 1 to the Fortran 2008
>> standard, paragraph 4 of subclause 5.5 reads
>> 
>>   Any data entity that is not explicitly
>>   declared by a type declaration, is not
>>   an intrinsic function,is not a component,
>>   and is not accessed by use or host
>>   association is declared implicitly to be
>>   of the type (and type parameters) mapped
>>   from the first letter of its name,
>>   provided the mapping is not null.  The
>>   mapping for the first letter of the data
>>   entity shall either have been established
>>   by a prior IMPLICIT statement or be the
>>   default mapping for the letter.  The data
>>   entity is treated as if it were declared
>>   in an explicit type declaration; if the
>>   outermost inclusive scope in which it
>>   appears is not a type definition, it is
>>   declared in that scope, otherwise, it is
>>   declared in the host of that scope.  An
>>   explicit type specification in a
>>   FUNCTION statement overrides an IMPLICIT
>>   statement for the name of the result
>>   variable of that function subprogram.
>> 
>> That paragraph corresponds to paragraph 4 of
>> subclause 8.7 of the 2023 draft.  In the
>> Fortran 2018 standard and the 2023 draft,
>> the parts of the text dealing with type
>> definitions have been elided.  Without that
>> text, my first example would seem not to be
>> standard conforming.
>> 
>> In the 2023 draft, rules for determining the
>> default implicit mapping do not cover the
>> case of type definitions.  That too would
>> cause my first example to be nonconforming,
>> because it would not have an interpretation.
>> 
>> Robert Corbett
>> 
>>  
>> 
>> On Wednesday, August 10, 2022 at 07:52:03 PM PDT, Vipul Parekh via J3 <j3 at mailman.j3-fortran.org> wrote:
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> On Wed, Aug 10, 2022 at 6:28 PM Robert Corbett via J3 <j3 at mailman.j3-fortran.org> wrote:
>> 
>> Is the program
>> 
>>  
>> 
>>       PROGRAM MAIN
>>         TYPE T
>>           REAL(KIND=KIND(X)) Y
>>         END TYPE T
>>       END
>> 
>> standard conformant?
>> 
>> What about the program
>> 
>>       PROGRAM MAIN
>>         DOUBLE PRECISION X
>>         TYPE T
>>           REAL(KIND=KIND(X)) X
>>         END TYPE T
>>       END
>> 
>>  
>> 
>> Hi Bob,
>> 
>>  
>> 
>> For whatever it's worth, I think both the programs conform for I am unable to place any text in the standard that would indicate to me these two programs do not conform.  Besides, two processors I tried did not detect any nonconformance.
>> 
>>  
>> 
>> Whenever you're ready, you can post the text you think is missing!
>> 
>>  
>> 
>> Regards,
>> 
>> Vipul Parekh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20220814/67e0fb9a/attachment-0001.htm>