J3/98-162

Date:        27 May 1998
To:          J3
From:        R. Maine
Subject:     Explicitly typed array constructors


Paper 98-124 suggested an extension to array constructor syntax
in order to allow explicit specification of the type and type
parameters of an array constructor.  A straw vote on whether
to procede in the general direction of that paper passed
15-0 with 3 undecided.

The current paper largely repeats 98-124, plus two new questions.

I. The problem (justification)

Array constructors suffer from several problems that I attribute
to the "feature" that their type and type parameters need to
be inferred from the components.

One example that resurfaces continually is the necessity to
explicitly pad out all of the strings to the same length in
an array of strings, as in
  (/ 'tom  ', 'dick ', 'harry' /)
Interpretation 30 on this subject caused considerable anguish,
but no adequate answer other than "yes, it is required" emerged.
Users continually trip over this requirement and complain
vehemently.

Another case, which does not yet seem to have been addressed,
is raised in the interpretation request in J3/98-101.
This case involved zero-length arrays.

With parameterized derived types, the opportunity for confusion
and complication in this area increases.  This is because there
are now more cases where the type and type parameters need not
be known at compile time.  Prior to parameterized derived
types, the character length parameter was the only type parameter
not constrained to be known at compile time (in the usual
weasel words of the standard, where we avoid actually saying
"compile time").

II. Specification

I certainly do not propose radically changing array constructor
syntax.  The existing syntax

  1. Is by now used in innumerable codes, pretty much ruling out
     incompatable changes.
and
  2. Is fine for the simple cases.

My proposal is to add an optional new part to the syntax.  This new
part would be an explicit specification of the type and type
parameters at the beginning of the constructor.  If the optional new
part is omitted, we have the existing array constructor; the type
and type parameters are inferred from those of the elements.  If,
however, the new part is used to explicitly specify the type and
type parameters, then assignment semantics are used for each
element; there is no need for the elements to be of the same
type and type parameters, or for there to be any elements).

One question on the details of this specification has been raised.
This is on exactly what assignment semantics is used.  Derived
type constructors allow only intrinsic assignment syntax.  It
is not clear why this restriction is necessary in general.
Of course, you can't have derived assignments in an initialization
expression, but it is not clear why this restriction needs to
apply to derived type constructors used in all places.  There
are three possibilities

  1. Restrict array constructors to use only intrinsic assignment
     semantics, just like derived type constructors.
  2. Allow derived assignments in array constructors, unlike in
     derived type constructors.
  3. Allow derived assignments in array constructors and change
     derived type constructors to allow this also.

III. Syntax

The new part would just be a type-spec, which we have already
defined syntax for.  That sytax works fine in this context.

Samples
  character(len=16) (/ 'tom', 'dick', 'harry' /)
  real(kind=kind(0.0d0)) (/ 1., 2, 3.d0 /)
     !-- Note that the second element above is integer.
  my_pdt(kind=1, dim=3) (/ element1, element2, ... /)
We could possibly require the last sample above to be written as
  type(my_pdt(kind=1, dim=3)) (/ element1, element2, ... /)
but I think the type() to be just extra typing to no obvious
benefit.  I'm flexible on this point though.

An alternative syntax has been suggested to simplify parsing
of the intrinsic type cases (because the intrinsic type
names aren't in the class 1 namespace).  This alternative
moves the type-spec to after the opening "(/"; a double
colon is then used to separate the type-spec from the element
values.  A sample is
  (/ character(len=16) :: 'tom', 'dick', 'harry' /)

All of the above forms appear to me to "work" and be unambiguous.
They are all a bit wordy for the simple cases.  But you don't
need to use the extra words for the simple cases.  They are
optional.

As best as I can see, the *ONLY* place that would need edits
would be section 4.5.  They don't seem hard to do.