[J3] type definitions

Malcolm Cohen malcolm at nag-j.co.jp
Mon Aug 15 02:12:27 UTC 2022


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:

1.	the variable appears first in the derived type definition, or
2.	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 <mailto: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 <mailto: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 <mailto:j3 at mailman.j3-fortran.org> >
Cc: Robert Corbett <rpcorbett at att.net <mailto: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

 

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


More information about the J3 mailing list