(j3.2006) WG23 Fortran Annex Draft

[Dan Nagle]

Hi,

Thanks.  I've incorporated (at least most of) your comments.
I'll post the new version in Tutorials.

On Jun 8, 2009, at 8:57 PM, Van Snyder wrote:

>
> 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.
>
>
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3

-- 
Cheers!

Dan Nagle