Kevin Maguire writes:

 > Is there anything illegal about the following code, in particular the
 > DATA statements....
  [elided]

Looks fine to me.  In fact pretty straightforward unless I missed
something.  And the NAG compiler (which is normally pretty good
about catching extensions) didn't find anything either.

I've got a guess about what compiler(s) might be failing on this,
but I think I'll keep my biases to myself in the matter, as I
haven't checked.  Anyway, it is standard conforming (in my
considered, but humanly fallible, opinion) and thus a compiler bug
if it fails.

 > I not 100% sure when or where I need array constructors.

Mostly wherever you want an array.  DATA statements are a bit
unusual, though, 'tis true.  The whole syntax of the DATA statement is
full of special cases.  This is partly because of things like the
3*5 notation to mean 3 copies of the value 5 (as opposed to the
value 15).  It is "dangerous" to take general statements and apply
them to the DATA statement.  Some things apply; others don't.

In particular, DATA statements do have several "special" rules
relating to arrays.  Note that DATA statements were one of the
few places in f77 where you could reference a whole array, but f77
didn't have syntax to write array-valued constants.  The data objects
in a data statement are always expanded to an equivalent sequence
of scalar values.  And the data statement constants must always be
scalar.  Thus, if you have ijk as an array of 3 integers, it would be

  data ijk/ 5, 5, 5/

or , alternatively

  data ijk/ 3*5 /

and not

  data ijk/ (/ 5, 5, 5 /) /

as you might expect.

This expansion of arrays to scalars applies only to the "top-level"
objects in the DATA statement, though.  If you have a derived type,
a scalar of the derived type may well include array components (as
does your example).  The syntax of a derived-type constructor is
going to require that you have arrays for those components.  The DATA
statement doesn't do anything "funky" with the innards of derived
type constructor syntax.  Thus, your

 >   data A / Table ( (/ 1 , 2 , 3 /) , (/ "H   ", "He  " , "Li  " /) ) /

is correct in using array constructors for the components.  But if you
put an array component of a derived type as a top-level object in the
DATA statement, it is now just an array.  Doesn't matter that it is an
array that also happens to be a component of some object.  So the DATA
statement rule for expanding top-level arrays now applies.  Thus your

 >   data B % at_number / 1 , 2 , 3  /
 >   data B % at_name / "$$$$" , "****" , "++++" /

are correct in omitting the array constructors.

Yes, DATA statements are tricky.  I mostly avoid them as somewhat
confusing vestiges of f77.  But I do use them on occasion.  There are
some cases where you really need them.  Mostly when you want to
initialize only part of an object for any of several reasons.  Also,
occasionally that repeat*value syntax is nice.

-- 
Richard Maine
[log in to unmask]



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%