J3/99-150r1

Date:    28th May 1999
To:      J3
From:    Malcolm Cohen
Subject: Unresolved issues 77 and 131-133


1. Introduction

Issue 133:
One requirement was missed out of the decoupling of the terms "constant
expression" and "initialization expression".

Issue 132:
notes that constant expressions have an "understandable" term,
but are hardly ever used.  Unfortunately, we have little use for constant
expressions - the distinction we are interested in is not just whether they
are constant but whether the compiler treats them as constant: so they are
evaluated at compile-time and can be used to determine type information
(kind type parameters) and static storage allocation (array sizes for
SAVEd variables) etc.  And we have a term for the latter one - it is
"initialization expression".  IMO we should forget all about constant
expression because users would not like being told that ASIN(1.0) is not a
constant expression (but yet the standard treats it as such, at least
mostly).
Also, initialization expressions can include kind type parameters, but this
is obviously nonsense for constant expressions (using the naive user's
interpretation of "constant").

Also, at least some of the few uses of "constant expression" ought to be
"initialization expression".  Edits are supplied to fix this.

Edits are not supplied to fix the J3note itself, as this is awaiting interp
resolution.

BTW, I agree with the comments on our confusing expression categorisation.
I am strongly in favour of eliminating the "constant expression" term.
We could eliminate the "restricted specification expression" term by
duplicating the extra requirements in (currently) 2 places - a separate set
of edits is supplied in case this finds universal appeal.  However, although
this would remove some terminology confusion, it would mean that the
necessary
restrictions (which are - and must be - identical) would appear in 2 places
(and maybe more, if we have forgotten something).

Issue 77:
actually, the text is wrong everywhere.  The requirement that "type
parameter
is a restricted expression" ought to be "type parameter *VALUE* is ..." - as
we can see from the comments in 131 where it is pointed out that type
parameters themselves (as opposed to their values or inquiries) are limited
to
the scope of the derived-type definition.

Edits are supplied to fix this.

Issue 131:
Yes, I agree that a type parameter is only accessible with its derived-type
definition.  I forgot that outside they are called "type parameter
inquiries".

However, is "A type parameter of the derived type being defined" not more
understandable than "A type parameter" ?  Particularly when even we are
prone
to confusing "type parameter", "type parameter value" and "type parameter
inquiry"?  Therefore I propose just to delete the scoping qualification.

2. Edits

{Note132:Fix incorrect use of constant expression when initialization
expression is required.}
[31:36] Change the first "constant" to "initialization".
{It is not true that a "constant value" in this context can be a constant
expression that is not an initialization expression: [31:34] says they can
be given names, which is only true for initialization expressions.}

{Note132:Fix another incorrect "constant expression"}
[48:25] Change "a constant" to "an initialization".
{The context is default initialization - which requires an initialization
expression!}

{Note132:Delete redundant text}
[61:46-47] Delete the first sentence which is
"A structure constructor whose component values are all constant expressions
is
a derived-type constant expression.".
{In what way does this add anything that the definition of a constant
expression does not?  And since we almost never use constant expressions,
this
gives unnecessary prominence to the concept.}

{Note132:Delete redundant and misleading text, plus its example}
[66:34-39] Delete.
{The normative sentence was "If every expression in an array constructor is
a
constant expression, the array constructor is a constant expression.".  This
does not add anything to the definition of a constant expression.  And the
example is trivial - and is follow by 4 other notes each of which contain
other examples of constant array constructors!  This is not, IMO, useful.}

{Note131: Delete redundant scoping qualification}
[140:1] Delete ", within a derived type definition,".

{Note131: Delete the J3 note}
[140:2-13] Delete.

{Note77: Fix use of incorrect term "type parameter"}
[140:18] After "parameter" insert "value".

{Note77: Delete the J3 note}
[140:19-31] Delete.

{Note77: Add "type parameter values" to constant expression requirements}
[142:8] Delete second "and"
        Before "is" insert ", and type parameter value".

{Note133:Fix it.}
[142:34] After "which" insert "each operation is intrinsic,".

{Note133:Delete the J3 note}
[142:36-43] Delete.

{Note131: Delete redundant scoping qualification}
[143:31] Delete ", within a derived type definition,".

{Note77: Add "type parameter values" to initialization expression reqs}
[143:36] Delete second "and"
         Before "is" insert ", and type parameter value".

3. Additional edits to eliminate "restricted specification expressions"

{Duplicate the restriction}
[43:13] Change "be a restricted specification expression (7.1.6)" to
        "not contain references to specification functions or any object
         designators other than named constants or subobjects thereof"

{Ditto}
[43:24] Delete "restricted"
        After "expression" add
        "that does not contain references to specification functions or any
         object designators other than named constants or subobjects
thereof"

{Delete the definition of restricted specification expression}
[141:29-31] Delete.

{Delete the amusement}
[142:28-33] Delete ", and now ... by it all".