[J3] type definitions

Robert Corbett rpcorbett at att.net
Mon Aug 15 06:34:48 UTC 2022


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/2e6d8648/attachment-0001.htm>


More information about the J3 mailing list