(j3.2006) implicit none ordering
Thu Nov 12 08:52:51 EST 2015
On Nov 12, 2015, at 1:23 AM, Cohen Malcolm <malcolm at nag-j.co.jp> wrote:
> We have a constraint
> ? C590 (R563) If IMPLICIT NONE is specified in a scoping unit, it shall
> precede any PARAMETER statements that appear in the scoping unit. No more
> than one IMPLICIT NONE statement shall appear in a scoping unit.
> Which leads to comparison with Table 2.1 in 2.3.2 Statement ordering (page
> 33 in 15-007r2).
> Is the IMPLICIT NONE in C590 and in Table 2.1 only the version where there
> is no <implicit-none-spec>?
> No, they are both "the IMPLICIT NONE statement".
> Maybe C590 could be reworded "If the IMPLICIT NONE statement appears in a
> scoping unit, ?".
Or, ?If an IMPLICIT NONE??. I think this would be an improvement. I clarifies that all the variants are included.
> For example, is this allowed:
> PARAMETER (x = 1.23)
> IMPLICIT NONE (EXTERNAL)
> I do not think we should allow this.
Agreed. That would be clearly disallowed with the wording change to C590.
> 1) Could the right middle box in Table 2.1 (Derived-type definitions ? and
> statement function statements) be shortened by replacing some of the
> current entries with ?specification constructs??
> Something should be done, not just here but also elsewhere, as we have
> deleted the syntax term "specification statement" so there is no unambiguous
> definition of it.
> 2) Is the table correct, since executable constructs include BLOCK
> constructs, which can contain specification statements?
> That bit seems ok, if a bit overly simplified. I don't see any obvious way
> to improve it.
It?s a basic problem that BLOCK constructs don?t fit with the current format of the table. Type declaration statements in a BLOCK construct textually follow executable constructs that come before the BLOCK construct in the code. Basically, a subset of the statement ordering rules starts over while in the block construct. I vaguely recall this came up before ( it?s a F2008 issue) and we decided to punt. Certainly an option here as well. Maybe a sentence outside the boxes something like ?If specification constructs are allowed within an executable construct, the relative ordering of the statements within that construct are as specified in the table.? That?s already in the BLOCK construct syntax rules, but at least it would indicate that we didn?t ignore that case in the table.
> I hope people are not getting too early a start on reading for February,
> since there will be a new 007 for that, which will contain lots of extra
> typos and mistakes in any bits you have already read!
Actually, I?m starting the task of writing bugs for the new features that we don?t already implement. This topic arose when starting to write the rules for IMPLICIT NONE with the new specs. Attention to specifics is sharpened when you try to write out detailed implementation rules for the compiler developers.
The text happens to be in the part of the draft I?m supposed to be reading for February, but that is only a coincidence.
> ........................Malcolm Cohen, Nihon NAG, Tokyo.
> J3 mailing list
> J3 at mailman.j3-fortran.org
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101
More information about the J3