[J3] type definitions

Mon Aug 15 07:26:50 UTC 2022

Hi Robert,

>I take it you think my two examples are not standard conforming.

That is not what I wrote. I wrote that it is *not clear* that they are valid, but that they do not break any explicit requirement. I also wrote that they are functionally completely useless, which is a good reason for not getting too excited over whether they should be valid or invalid.

I would have to give this a lot more thought to arrive at a conclusion on those examples.

> The first sentence of paragraph 3 of subclause 8.7 states

> 

>In each scoping unit, there is a mapping, which may be null,

8.7p3 may indeed state incorrectly. And we already know that it does – it does not establish what the mapping is.

The fact remains that there is no non-host-associated named variable in the scoping unit of a derived type definition. A host-associated variable that is implicitly typed is being typed in the host, not in the derived type definition.

Implicit typing thus *must be* completely defunct in derived type definitions. Host variables must be typed in the host, not in a contained scoping unit. We do not have implicitly typing for derived type parameters, nor for components.

Is there an implicit mapping? Who knows – if a tree that doesn’t exist falls in the forest, does it make a sound? Seriously, there are no entities inside the definition that are implicitly typed, so how could anyone tell.

I definitely agree that 8.7 is defective. On the face of it, this defect does not appear to validate or invalidate any possible program though…

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 3:35 PM
To: General J3 interest list <j3 at mailman.j3-fortran.org>
Cc: Robert Corbett <rpcorbett at att.net>
Subject: Re: [J3] type definitions

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 <mailto: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:

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 <mailto: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 <mailto:j3 at mailman.j3-fortran.org> >
Cc: Robert Corbett <rpcorbett at att.net <mailto: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 < <mailto:j3 at mailman.j3-fortran.org> 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 < <mailto:j3-bounces at mailman.j3-fortran.org> 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 < <mailto:j3 at mailman.j3-fortran.org> j3 at mailman.j3-fortran.org>
Cc: Robert Corbett < <mailto:rpcorbett at att.net> 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 < <mailto:j3 at mailman.j3-fortran.org> j3 at mailman.j3-fortran.org> wrote: 

On Wed, Aug 10, 2022 at 6:28 PM Robert Corbett via J3 < <mailto:j3 at mailman.j3-fortran.org> 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/740b4c26/attachment-0001.htm>