(j3.2006) (SC22WG5.5175) [ukfortran] Draft result of ballot on Corrigendum 3

[Bill Long]

On 12/24/13 6:35 PM, Malcolm Cohen wrote:
> Bill Long writes:
>> Are the replacement edits really correct?
>
> Yes.
>
>> On 12/24/13 10:03 AM, John Reid wrote:
>>> [95:33-] Insert new BNF term
>>>     "R520a <assumed-implied-spec> <<is>>  [ <lower-bound> : ] *"
>>>
>>
>> OK, a new, reusable name for  [<lower-bound>:]* .
>
> Yes.
>
>>> [95:33] R521 <assumed-size-spec>, after "<<is>>"
>>>     Replace entire RHS
>>>       "[ <explicit-shape-spec>, ]... [ <lower-bound> : ] *"
>>>     with
>>>       "<explicit-shape-spec-list>, <assumed-implied-spec>"
>>
>> So now there is a mandatory comma as part of this syntax?
>
> I should hope so!!!!!  Having no comma between the preceding
> explicit-shape-spec-list and the assumed-implied-spec would be a serious error,
> e.g.
>
>    REAL X(1:100 30:*)
>
> I think we can all agree there needs to be a comma between the
> explicit-shape-spec-list "1:100" and the assumed-implied-spec "30:*".
>
>>   It would seem this should be
>>
>> "[<explicit-shape-spec-list>,] <assumed-implied-spec>"
>
> No, the case when the explicit-shape-spec-list is missing is the ambiguous case.
> Which is why we have the edit
>
>>> [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.}
>
> ...
>>> [96:26] R522,
>>>     Replace right-hand-side (after "<<is>>")
>>>       "[ <lower-bound> : ] *"
>>>     with
>>>       "<assumed-implied-spec>, <assumed-implied-spec-list>".
>>
>> Similarly here, should this not be
>>
>> "<assumed-implied-spec> [, <assumed-implied-spec-list>]"
>
> No.
>
>> or better, just
>>
>> "<assumed-implied-spec-list>"
>
> No.
>
>> since the <-list> syntax requires at least one instance of the thing being
>> qualified.  [22:16].
>
> Those just reintroduce the ambiguity the interp is complaining about in the
> first place... the complaint wasn't "we don't have a catchy name for [
> <lower-bound> : ] *", it was "the syntax is ambiguous".  The catchy name is only
> introduced because it simplifies the otherwise-confusing BNF and prose
> descriptions.

I hardly see this as "simple".  Not to mention the confusing wording for 
error messages that use syntax terms.

How is Q2 of the interp any different from

subroutine test2(a)
   character(*) :: a,c
   parameter (c = "string")
   a = c
end

We don't seem to have an issue with a * for the length type parameter 
meaning two different things in the same statement.   It is 
disambiguated by whether the entity is a dummy argument.  We manage to 
say that in normative text, and there is no problem with the code above. 
   The same should be true for the dimension case which looks the same. 
   The real contradiction in the original interp was the requirement 
that the "shape" had to be previously specified, instead of only the 
rank.   All of the new syntax seems extraneous and unnecessarily confusing.

Cheers,
Bill




>
> Cheers,
>

-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101