[J3] type definitions

Malcolm Cohen malcolm at nag-j.co.jp
Fri Aug 12 00:36:53 UTC 2022

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.




..............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 <mailto: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 <mailto:j3 at mailman.j3-fortran.org> > wrote:

Is the program


        TYPE T
          REAL(KIND=KIND(X)) Y
        END TYPE T

standard conformant?

What about the program

        TYPE T
          REAL(KIND=KIND(X)) X
        END TYPE T


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!



Vipul Parekh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20220812/0a21a35a/attachment.htm>

More information about the J3 mailing list