(j3.2006) Interp F03/0091

[Malcolm Cohen]

Michael Ingrassia strangely asserted:
>But one can't argue from logic; the standard has actual words and
>statements that have to be interpreted.  

That's what we're using the logic on, but you still have to use logic.

Bill Long said:
> That is not at all clear.  Having an <explicit-shape-spec-list> does not 
> necessarily make something an explicit-shape array.

Well if you actually read 4.5.3.1, it says

  "If the <component-decl> contains a <component-array-spec>, it specifies
   the array rank, and IF THE ARRAY IS EXPLICIT SHAPE ..."
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                       ||||||||||||||||||||||||||||||
                       emphasis mine.

>"explicit-shaped array" is a defined term [78:16], not a description.

Yes, and one that contradicts 4.5.3.1 (or vice versa).

> > Either we have to
> >mutilate 4.5.3.1 so that array components aren't arrays (and I have no
> >idea how to do so), or we have to repair 5.1.2.5.1.  I prefer the
> >latter.
> >
> 
> I don't see those as the only options.

Fixing the contradiction in at least one of the two places that
contradict each other is the only option.

> An array does not have to be a named array.

Exactly.

> Sure, if you change the definition of explicit-shaped array to include
> things arrays that are not named arrays, then you are forced to change
> the constraint that references that definition.

We should be changing the constraint anyway,
the way it is written now is not acceptable.

> How many other places that also need changing is unclear. But why
> change the definition of something that is as fundamental as this?

As fundamentally incorrect as this!

To have "explicit-shape array" mean something other than "array that is
explicit shape", is just bad form, and without technical justification
it's unacceptably bad form.

(repeated)
> How many other places that also need changing is unclear.

You have it backwards - many of those assume the literal reading of
"explicit-shape array", so need changing NOW, and would not need
changing if we corrected the bad definition.

Looking at every occurrence of "explicit-shape" in 07-007r1
 1 is the (bad) definition
 1 is the (unimportant) glossary
 15 are (irrelevant) syntax terms
 4 are correct either way
 4 require the literal meaning

i.e. with the fix suggested by Van only the glossary need be changed,
without it (viz with bodging 4.5.3.1) 3 other places need bodging.

So the misleading definition is not just misleading, but wrong in four
places, whereas the suggested correction is not only less misleading
but only needs 1 constraint to be changed.

> The simpler option is to make neither of the changes on page 78 that
> are suggested above.

Oh yes, and not have any semantics for array components.
Not an improvement.

It's pretty clear that the F77 definitions of "whole array" et al were
not sufficient to describe F90.  Maybe it's a shame we're not getting
around to fixing the text until now, but that's no excuse for not fixing
it at all.

Cheers,
-- 
........................Malcolm Cohen (malcolm at nag-j.co.jp), Nihon NAG, Tokyo.