J3/99-119
Date: 3rd March 1999
To: J3
From: Malcolm Cohen
Subject: Unresolved issues 73, 77, 80, plus related fixups.
INTRODUCTION:
-------------
Issue 73 is "May the char length of a component be deferred? The 2nd
constraint after R433 says not."
The answer is yes, a char length can be deferred.
Issue 77a is "No requirements on type parameters in init/constant exprs".
We add some.
Issue 77b is "type parameters can supposedly appear in spec exprs and init
exprs, but they are not allowed to".
We will allow
kind type parameters in initialisation expressions
unkind type parameters in specification expressions
We don't want to allow kind type parameters in constant expressions (they are
not constant!) so we need to decouple initialisation exprs from constant exprs.
Then we need to fix the rules for non-kind type-parameters in a derived type
def; these need to be the same as the array bounds cases.
One question that arises is do we allow the usual dummy arguments and common
block variables in a specification expression that is in a derived-type def;
the answer is NO (we could not allow it in a module anyway, and for consistency
it is preferable to have derived-type characteristics only affected through the
type-parameter list.
We will introduce a new term "restricted specification expression" which is a
specification expression that is suitable for use in derived-type definitions.
{It might be a good idea to get rid of our existing "restricted expressions"
that are only used partway to define specification expressions.}
Related: Poor wording is:
[61:22-23] Says that "every ... that is not assumed or
deferred shall be a ."
This wording is poor because it is the type parameter (not italicised!)
that is assumed or deferred, the is an asterisk or colon.
Issue 80 is should we get rid of the BNF term and use
instead. The answer is yes.
EDITS:
------
{Non-deferred array bounds in component defns must be restricted.}
[40:46-47] Replace with
"Constraint: Each bound in the shall be a
restricted specification expression."
{Similarly, type-param-values in component defns must be restricted.}
[41:9-14] Replace with
"Constraint: Each within a shall either
be a colon or a restricted specification expression."
{Issue 80}
[61:22] Delete "or "
{Fix poor wording}
[61:23] Change "assumed or deferred" to "a colon or an asterisk".
{Issue 80}
[62:17] Change "" to "type parameter value".
{Broken text - BNF term is not available}
[62:18] Change "" to "specification expression".
{Fix broken text}
[65:38-40] Replace text up to "specification expression" with
"In a declaration, a type parameter value or array bound may be a nonconstant
expression provided the expression"
{Fix incorrect BNF term}
[65:41] Replace "" with ""
{Fix more broken text}
[65:41] Change "" to "expression".
{Improve readability}
[65:42] Change "the expression" to "it".
{Issue 80}
[67:18,20,23,24,26] Change "" to "".
[67:28-38] Delete.
[67:44] Change "" to "".
In obsolescent, after "unless it is" add "of type CHARACTER and is".
[68:1,8] Change "" to "".
{Allow type parameter names in specification expressions.}
[121:40+] Add new item to list and renumber:
"(9.1) A type parameter, within a derived-type definition, of the derived type
being defined."
{Restricted form of spec exprs for use in derived-type defns}
[122:40+] Add new paragraph
"A <> is a specification expression that
does not contain any object designators or references to specification
functions."
{Unrelated fixup:}
[123:14] Before "," insert "and no component has the ALLOCATABLE attribute".
{This is broken in F95 and should be fixed sometime.}
[123:35+] Insert as a J3 note.
"In F95 we allow 'constant specification expressions' in certain situations
where evaluation at compile-time is required. This is confusing and unhelpful;
(1) compile-time evaluation is the purpose of INITIALIZATION expressions
(2) if we require all compilers to evaluate them at compile-time, why not let
the user put them into PARAMETERs?"
{Allow kind type parameter names in init exprs.}
[123:36] Delete "constant"
{The listed requirements for initialisation expressions cover or subsume the
constant expression requirements anyway, so this adds nothing - it just
breaks kind-type parameters in pdts.}
{Allow kind type parameter names in init exprs.}
[124:28+] Add new item to list and renumber:
"(7.1) A kind type parameter, within a derived-type definition, of the derived
type being defined,"