(j3.2006) [ukfortran] WG5 letter ballot on draft Corrigendum 3
John Reid
John.Reid
Thu Dec 12 09:47:59 EST 2013
Malcolm,
Thanks very much for your careful explanations.
>> I have been struggling for a couple hours to decide whether to support
>> Malcolm's recent replacement for interp f08/0086. I have decided that I cannot
>> for the following reasons:
>
> Instead of struggling and then voting no, why not ask questions? My reply to
> innocent questions is usually more polite than my reply to bogus reasons for
> voting no!
I am willing to be persuaded to change my vote.
>> 1. The new edit for 96:24-25 begins "Replace sentence" rather than "Replace
>> sentences". This restores the sentence "An implied-shape array is a named
>> constant that takes its shape from the constant-expr in its declaration." While
>> I agree with this change, if we are to approve the revised f08/0086 as part of
>> this ballot, the wording needs to be altered so that it does not depend on the
>> difference between "sentence" and "sentences".
>
> I took the wording directly from the interp. It has "Replace sentence.".
> Copy-paste made no change to that!
>
> David changed "sentence"->"sentences" in the draft corrigendum claiming that
> this was an error in N1987. It is certainly true that mjc002.txt, like N1987
> and 13-007Ar1 and 13-007Ar2 and 13-007Ar3, has this edit poorly worded; but the
> wording is not in fact ambiguous. If we had meant to replace the entire
> paragraph (which is the effect of David's modification), we would likely have
> written "replace entire paragraph 1" not "replace sentence".
>
> Improving this wording to avoid possible misreading would be a trivial editorial
> matter.
>
> As it happens, the first sentence of paragraph 1 that this is so exercised about
> is introductory waffle. It makes no difference whatsoever as to whether it
> stays or goes, because the precise semantics are precisely specified in
> paragraphs 2 and 3. (Which is another strike against this being a meaningful
> change!) Apart from a microscopic preference for sticking with the actual
> passed edit (i.e. "sentence") just for the sake of sticking with the actual
> passed edit, I do not care even a little bit whether that sentence stays or
> goes.
>
> I apologise for accidentally correcting this, by copying the edit in the *actual
> interp* as passed by WG5.
We are in agreement here. I would like to keep the sentence. How about
adding a bit more of the old sentence to remove any possible confusion?
>> 2. The sentence at 96:28 is wrong for an implied-shape array that is declared
>> with an asterisk. Separate wording is needed for the two cases.
>
> No it is absolutely correct. A rank-one implied-shape array is declared with an
> <implied-shape-or-assumed-size-spec>
> which contains precisely one
> <assumed-implied-spec>
>
> I.e., in "REAL x(*)" we have activated the BNF (omitting the optional syntax
> terms that are omitted in this example):
>
> <type-declaration-stmt> ::= <declaration-type-spec> <entity-decl-list>
> <entity-decl-list> ::= <entity-decl>
> <entity-decl> ::= <object-name> ( <array-spec> )
> <array-spec> ::= <implied-shape-or-assumed-size-spec>
> <implied-shape-or-assumed-size-spec> :: = <assumed-implied-spec>
> <assumed-implied-spec> ::= *
>
> where the last three productions come from
>
> [94:10+] Insert new production
> "<<or>> <implied-shape-or-assumed-size-spec>".
> {This will be the otherwise-ambiguous syntax.}
>
> and
>
> [95:37+] Insert new BNF rules and constraint
> "R521a <implied-shape-or-assumed-size-spec> <<is>>
> <assumed-implied-spec>
>
> and
>
> [95:33-] Insert new BNF term
> "R520a <assumed-implied-spec> <<is>> [ <lower-bound> : ] *"
OK, but I think a bigger change needs to be made to 96:28. Here is my
suggestion:
[96:28] p2, replace the line by "The rank of an implied-shape array
is the number of <assumed-implied-spec>s in the
<implied-shape-or-assumed-size-spec> or <implied-shape-spec>."
>> 3. I think the new right-hand side of R522 should be
>> "<assumed-implied-spec-list>"
>> to avoid forcing the rank to be at least 2.
>
> Already answered in my reply to Van Snyder. You did notice he made the same
> mistake you did, right? And that I pointed out it was already covered by the
> immediately preceding edit which was already in the interp...
>
> As in point 2, a rank-one implied-shape array is declared with an
> <implied-shape-or-assumed-size-spec>
> it is only rank>1 which is declared with R522. As the immediately-preceding
> edit says.
>
> ***This was the whole point of the interp to split the rank-one case away from
> rank>1 because the rank==1 case was ambiguous with respect to assumed-size
> arrays.***
>
> Here is the edit that I am referring to:
> [96:24-25] 5.3.8.6p1
> Replace sentence
> "An implied-shape array ... <implied-shape-spec-list>."
> with
> "A named constant is declared to be an implied-shape array by an
> <implied-shape-or-assumed-size-spec> or an <implied-shape-spec>."
> {Now two ways of declaring implied shape.}
Agreed.
>> 4. In the edit for 95:33-, "<implied-assumed-spec>" should be
>> "<assumed-implied-spec>" (already noted by Malcolm).
>
> Yes, I already thanked Van for spotting this typo.
Agreed.
So I would like to suggest three changes to your draft. I attached a new
version that includes these changes. Are these OK? If so, I would be
pleased to change my vote.
Best wishes,
John.
-------------- next part --------------
----------------------------------------------------------------------
NUMBER: F08/0086
TITLE: Implied-shape and separate PARAMETER statement
KEYWORDS: Implied-shape, PARAMETER
DEFECT TYPE: Erratum
STATUS: Unknown
QUESTION:
Q1. Consider
Program test1
Character(*) a,b(*)
Dimension c(*)
Parameter (a='123', b=['1','2','3'])
Character(*),Parameter :: c = [ '44','55','66' ]
Print *,a,b,c
End
The definition of the assumed-length character named constant A
conforms to Fortran 77 to Fortran 2008. However, the definition of
the implied-shape named constant B appears not to conform to Fortran
2008, as the standard says in 5.4.11p2
"A named array constant defined by a PARAMETER statement shall have
its shape specified in a prior specification statement."
On the other hand, the named constant C does not have such a
requirement, so its definition would appear to be conforming.
This apparent requirement on the named constant B would thus appear to
be inconsistent with those on the named constant C, as well as
inconsistent with the way that assumed length works, and with the
general principle of allowing attributes to be specified either in a
single type declaration statement or with separate specification
statements.
Is the program intended to conform to the Fortran standard?
Q2. Consider
Subroutine test2(a)
Real,Dimension(*) :: a,c
Parameter (c = [ 45.6 ])
a(:size(c)) = c
End Subroutine
The <array-spec> in the type declaration statement is ambiguous; if it
is an <implied-shape-spec> then the declaration of A as an
assumed-size array is erroneous, but if it is an <assumed-size-spec>
then the declaration of C as an implied-shape array is erroneous.
Is this program-unit intended to be standard-conforming?
ANSWER:
A1. Yes, the program was intended to conform to the Fortran standard.
An edit is provided to modify the requirement for prior
specification so as to allow this case.
A2. Yes, the program is intended to conform to the Fortran standard.
An edit is provided to add syntax to permit this unambiguously.
EDITS to 10-007r1:
[94:10] 5.3.8.1, R515,
Change "<implied-shape-spec-list>" to "<implied-shape-spec>".
{This will be the unambiguous implied-shape syntax.}
[94:10+] Insert new production
"<<or>> <implied-shape-or-assumed-size-spec>".
{This will be the otherwise-ambiguous syntax.}
[95:32] 5.3.8.5p1
Replace sentence
"An assumed-size array is declared with an <assumed-size-spec>."
with
"A dummy argument is declared to be an assumed-size array by an
<assumed-size-spec> or an <implied-shape-or-assumed-size-spec>."
{Now two ways of declaring assumed size.}
[95:33-] Insert new BNF term
"R520a <assumed-implied-spec> <<is>> [ <lower-bound> : ] *"
[95:33] R521 <assumed-size-spec>, after "<<is>>"
Replace entire RHS
"[ <explicit-shape-spec>, ]... [ <lower-bound> : ] *"
with
"<explicit-shape-spec-list>, <assumed-implied-spec>"
{The unambiguous case has a list of <explicit-shape-spec>s.}
[95:37+] Insert new BNF rules and constraint
"R521a <implied-shape-or-assumed-size-spec> <<is>>
<assumed-implied-spec>
C534a An object whose array bounds are specified by an
<implied-shape-or-assumed-size-spec> shall be a dummy data
object or a named constant."
{The otherwise-ambiguous case. Note careful wording.}
[96:24-25] 5.3.8.6p1
Replace sentence
"An implied-shape array is declared ... <implied-shape-spec-list>."
with
"A named constant is declared to be an implied-shape array by an
<implied-shape-or-assumed-size-spec> or an <implied-shape-spec>."
{Now two ways of declaring implied shape.}
[96:26] R522,
Replace right-hand-side (after "<<is>>")
"[ <lower-bound> : ] *"
with
"<assumed-implied-spec>, <assumed-implied-spec-list>".
{This is now the unambiguously implied-shape spec.}
[96:28] p2, replace the line by "The rank of an implied-shape array
is the number of <assumed-implied-spec>s in the
<implied-shape-or-assumed-size-spec> or <implied-shape-spec>."
{Change rank determination to accord with new syntax terms.}
[107:11] 5.4.11p1 "shape" -> "rank".
{In the PARAMETER statement, only require the rank to be specified in
a prior specification statement.}
NOTE for future investigation:
The current wording of C533 is slightly defective, as it does not
clearly prohibit "REAL,DIMENSION(*) :: dummy,nondummy", seeing as
how that does indeed declare "the array bounds of a dummy data
object". C533 should probably be reworded similarly to C534a.
SUBMITTED BY: Bill Long
HISTORY: 12-191 m199 F08/0086 submitted - revised by Malcolm
Cohen - passed by J3 meeting
13-237 m200 Failed letter ballot
13-235 m200 Revised with straw votes
13-235r1 m200 Passed by J3 meeting
13-262 m201 Passed as amended by J3 letter ballot #28
13-255r1
N1990 m202 Passed by WG5 ballot N1988/n1987
something ???? Revised edits from draft corrigendum ballot
----------------------------------------------------------------------
More information about the J3
mailing list