J3/99-267
Date:    30th November 1999
To:	 J3
From:	 Malcolm Cohen
Subject: Unresolved issues 135 and 136

1. Introduction

Unresolved issue 136 says:
  "The 10th constraint in 4.5.5 says that type-param-values in array
  constructors and derived type constructors are required to be specification
  expressions. Why?  This seems like an inappropriate restriction and appears
  to be a change in specification.  Hmm.  Actually, it looks like constructors
  are ok as long as they are anywhere within an ALLOCATE statement (doesn't
  actually have to be the part of the ALLOCATE statement that specifies the
  type to be allocated).  Strange.  The same comments apply to the same words
  added in 5.1.1.5."

I concur.

Furthermore, this constraint is totally unnecessary because
<declaration-type-spec>s are already constrained to contain only specification
expressions in [69:22-23].  No constraint whatsoever is needed at this point!

Unresolved issue 135 says:
  "I'm not sure what purpose paper 99-106r2 had in mind in rewriting the 8th
  and 9th constraints in 4.5.5 (the ones about where asterisks and colons are
  allowed).  I thought the versions in 99-007 were better in all regards.
  Unless I'm missing something, the new version appears to now allow them in
  lots of places that the old version didn't.  Apparently an asterisk can be
  used in the declaration of a component (since that's not an entity).  And
  both the asterisk and colon can be used in constructors and allocate
  statements (since those aren't declarations of anything).  Looks to me like
  this was an attempt at wording improvement that broke the technical meaning.

  Note that the identical words for the colon case in 5.1.1.5 were left
  unchanged.  Why change them here but not there."

I concur.

  "Hmm.  Also I'm unsure whether 5.1.1.5 belongs to be repeating these
  constraints or just letting the ones from 4.5.5 apply.  Its not completely
  clear whether the constraints on type-param-value in 4.5.5 apply to any
  type-param-value or just to those used in derived type specifiers."

4.5.5 does indeed cover all <type-param-value>s, because the constraints are
on R450 <type-param-value>.

Oops.

  "If the ones in 4.5.5 apply, we need to get the bit about * to agree (as we
  allow * in a few extra places for character).  Since type-param-value is used
  for both derived and intrinsic types, it might be better to move R448 and its
  applicable constraints into, say, section 4.2, which is about type parameters
  in general, instead of 4.5.5, which is about derived types.  It might then
  also be easier to make clear what constraints applied in all cases (put them
  in 4.2), what ones applied to derived type specifiers (in 4.5.5), and what
  constraints applied to characters (in 5.1.1.5)."

I concur wholeheartedly.  Few will think to look for constraints on character
length specification under "4.5.5 Derived-type specifier"!

However, the only rule that need be moved is R450.  R448 and R449 indeed
only apply to derived-type specifiers and thus are appropriately placed.
Since the constraint needed for assumed character length is significantly
different from the constraint needed for other assumed type parameters, this
paper proposes separate constraints for each occasion.

Furthermore (really further to issue 134 which we fixed last meeting), there
appears to be no definition of assumed type parameter anywhere; descriptive
text but no definition.  Sigh.

2. Edits to 99-007r2

There are multiple edits placing text at [32:34+]; each inserted text after the
first one places the text immediately following the previous edit.  I have
noted where the edit to [32:34+] from 99-187r1 occurs.

[32:13] Delete sentence "The ... (7.1.7)."
{Delete sentence that duplicates the constraint previously at [58:9].}
[32:14] Delete "in turn".
{Improve wording.}

[32:16] Change second "kind" to "KIND".
{Improve readability.}

[32:28] Delete.
{Delete vacuous sentence.}
[32:29] Delete "in turn".
{Improve wording.}

[32:31] Before "," insert "named LEN".
{Specify the name of the character length parameter.}

[32:34+] Insert new paragraph
  "A type parameter value expression is not required to be of the same integer
   kind as the corresponding type parameter."
{Basically from [59:1-2] with slight rewording.}

[32:34+] Move R450 from [57:42-44] to here, plus the constraint at [58:9].
This text reads:
  "R450 <type-param-value> <<is>> <scalar-int-expr>
                           <<or>> *
                           <<or>> :
   Constraint: The <type-param-value> for a kind type parameter shall be an
               initialization expression."
{Move rule and the only correct constraint.}

[32:34+] Insert new constraint:
  "Constraint: A colon may be used as a <type-param-value> only in the
	       declaration of an entity or component that has the POINTER or
	       ALLOCATABLE attribute."

[32:34+] This is where the text from 99-187r1 should appear.
{The definition of deferred type parameters.}

[32:34+] Insert
  "An <<assumed type parameter>> is a nonkind type parameter for which the
   <type-param-value> is an asterisk.
   The values of the assumed type parameters of a dummy argument are assumed
   from the corresponding actual argument."
{New definition of assumed type parameter.}

[33:8-19] Delete.
{Delete J3 note.}

[57:42-44] Reminder: R450 was moved from here.

[58:9] Reminder: A constraint was moved from here.

[58:10-13] Replace two erroneous constraints with
  "Constraint: An asterisk may be used as a <type-param-value> in a
               <type-param-spec> only in the declaration of a dummy argument."
{Delete erroneous constraints.  Colon constraint is now in 4.2, asterisk
 constraint remains here because we want to handle assumed character length
 differently.}

[58:14-35] Delete.
{Delete the J3 note.}

[58:36-37] Delete.
{Delete spurious and erroneous constraint.}

[58:38-45] Delete.
{Delete the J3 note.}

[59:1-2] Delete sentence "A type parameter value ... parameter."
{Superior sentence inserted into 4.2.}

[59:3-6] Delete.
{Superior text inserted into 4.2.}

[73:41-42] Delete.
{Delete spurious and erroneous constraint.}