J3/13-277r1
To: J3
From: Malcolm Cohen
Subject: Editorial corrections/enhancements for F2015
Date: 2013 June 27


1. Introduction
---------------

This paper contains editorial corrections and enhancements for the next
revision of Fortran (anticipated to be Fortran 2015).

It also contains a technical correction, classified as editorial as no-one
has ever disputed the intent.


2. Discussion
-------------

(a) The Description paragraph for C_ASSOCIATED is nonsense that contradicts
    the Result Value paragraph.  It needs detoxification.

(c) It is not made clear that the internal representation must be the same
    for interoperability; this is particularly germane to C_BOOL.

(d) There is an ambiguous parse for a variable as an actual argument, since
    it also matches the syntax for an expression.  A constraint is added to
    remove the ambiguity.

(e) It is not clear that an associate-name is a variable, as this seems not
    to be said directly.  One might imagine that it is a special "entity"
    that is not a variable or expression or any of the other things that
    the standard gives names to, and therefore not subject to the rules
    that govern variables and so on.

(g) 4.5.6.2p2 is unclear, the second sentence is talking about the
    situation described in the first sentence, but can be read as applying
    more widely.

(h) The wording in 9.3.3.4 is inconsistent between p3 (unformatted streams)
    and p4 (formatted streams); p4 says "shall be read or written only by
    formatted stream access input/output", whereas p3 says "shall be read or
    written only by stream access input/output", i.e. the "unformatted" bit
    is missing.  Looking at the other access methods, none of them give the
    formatted/unformatted restriction - it is specified in 9.6.5.4.2 and
    9.6.5.4.3 (Unformatted and Formatted data transfer respectively).

    Therefore either we should insert "unformatted" (at 200:15), or delete
    both bullet points and state the requirement once.  The edits below
    suggest stating the requirement once.

(i) C917 is already covered by C916.

(j) 9.5.1p2s3 requires that a <file-unit-number> be nonnegative, equal to
    INPUT_UNIT et al, or a NEWUNIT value; this means that child data
    transfer statements for internal files don't work, since the unit
    number will be negative.  s3 should permit this case.  s4 talks about
    the possibility but cannot (and does not even attempt to) override the
    requirement that is stated clearly in s3.


3. Edits to 10-007r1
--------------------

[76:6-7] 4.5.6.2p2s2, change "A final ... been finalized." to
  "During this process, execution of a final subroutine for one of these
   entities shall not reference or define any of the other entities that
   have already been finalized."
{Clarify intent of requirement.}

[171:12] 8.1.3.3p2, prepend new sentence
  "The associating entity itself is a variable, but if the selector is not
   a definable variable, the associating entity is not definable and shall
   not be defined or become undefined."
{Clarify that associate-names are variable-names; also clarify
 definability, though this can be proved via the association rules.}

[200:13] 9.3.3.4p2, append
  "While connected for stream access, the file storage units of the file
   shall be read or written only by stream access input/output statements."
{State this requirement once.}

[200:15] 9.3.3.4p3, first bullet, delete.
{Now redundant.}

[200:30-31] 9.3.3.4p4, fourth bullet, delete.
{Now redundant.}

[204:8,10] 9.5.1p2, before "or a NEWUNIT"
           insert "the \cf{unit} argument of an active defined input/output
                   procedure (9.6.4.8)",
           Delete existing " (9.6.4.8)".

[213:3] 9.6.2.1, C917, Delete entire constraint C917.
{Already redundant with C916.}

[290:20+] 12.5.1p4, after C1235, insert
  "C1235a (R1223) <expr> shall not be a variable."
{Disambiguate parse.}

[425:19+] 15.2.2p1+, insert new paragraph
  "A Fortran intrinsic type whose kind type parameter is one of the values
   in the module shall have the same representation as the C type with
   which it interoperates, for each value that a variable of that type can
   have.  For C_BOOL, the internal representation of .TRUE._C_BOOL and
   .FALSE._C_BOOL shall be the same as those of the the C values
   (_Bool)true and (_Bool)false respectively.".
{Clarify the internal representation requirements.}

[426:17-18] 15.2.3.2p1, replace whole sentence "True ... entity." with
            "Query C pointer status."
{Replace nonsense with platitudes.}

===END===