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

[Malcolm Cohen]

>> 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".

Giving a name to the occurring-in-several-places "[ <lower-bound> : ] *" syntax 
is clearly simpler than repeating that syntax in every place it is used.

That is not to claim that we cannot improve the BNF/constraints/prose.  But it 
is hard to see how we could do that without a wholesale rewrite of the 
array-spec syntax; that would be a lot more work than this fix.  Perhaps some 
editorial/DATA time could be found over the next year or two to revisit this and 
try to straighten out what has become somewhat convoluted and perhaps overly 
complicated with our plethora of array kinds.

>  Not to mention the confusing wording for error messages that use syntax 
> terms.

Poor choice of wording for error messages is hardly the fault of the standard. 
In fact, since few users have copies of the standard, slavishly repeating syntax 
terms from the standard is unlikely to be the best wording (except in the happy 
instance where desipte the rigors of BNF and the straightjacket of existing 
syntax and terminology we happened to come up with a really great name!).

Not to mention that if "<assumed-implied-spec>" is unappetising, there is 
nothing stopping you from using "[ <lower-bound> : ] *" instead since that is 
what it expands to...

>How is Q2 of the interp any different from
>
>subroutine test2(a)
>   character(*) :: a,c
>   parameter (c = "string")
>   a = c
>end

Completely and utterly different.  No connection.

>We don't seem to have an issue with a * for the length type parameter meaning 
>two different things in the same statement.

Once again, Q2 is not about whether "*" can have different meanings, it is about
    THE BNF RULES IN THE STANDARD WERE AMBIGUOUS

There were two parses for the example array-spec in Q2, and no reasonable way to 
disambiguate them.

>   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.

No it does not look the same.  The syntax of an array-spec is more complicated 
than a simple ": or * or expr".

>   The real contradiction in the original interp was the requirement that the 
> "shape" had to be previously specified, instead of only the rank.

No, that was just Q1.  Q2 was entirely about the ambiguous BNF.

>   All of the new syntax seems extraneous and unnecessarily confusing.

There is no "new syntax" as such, the revised BNF in fact has FEWER parses than 
the old one.  That's because the old one was ambiguous, and we removed the 
ambiguity.  Yes it took more rules to specify the syntax unambiguously - that is 
quite often the case with rules!

You seem to be hinting at an approach which would be to make the BNF rules 
themselves much more permissive, and eliminating ambiguous parses with textual 
constraints and ambiguous semantics with plain prose.  While that might be a 
viable approach, it would seem to have two major disadvantages:
(a) loses the power of BNF formalism - reducing the ability to mathematically 
prove the syntax;
(b) requires wholesale rewrite of the array-spec BNF.
Disadvantage (a) makes it likely to be a bad idea.
Disadvantage (b) makes it a complete nonstarter for an interp anyway.

I certainly have no objection to rethinking the way that we describe an 
array-spec with a view to improving the exposition, quite the opposite.  But 
that would be for the next revision.  And it is certainly unclear at this point 
whether any real improvement could be made, or whether that would just be moving 
the complications out of the BNF and into the prose (as mentioned above, that is 
often a bad idea).

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.