Version 1.4 of ai12s/ai12-0368-1.txt
!standard 4.9(8) 20-03-12 AI12-0368-1/03
!standard 4.9(12.1/3)
!standard 4.9(17)
!standard 6.1.1(24.2/5)
!standard 6.1.1(24.3/5)
!standard 6.1.1(24.4/5)
!standard 6.1.1(24.5/5)
!standard C.4(9)
!class Amendment 20-03-05
!status Amendment 1-2012 20-03-11
!status ARG Approved 14-0-0 20-03-11
!status work item 20-03-05
!status received 20-02-20
!priority Low
!difficulty Easy
!subject Declare expressions can be static
!summary
The term "statically names" is defined in 4.9 for more general use.
declare expressions can be static so long as nothing in them requires
any runtime evaluation, and the body_expression is static.
The prefix of an array attribute can be anything that is "statically
named".
Preelaboration is required for objects that are statically named.
!problem
declare expressions (4.5.9) are not listed in the static expression
section (4.9). It would seem a shame if a static expression would lose its
static-ness if it was refactored into a declare expression with the same
content. We allow static expression functions to be used in static
expressions, and declare expressions seem quite similar as
far as introducing names which are then used in an expression.
!proposal
(See Summary.)
!wording
Modify 4.9(8):
* an attribute_reference whose prefix statically [denotes]{names} a
statically constrained array object or array subtype, and whose
attribute_designator is First, Last, or Length, with an optional
dimension;
Add after 4.9(12.1/3):
* a declare_expression whose body_expression is static and each of whose
declarations, if any, is either the declaration of a static constant or is
an object_renaming_declaration with an object_name that statically names the
renamed object;
Add after 4.9(17):
A name statically names an object if it:
* statically denotes the declaration of an object Redundant[(possibly through
one or more renames)];
AARM Proof: Follows from the definition of statically denotes.
* is a selected_component whose prefix statically names an object, there
is no implicit dereference of the prefix, and the selector_name names a
component that does not depend on a discriminant; or
AARM Reason: We disallow components that depend on a discriminant so that
no discriminant checks are needed to evaluate the selected_component.
* is an indexed_component whose prefix statically names an object, there
is no implicit dereference of the prefix, the object is statically
constrained, and the index expressions of the object are static and have
values that are within the range of the index constraint.
[Editor's note: The part about implicit dereference was missing here in the
6.1.1 wording. Since a "null constraint" (that is, no constraint at all)
is considered statically constrained, object of most access types would
qualify for the original rule, which is not what we want.]
For an entity other than an object, a name statically names an entity if
the name statically denotes the entity.
Delete 6.1.1(24.2-5/5). [It is moved to 4.9 as above.]
Modify C.4(9):
* any name that is not part of a static expression is an expanded name or
direct_name that statically {names}[denotes] some entity;
!discussion
We do not want refactoring a static expression to use a declare expression
with the same contents (semantically) to become non-static, so a definition
for static declare expressions is needed.
We use "statically names" in these rules to allow them maximum flexibility.
See AI12-0369-1 for an example as to why wrapping an object in a record might
be desirable.
We checked all of the uses of "statically denotes" in the Standard, and the
only other cases that could use "statically names" are associated with various
tasking restrictions (see AI12-0369-1) and a rule in C.4. All of the other
rules are "statically denoting" entities that are not objects. We also change
that rule in this AI.
Since the term "statically names" is being used more generally, we move it
near the similar definition of "statically denotes". We also extend it to
work on non-objects, so that it can be used in place of "statically denotes"
without rearranging the rest of the wording.
!corrigendum 4.9(8)
Replace the paragraph:
- an attribute_reference whose prefix statically denotes a
statically constrained array object or array subtype, and whose
attribute_designator is First, Last, or Length, with an optional
dimension;
by:
- an attribute_reference whose prefix statically names a
statically constrained array object or array subtype, and whose
attribute_designator is First, Last, or Length, with an optional
dimension;
!corrigendum 4.9(12.1/3)
Insert after the paragraph:
- a conditional_expression all of whose conditions,
selecting_expressions, and dependent_expressions are static
expressions;
the new paragraph:
- a declare_expression whose body_expression is static and
each of whose declarations, if any, is either the declaration of a static
constant or is an object_renaming_declaration with an object_name
that statically names the renamed object;
!corrigendum 4.9(17)
Insert after the paragraph:
- It denotes a renaming_declaration with a name that
statically denotes the renamed entity.
the new paragraphs:
A name statically names an object if it:
- statically denotes the declaration of an object (possibly
through one or more renames);
- is a selected_component whose prefix statically names an object,
there is no implicit dereference of the prefix, and the selector_name
names a component that does not depend on a discriminant; or
- is an indexed_component whose prefix statically names an object,
there is no implicit dereference of the prefix, the object is statically
constrained, and the index expressions of the object are static and have
values that are within the range of the index constraint.
For an entity other than an object, a name statically names an entity if
the name statically denotes the entity.
!corrigendum 6.1.1(24/3)
!comment No change here, just need a conflict.
@drepl
@xbullet<a @fa<membership_choice> other than the first of a membership
operation.>
@dby
@xbullet<a @fa<membership_choice> other than the first of a membership
operation.>
!corrigendum C.4(9)
Replace the paragraph:
- any name that is not part of a static expression is an expanded
name or direct_name that statically denotes some entity;
by:
- any name that is not part of a static expression is an expanded
name or direct_name that statically names some entity;
!ASIS
No ASIS change.
!ACATS test
ACATS B- and C-Tests are needed to check that the declare expressions
can be static, and are not static if the conditions aren't met.
An ACATS C-Test should be constructed to check that array prefixes can be
"statically named" rather than just "statically denoted".
!appendix
From: Tucker Taft
Sent: Monday, February 24, 2020 9:09 AM
I just happened to notice that "declare" expressions (4.5.9) are not listed
in the static expression section (4.9). It would seem a shame if a static
expression would lose its static-ness if it was refactored into a declare
expression with the same content. We allow static expression functions to be
used in static expressions now, and declare expressions seem quite similar as
far as introducing names which are then used in an expression. So perhaps we
should add something like the following after 4.9(12.1/3):
* a declare_expression whose body_expression is static and each of whose
declarations, if any, is either the declaration of a static constant or is
an object_renaming_declaration with a name that statically names the renamed
object;
****************************************************************
From: Tucker Taft
Sent: Monday, February 24, 2020 9:15 AM
On a related note, I wonder whether paragraph 8 of 4.9 should be shifted to
use the "statically names" terminology:
* an attribute_reference whose prefix statically [denotes]{names} a statically
constrained array object or array subtype, and whose attribute_designator is
First, Last, or Length, with an optional dimension;
Also, I wonder whether we shouldn't move "statically names" from 6.1.1 to 4.9,
where we define "statically denotes." It is a bit odd for "statically names"
to be in the pre/postcondition section.
****************************************************************
From: Richard Wai
Sent: Monday, February 24, 2020 11:07 AM
Great catch in both accounts! I agree that these are desirable changes.
****************************************************************
From: Steve Baird
Sent: Monday, February 24, 2020 12:30 PM
> ... So perhaps we should add something like the following after 4.9(12.1/3):
>
> * a declare_expression whose body_expression is static and each of
> whose declarations, if any, is either the declaration of a static
> constant or is an object_renaming_declaration with a name that
> statically names the renamed object;
Looks good to me.
> On a related note, I wonder whether paragraph 8 of 4.9 should be shifted to
>use the "statically names" terminology:
>
> * an attribute_reference whose prefix statically [denotes]{names} a
> statically constrained array object or array subtype, and whose
> attribute_designator is First, Last, or Length, with an optional
> dimension;
Also looks good.
Because declare expressions are new, we don't care about the compatibility
issues associated with reclassifying a non-static expression as static
(there are issues relating both to legality checks and to real arithmetic
precision).
> Also, I wonder whether we shouldn't move "statically names" from 6.1.1 to
> 4.9, where we define "statically denotes." It is a bit odd for "statically
> names" to be in the pre/postcondition section.
Very good point. When we introduce a new term and it is used in only one
place, it makes sense to define the term near that single use.
If we later start using the term in more places, we should consider moving
the definition.
Note that this guideline wasn't followed (I plead guilty) in the recent ARG
discussion of adding another use of "statically names" in the context of
defining "pure-barrier-eligible".
****************************************************************
From: Gary Dismukes
Sent: Monday, February 24, 2020 1:04 PM
> Also, I wonder whether we shouldn't move "statically names" from 6.1.1 to
> 4.9, where we define "statically denotes." It is a bit odd for "statically
> names" to be in the pre/postcondition section.
Yes, definitely move it to 4.9.
****************************************************************
From: Randy Brukardt
Sent: Monday, March 2, 2020 10:32 PM
> So perhaps we should add something
> like the following after 4.9(12.1/3):
>
> * a declare_expression whose body_expression is static and each of
> whose declarations, if any, is either the declaration of a static
> constant or is an object_renaming_declaration with a name that
> statically names the renamed object;
I agree with the basic question and concept, but I have to wonder about
the last part. The only object names allowed in a static expression are the
names of static constants. The above wording seems to allow a renaming that
statically names a variable. I suppose it wouldn't be harmful, per-se, but
such a renaming would be completely useless. Note that renamings can be
static constants, so we probably shouldn't be mentioning them separately.
* a declare_expression whose body_expression is static and
each of whose declarations, if any, is the declaration
of a static constant (which might be a stand-alone
constant or a renaming declaration);
Secondly, "statically naming" a constant component doesn't make it a static
constant (which is a concept declared by 4.9(24/5)), since a "static constant"
has to be a stand-alone object (since it is required to be declared by a full
constant declaration and in particular not a component. (The wording in
4.9(24/5) does not include "part"!) So even for constants the original wording
doesn't work, since the renaming still wouldn't be allowed in a static
expression unless it was a static constant by 4.9(24/5) - which doesn't allow
static naming.
I don't see any point in allowing stuff to be declared in a static expression
that can't be referenced in the expression. If we're going to allow unusable
stuff, it's not clear why we're allowing some renamings and not similar
constants. But unused declarations are usually removed when detected, is
there a good reason for this to be different?
So I think if we want to allow static renaming more generally as is suggested
here, we need to do that (somehow) in the definition of static constant,
presumably by moving some of the static naming stuff there. But I'm not really
sure how that would work, we'd need to get a value from an aggregate in such a
case.
I don't have any problem with the other suggestions (moving "statically names"
here, and using it in the array attribute rule), as well as Tucker's
(private) suggestion to use "statically names" in C.4(9).
****************************************************************
From: Tucker Taft
Sent: Tuesday, March 3, 2020 3:57 AM
...
> I agree with the basic question and concept, but I have to wonder
> about the last part. The only object names allowed in a static
> expression are the names of static constants. The above wording seems
> to allow a renaming that statically names a variable. I suppose it
> wouldn't be harmful, per-se, but such a renaming would be completely
> useless. Note that renamings can be static constants, so we probably
> shouldn't be mentioning them separately.
You can get a static expression by getting the 'First or 'Last of a
statically-constrained variable array (RM 4.9(8)). That is what I had in
mind for why a static renaming of a variable would be useful.
...
> Secondly, "statically naming" a constant component doesn't make it a
> static constant (which is a concept declared by 4.9(24/5)), since a
> "static constant" has to be a stand-alone object (since it is required
> to be declared by a full constant declaration and in particular not a component.
> (The wording in 4.9(24/5) does not include "part"!) So even for
> constants the original wording doesn't work, since the renaming still
> wouldn't be allowed in a static expression unless it was a static
> constant by 4.9(24/5) - which doesn't allow static naming.
Again, the point was to allow referring to 'First/'Last of a
statically-constrained component.
> I don't see any point in allowing stuff to be declared in a static
> expression that can't be referenced in the expression. If we're going
> to allow unusable stuff, it's not clear why we're allowing some
> renamings and not similar constants. But unused declarations are
> usually removed when detected, is there a good reason for this to be
> different?
See above w.r.t statically-constrained array variables.
****************************************************************
From: Randy Brukardt
Sent: Thursday, March 5, 2020 10:38 PM
...
> > I agree with the basic question and concept, but I have to wonder
> > about the last part. The only object names allowed in a static
> > expression are the names of static constants. The above wording
> > seems to allow a renaming that statically names a variable. I
> > suppose it wouldn't be harmful, per-se, but such a renaming would be
> > completely useless. Note that renamings can be static constants, so
> > we probably shouldn't be mentioning them separately.
>
> You can get a static expression by getting the 'First or 'Last of a
> statically-constrained variable array (RM 4.9(8)).
> That is what I had in mind for why a static renaming of a variable
> would be useful.
OIC. Allowing all variables is overkill, since anything other than an array
variable is useless. So something like:
* a declare_expression whose body_expression is static and each of
whose declarations, if any, is either the declaration of a static
constant or is an object_renaming_declaration with a name that
statically names an array object;
might be better. But it's certainly not as clear-cut as I was thinking.
And this version is slightly confusing, since a renaming of a static
constant is covered by the first part. Probably would need an AARM note
for that:
AARM Ramification: An object_renaming_declaration that renames a
static constant is itself a static constant, so it is also allowed
by this rule.
Or we could use a parenthetical remark instead:
* a declare_expression whose body_expression is static and each of
whose declarations, if any, is either the declaration of a static
constant (which might be a stand-alone constant or a renaming
declaration) or is an object_renaming_declaration with a name that
statically names an array object;
The need for the AARM note (or the longer parenthetical remark) makes it less
of an improvement than I originally hoped.
----
Another point I think came up elsewhere (but I haven't found where yet, it's
definitely not in this thread).
That is, when we change 4.9(8) to:
* an attribute_reference whose prefix statically names a
statically constrained array object or array subtype, and whose
attribute_designator is First, Last, or Length, with an optional
dimension;
we now have wording that is talking about "statically names a ... array
subtype". But the original definition of "statically names" only applies to
objects. We could complicate this wording by using the correct term on each
thing:
* an attribute_reference whose prefix statically names a
statically constrained array object or statically denotes a
statically constrained array subtype, and whose
attribute_designator is First, Last, or Length, with an optional
dimension;
but this is a lot longer. So I added the following after the existing
definition of "statically names".
For other kinds of entities, a name statically names an entity if the name
statically denotes the entity.
"other kinds" is a bit vague but since it follows the bullets about
"statically names an object if" it seemed good enough. I suppose we could
use something like:
For nonobject entities, a name statically names an entity if the name
statically denotes the entity.
but I'm no fan of "non"words.
****************************************************************
From: Tucker Taft
Sent: Friday, March 6, 2020 9:23 AM
...
> Or we could use a parenthetical remark instead:
>
> * a declare_expression whose body_expression is static and each of
> whose declarations, if any, is either the declaration of a static
> constant (which might be a stand-alone constant or a renaming
> declaration) or is an object_renaming_declaration with a name that
> statically names an array object;
>
> The need for the AARM note (or the longer parenthetical remark) makes
> it less of an improvement than I originally hoped.
I don't see the point of restricting it to array objects. Presumably the
programmer will not waste time putting renames into a declare expression that
aren't going to be used in later declarations or in the expression. So why
be picky here? The key point is we don't want any declarations that require
run-time elaboration, since that won't work for a static expression, and
"statically names" gives us that. And who knows, some day we might have other
sorts of static attributes.
>
> ----
>
> Another point I think came up elsewhere (but I haven't found where
> yet, it's definitely not in this thread).
>
> That is, when we change 4.9(8) to:
>
> * an attribute_reference whose prefix statically names a
> statically constrained array object or array subtype, and whose
> attribute_designator is First, Last, or Length, with an optional
> dimension;
>
> we now have wording that is talking about "statically names a ...
> array subtype". But the original definition of "statically names" only
> applies to objects.
Yes, I noticed this in another (non-Ada-Comment) thread, and made essentially
the same suggestion you have below:
"Another item that came to mind when looking at the definition of "statically
names" is that it only is defined for objects. I would think we might want to
use the term more generally, with it meaning "statically denotes" for things
other than objects, and have the additional ability to denote subcomponents for
objects." (24-Feb-2020, 4:31PM EST, "Pure_Barriers restriction relaxation")
...
> I suppose we
> could use something like:
>
> For nonobject entities, a name statically names an entity if the name
> statically denotes the entity.
>
> but I'm no fan of "non"words.
I am a nonfan as well. ;-)
****************************************************************
From: Randy Brukardt
Sent: Friday, March 6, 2020 2:29 PM
Humm. Maybe better than either would be:
For an entity that is not an object, a name statically names an entity if
the name statically denotes the entity.
or:
For an entity other than an object, a name statically names an entity if
the name statically denotes the entity.
Rather than the vague "other kinds". Thoughts?
****************************************************************
From: Tucker Taft
Sent: Friday, March 6, 2020 2:47 PM
Agreed. Either is better; I slightly prefer the second one ("other than an
object").
****************************************************************
Questions? Ask the ACAA Technical Agent