(j3.2006) WG23 Fortran Annex Draft

[Van Snyder]

On Mon, 2009-06-08 at 13:20 -0700, Dan Nagle wrote:
> Hello,
> 
> I have put Fortran_Annex.txt in the Tutorials folder
> in the members area on the server.  I will forward it to the WG23  
> Editor,
> hopefully, this week.  I would appreciate any comments anyone
> has the time to make.

In general, unless WG23 is using a different ISO dictionary, "may"
should be "might".  "May" gives permission; "might" indicates more than
one possibility.

The second paragraph of General Terminology should state that a
processor is required to report errors that can be detected by reference
to the numbered syntax rules **and constraints**.

The third paragraph of 3.1.4 recommends that the entire definition of a
common block should be in one statement.  It's more likely possible now
that 99 lines of 255 characters each are allowed for a single statement,
but it's not guaranteed to be possible, which is why multiple statements
are allowed.  Perhaps add "If multiple statements are used to declare a
single common block, they should be contiguous, or perhaps separated
only by comments."

3.2.5 is the only 3.x.5 with "None."  Most are simply empty.

3.5.2 needs "might" after "therefore".

I consider 3.10.4 and 3.10.5 to be bad advice.

The first paragraph of 3.11.2 needs "numeric" before the first "type".
It wouldn't hurt to separate real and complex from integer, and explain
larger WHAT? in both cases.

In the second paragraph of 3.11.2, "name" should be "designator" to
cover the case of array elements, components, or complex parts.

The second paragraph of 3.11.5 and 3.15.5 aren't necessary, unless there
are processors that can't represent 1.0/epsilon(1.0) - 1 as an integer.

3.13.5 invites an annoyance that would be more likely to provide enough
clutter to obscure something important than to provide a useful warning
of a problem.  An option to ask for it might be useful, but requiring it
is not helpful.

Add "Fortran uses the term <rank> for the number of dimensions of an
array." as a first sentence of 3.17.1.

"Indexes are undefined outside the bounds" should be "Using subscripts
with values outside the bounds is prohibited" in 3.17.1.  Is it
necessary to add "An index is called a subscript in Fortran"?

Add ", automatic, or fixed shape" after "allocatable" in 3.17.4, 3.18.4,
3.19.4, 3.20.4.

Add "Consider adding a requirement to provide an option to check that
subscripts are within bounds."

3.24.4 does not address the question of "Dangling reference to heap" as
I understand it.  I understand the title to mean using a pointer to try
to reference something that has been deallocated using a different
pointer.  Strategies to avoid the vulnerability might be

"Avoid associating more than one pointer with an object.
Avoid associating a pointer with an allocatable object.
Always allocate and deallocate using the same pointer if more than one
can be associated with an object.
"

3.26.1 is incorrect.  Allocatable variables and dummy arguments can be
polymorphic.

Add ", not that the variable is initialized whenever the scope in which
it is declared is entered" at the end of 3.27.1.

The implications of "changing the storage class" in 3.27.5 are obscure
and indirect.  "Fortran might consider a way to supply an initial value
for a variable every time the scope in which it is declared is entered."

Delete "an" before "problematic" in 3.31.1.

Replace "when" by "if" in 3.31.4.

Add a paragraph "Prefer to use pure functions" in 3.31.4.

3.35.5.  Fortran already has deprecated the nonblock form of the DO.

Insert "explicit interface and" before "argument intents" in 3.36.5.

Add "Use interface bodies to describe external procedures" to 3.41.4.

Add "Do not cause storage association of objects of different type by
using common or equivalence" to 3.46.4.

Add "or automatic" after "allocatable" in 3.47.4.

3.51.1 is not quite correct.  Fortran provides alternate returns instead
of block-structured exceptions.