(j3.2006) another example of a forward reference

[Malcolm Cohen]

<<<
      A length type parameter may be used in specification
      expressions within the derived-type definition for the
      type, but it shall not be used in constant expressions.

That statement can be read in more than one way.

I would like the array constructor shown in Note 4.74 of
the Fortran 2008 standard (Clause 4.8, paragraph 8+, [86])
to be a standard-conforming constant expression.
>>>

I don't quite follow.  That note shows
   [ CHARACTER(LEN=7) :: 'Takata', 'Tanaka', 'Hayashi' ]
which contains no length type parameters.  I mean, 'Takata' has (specifies) a 
length type parameter but it is not one.  LEN=7 specifies the value of a length 
type parameter, but it is not one.  I see no actual length type parameter 
entities here - in fact since those are only accessible within the derived-type 
definition, this is not a surprise.  Even CHARVAR%LEN is not a length type 
parameter but a length type parameter inquiry, though I accept that here we are 
on shakier ground since one might unconvincingly argue that the "LEN" after the 
"%" is a length type parameter.

So even disregarding the clear implication that the second half is still in the 
context of "within the derived-type definition", if we accept that when it says 
"length type parameter" it really is talking about the "length type parameter" 
entity itself, there are no problems with the example in 4.74.

Generally I agree with Rich Maine who said (approx) that if you can read a 
requirement in two ways, and one does not make sense, it is the other way that 
is the meaning.  Using that rule, the reading you are hinting at can be rejected 
as it leads pretty quickly to ridiculous conclusions.

That said, I don't disagree the wording could be better though, perhaps as

  "Within a derived-type definition, a length type parameter of the type being 
defined can be used in a specification expression, but it cannot be used in a 
constant expression."

(Removes needless pluralisation, puts the context at the beginning rather than 
in the middle, and the requirements of constant and specification expressions 
are specified elsewhere so we can use "can" to indicate capability rather than 
duplicate those requirements and confuse the unwary.)

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