[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