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

Tue May 17 00:18:59 UTC 2022

Hi Robert,

Editorial improvements are always welcome for the next revision. They should not derail technical fixes in a corrigendum.

> In the case of the edit proposed for F18/019, I believe a clearer description is
reasonably possible.

I do not agree that you have demonstrated that a clearer description is possible, let alone sufficiently obvious within the time available for wordsmithing. The description in the interp is in my opinion clear and unambiguous.

> You assert that there is no case where a
constructor of such a type can be used in pure
code. 

You must be reading a different message. I *concluded*, after earlier having thought there was some potential usage, that the cases I thought up were invalid.

> ISIZE = STORAGE_SIZE(T())

Fair enough. Pretty useless, but I agree it does not violate the constraints and requirements *before or after* the interpretation in question. And it seems to be non-problematic, which means we don’t have to worry about prohibiting it.

<<< 

The code fragment

      ASSOCIATE (X => T())
        CONTINUE
      END ASSOCIATE

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.

>>> 

Yes, it does violate the new constraint because the name X *is the name of a construct entity*.

“The ASSOCIATE construct associates named entities with expressions or variables during the execution of its block. These named construct entities (19.4)...”

<<< 

I noted
that the explanation in F18/019 only requires the
new constraint for named variables and named
constants. 

>>> 

Yes, but...

<<< 

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. 

>>> 

Good. That is required, otherwise the result of the function (which is required to be pure) is initialised to point to global data, and we already explained that this was a problem – the result being a named variable.

Cheers,

-- 

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

From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Robert Corbett via J3
Sent: Tuesday, May 17, 2022 8:07 AM
To: Malcolm Cohen via J3 <j3 at mailman.j3-fortran.org>
Cc: Robert Corbett <rpcorbett at att.net>
Subject: Re: [J3] [SC22WG5.6386] RE: [ukfortran] WG5 Letter Ballot 2

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

      ISIZE = STORAGE_SIZE(T())

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

The code fragment

      ASSOCIATE (X => T())
        CONTINUE
      END ASSOCIATE

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
procedures.

On Tuesday, May 10, 2022, 05:52:49 PM PDT, Malcolm Cohen via J3 <j3 at mailman.j3-fortran.org <mailto: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.

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 Malcolm Cohen via J3
Sent: Tuesday, May 10, 2022 12:20 PM
To: 'General J3 interest list' <j3 at mailman.j3-fortran.org <mailto:j3 at mailman.j3-fortran.org> >
Cc: Malcolm Cohen <malcolm at nag-j.co.jp <mailto: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.)

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: Tuesday, May 10, 2022 11:53 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] [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 <mailto: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
reed. 

>>> 

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)?

Cheers,

-- 

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20220517/4cb7d261/attachment-0001.htm>