12-148r2
To: J3
Subject: Editorial stuff and questions without edits
From: Malcolm Cohen
Date: 2012 June 25


1. Editorial changes to 12-007

[4.3 51:1+] Insert subclause heading "4.3.1 General" and renumber.
{ISO guidelines.}

[4.6p4 83:3] "the result of" -> "the same as".
{Expressions don't have results.}


2. Rejected suggestions.

Suggestion:
[7.1.2.3 134:4-5] Replace R703 by
R703  <defined-unary-op>  <<is>> <defined-op>
R703a <defined-op>        <<is>> . letter [ letter ] ... .
[7.1.2.3 134:6]
Within C703 replace "<defined-unary-op>" by "<defined-op>"
[7.1.2.8 136:17] Replace R723 by
R723  <defined-binary-op> <<is>> <defined-op>
[7.1.2.8 136:18-19] Delete C704.
R703  <defined-unary-op>  <<is>> <defined-op>
R703a <defined-op>        <<is>> . letter [ letter ] ... .
C703 (R703a) A <defined-op> shall not contain...,
R722 were defined as
R722  <defined-binary-op> <<is>> <defined-op>
and C704 were deleted.
This might in any case be a desirable editorial change, since it
eliminates one constraint (at the expense of adding a syntax rule).

Rejected because:
The complexity of the standard is unaffected by +1 rule -1 constraint.
The zero benefit is outweighed by the cost to ourselves and our
translators.

Suggestion:
[8.1.6.2 174:28] C607 says "<int-variable> shall be of type integer."  The
<scalar-> prefix and <-name> suffix in <scalar-int-variable-name> in R819
are assumed syntax rules.  Concerning assumed syntax rules, 1.4.3p1
[22:14-15] says "... and convey appropriate constraint information...."
Therefore C607 applies to R819.  Therefore C812 is redundant with C607.
Delete C812.

Rejected because:
The reasoning is faulty.  There is no set of productions that take
<scalar-int-variable-name> to <int-variable>; yes, the "scalar-" can be
stripped off, but the only implied rule for <int-variable-name> takes it to
<name>.

Suggestion:
[10.11.3.2p4 267:28-29] A discussion of namelist comments ought to be in
subclause 10.11.3.6 Namelist comments.  The essence of 10.11.3.2p4, except
for the part about namelist comments not being allowed after the slash that
terminates execution of the input statement, is already in that subclause.

Rejected because:
Not mentioning namelist comments in the "Namelist input" subclause would be
likely to lead to misreading the standard.  There is no problem with the
text as is.

Suggestion:
[A.2 461:50+] Since namelist output is only required to be consistent with
namelist input, and component names are optional in input, it is processor
dependent whether component names appear in namelist output.  [461:50]
specifies that "the results of namelist output" are processor dependent.
It is not obvious that this applies to more than the organization of output
items into records, and the format used for numeric items.  Since whether
component names appear in namelist output is not mentioned in 10.11.4, it
should be mentioned here.  Add a list item "o whether structure component
names appear in namelist output (10.11.4);"

Rejected because:
The current text says that "the results", which includes EVERYTHING that
could possible be processor dependent about "the results".  The suggestion
is therefore redundant and unnecessary.


3. Rejected technical suggestions

Suggestion:
Since a slash terminates execution of the input statement, it seems the
processor doesn't care what's after the slash, so why are [namelist]
comments prohibited?  This might have had something to do with namelist
stream input, but 10.11.3.6 prohibits comments in namelist stream input.
Delete 10.11.3.2p4.

Rejected because:
This is a TECHNICAL CHANGE.  We are not doing those yet.


4. Responses to Questions without edits

Background:
There are several places where "for example" appears embedded in
normative text:

  1.4.4p3, 1.4.4p4, 3.3.2.2p1, 5.5p2, 9.2.1p1 9.3.3.3p2--200:4
  9.3.3.4p3--200:20, 9.4p2--203:20, 10.7.2.3.7p2, 13.7.44p3--341:7,
  13.7.70p5--352:18, 13.7.136p5--380:28--380:33, 14.3p5, 14.3p6, 14.3p7.

Question:
Are any of these normative?

Response:
Yes, all of them.

Question:
Should at least some be in notes (or maybe deleted)?

Response:
Possibly, but the ones I looked at seemed fine as is.

Background:
I have a dim, perhaps incorrect, recollection that in some standard we
specified that nonnormative material appeared in boxes and with shaded
background (or some such description), but I can't find it in 10-007r1.

Question:
  Do we still say it?

Response:
No.

Question:
  Should we?

Response:
No.  The informative nature of NOTEs and EXAMPLEs is established as a
general principle by the ISO guidelines.

Question:
Should the "Example" paragraphs of the descriptions of intrinsic procedures
and procedures in intrinsic modules be specified to be nonnormative?

Response:
No.  These are close enough to how the ISO guidelines say we should present
examples that it is clear that they are informative.

Background:
[9.8.3p3 232:19-20] After a discussion of the effect of executing an
ENDFILE statement for a stream access file, the last sentence of the
paragraph says "Subsequent stream output statements may be used to write
further data to the file."

Question:
Does this mean before the terminal position of the file?

Response:
No, it means what it says - you may write *further* data to the file.
Compare and contrast with what p1 and p2 say for sequential files (i.e.
that there is an endfile record, and you shall not write further data
to the file without repositioning).

Question:
Does it change the terminal position of the file if data are written after
the previously-established terminal position?

Response:
Yes, this is well-specified by "File position after data transfer".

Question:
Can we handle this without an interp?

Reponse:
No interp seems to be necessary.

===END===