[J3] [SC22WG5.6386] RE: [ukfortran] WG5 Letter Ballot 2

Robert Corbett rpcorbett at att.net
Mon May 16 23:07:18 UTC 2022

 I am sorry, but I disagree with some of the points
raised in your responses to my negative vote on 
interpretation F18/019.

The text of the standard should be as clear as is
reasonably possible.  You have convinced me many
times that a clearer description of a particular
part of the standard is not reasonably possible.
The standard's description of lexical scoping is
one example.  In the case of the edit proposed
for F18/019, I believe a clearer description is
reasonably possible.

The proposed edit bans the use of entities of a
type that includes a default initialization of
a pointer component to a target in pure code.
You assert that there is no case where a
constructor of such a type can be used in pure
code.  Suppose T is the name of such a type with
a single pointer component.  The statement


does not appear to violate any of the
restrictions placed on pure code.

The code fragment

      ASSOCIATE (X => T())

might violate the new constraint proposed in the
edit.  The name X in the ASSOCIATE statement is
not a local identifier or the name of a construct
entity.  The scope of the associate name is the
block of the ASSOCIATE construct, which does not
include the ASSOCIATE statement.  A case could be
made that there is a construct entity that
violates the new constraint, even though its name
does not appear in the block, and so a diagnostic
message must be issued.  The edit does not make
it clear if the new constraint is violated in
this case.

In the comment I supplied with my ballot, I noted
that the explanation in F18/019 only requires the
new constraint for named variables and named
constants.  The text proposed in the edit also
bans procedure entities of a derived type that
includes a pointer component that is default
initialized to a target from appearing in pure
code.  Is that restriction intended?  The
application of the restriction is apt to be
confusing given the scoping rules for

    On Tuesday, May 10, 2022, 05:52:49 PM PDT, Malcolm Cohen via J3 <j3 at mailman.j3-fortran.org> wrote:  
Actually, you can’t write it to a character string without defined i/o, and that can’t be done because a pure procedure can’t have a dummy argument of that type. (And luckily, this means no additional edit will be needed for simple procedures.)


So I conclude that there would appear to be no circumstances where the structure constructor could be used anyway.


So unless I am very much mistaken, even with a misreading of the constraint, there would appear to be no change in what one can do.




..............Malcolm Cohen, NAG Oxford/Tokyo.


From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Malcolm Cohen via J3
Sent: Tuesday, May 10, 2022 12:20 PM
To: 'General J3 interest list' <j3 at mailman.j3-fortran.org>
Cc: Malcolm Cohen <malcolm at nag-j.co.jp>
Subject: Re: [J3] [SC22WG5.6386] RE: [ukfortran] WG5 Letter Ballot 2


So what are you going to do with this constructor? Assign it to a local variable? Oops, not allowed to have the local variable. Pass it as an argument? Not allowed either.


I suppose you could write it into a character string. Is this the hill we’re going to have the interp die on? I am struggling to imagine any other context where it could potentially be valid...


...and anyway, the existing text does not ban type names. Type REAL is not of type REAL or any other type, type CHARACTER is not of type CHARACTER or any other type, and type RANDOM_DERIVED_TYPE is not of any type either.


(There might be consequences for SIMPLE procedures here; we definitely need to ban the type name or have some constraint on structure constructors.)




..............Malcolm Cohen, NAG Oxford/Tokyo.


From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Robert Corbett via J3
Sent: Tuesday, May 10, 2022 11:53 AM
To: General J3 interest list <j3 at mailman.j3-fortran.org>
Cc: Robert Corbett <rpcorbett at att.net>
Subject: Re: [J3] [SC22WG5.6386] RE: [ukfortran] WG5 Letter Ballot 2


The text bans a named local entity or construct entity.  If type names are not banned, they can be used in constructors, which are not named entities.

Robert Corbett


On May 9, 2022, at 7:39 PM, Malcolm Cohen via J3 <j3 at mailman.j3-fortran.org> wrote:


A type name can name a local entity that might seem to be
subject to the new constraint.  However, I do not think that
a derived type is "of a type" (it is a type), and therefore,
is not subject to the constraint.  I find that to be a slender



A derived type name does not itself have a type, any more than the name of a module (that might contain type definitions that contain data components) has a type. In my opinion this is not a weak or slender reed.


> A named local or construct data entity


Apart from having ambiguous grammar, there is also no such thing as a “construct data entity”.


> be of a {declared} type


We never say “of a declared type”, as the “declared” part goes with the entity, not with the type.


Making such changes to the edit would change my vote to “N”.



Specifically, it might be read as banning
type names that name derived types that include default
initializations of pointer components to targets.



I disagree, but in any case, how exactly do you envisage such a type name being used unproblematically within a pure procedure (and without creating any local entity or construct entity of such a type)?




..............Malcolm Cohen, NAG Oxford/Tokyo.

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

More information about the J3 mailing list