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,"