Version 1.10 of ai12s/ai12-0072-1.txt

Unformatted version of ai12s/ai12-0072-1.txt version 1.10
Other versions for file ai12s/ai12-0072-1.txt

!standard C.5(1)          13-10-07 AI12-0072-1/05
!standard C.5(5)
!standard C.5(7/2)
!standard C.5(8)
!class binding interpretation 13-06-07
!status Corrigendum 2014 13-07-11
!status WG9 Approved 13-11-15
!status ARG Approved 7-0-0 13-06-16
!status work item 13-06-07
!status received 13-05-03
!priority Low
!difficulty Easy
!qualifier Clarification
!subject Missing rules for Discard_Names aspect
!summary
Discard_Names is an aspect, with typical rules.
!question
Discard_Names is not on the list of language-defined aspects and nothing in C.5 says that it can be used as an aspect name, but AARM Note C.5(6.a/3) says it is a language-defined aspect. Which is it? (It's an aspect.)
!recommendation
(See !summary.)
!wording
Change the title of C.5 to:
Aspect Discard_Names
Modify C.5(1):
Redundant[{Specifying the aspect}[A pragma] Discard_Names {can}[may] be used to request a reduction in storage used for the names of {entities with runtime name text}[certain entities].]
Add after C.5(1):
Static Semantics
An entity with runtime name text is a nonderived enumeration first subtype, a tagged first subtype, or an exception.
For an entity with runtime name text, the following language-defined representation aspect may be specified:
Discard_Names The type of aspect Discard_Names is Boolean. If directly specified, the aspect_definition shall be a static expression. If not specified (including by inheritance), the aspect is False.
[Also, make sure this aspect gets added to the index of aspects in K.1: Discard_Names -- Requests a reduction in storage for names associated with an entity.]
Modify C.5(5):
The local_name (if present) shall denote {an entity with runtime name text}[a nonderived enumeration first subtype, a tagged first subtype, or an exception]. The pragma [applies to]{specifies that the aspect Discard_Names for} the type or exception {has the value True}. Without a local_name, the pragma [applies to]{specifies that} all [such] entities {with runtime name text} declared after the pragma, within the same declarative region{ have the value True for aspect Discard_Names}. Alternatively, the pragma can be used as a configuration pragma. {If the configuration pragma Discard_Names applies to a compilation unit, all entities with runtime name text declared in the compilation unit have the value True for the aspect Discard_Names.} [If the pragma applies to a type, then it applies also to all descendants of the type.]
[Editor's note: We don't need the last sentence because normal aspect inheritance applies and has that effect.]
Modify C.5(7/2):
If the [pragma applies to]{aspect Discard_Names is True for} an enumeration type, then the semantics of the Wide_Wide_Image and Wide_Wide_Value attributes are implementation defined for that type; the semantics of Image, Wide_Image, Value, and Wide_Value are still defined in terms of Wide_Wide_Image and Wide_Wide_Value. In addition, the semantics of Text_IO.Enumeration_IO are implementation defined. If the [pragma applies to]{aspect Discard_Names is True for} a tagged type, then the semantics of the Tags.Wide_Wide_Expanded_Name function are implementation defined for that type; the semantics of Tags.Expanded_Name and Tags.Wide_Expanded_Name are still defined in terms of Tags.Wide_Wide_Expanded_Name. If the [pragma applies to]{aspect Discard_Names is True for} an exception, then the semantics of the Exceptions.Wide_Wide_Exception_Name function are implementation defined for that exception; the semantics of Exceptions.Exception_Name and Exceptions.Wide_Exception_Name are still defined in terms of Exceptions.Wide_Wide_Exception_Name.
Modify C.5(8): If the [pragma applies to]{aspect Discard_Names is True for} an entity, then the implementation should reduce the amount of storage used for storing names associated with that entity.
!discussion
The original intent was that blanket rules in 13.1 and 13.1.1 (especially 13.1.1(32/3)) would be sufficient to specify the rules for aspects associated with representation pragmas. But eventually every such pragma except this one got explicit rules. It seems weird that this solitary pragma depends on the blanket rules (enough that it failed to get added to the index of aspects).
In addition, it's not clear that the blanket rules explain what it means to specify the aspect using an aspect_specification. In particular, do the rules make the specifying the aspect to True with an aspect_specification the same as if the associated pragma applies to the entity? We sidestepped that for all other pragmas by defining the pragmas in terms of the aspects.
Finally, if we add the aspect to the aspect index, it would be bad if there was no text describing the aspect at the target of that index entry.
So, for all of these reasons, we define the aspect here, and then define the pragma in terms of the aspect in the usual way.
In doing this, an old bug was discovered, in that a configuration pragma is defined to apply to a compilation unit, not the entities defined in that unit (which is what we want here). That was corrected in these wording changes.
It is not the intent of these changes to change the effect of pragma Discard_Names (as understood, as opposed to formally defined) in any way.
!corrigendum C.5(0)
Replace the paragraph:
Pragma Discard_Names
by:
Aspect Discard_Names
!corrigendum C.5(1)
Replace the paragraph:
A pragma Discard_Names may be used to request a reduction in storage used for the names of certain entities.
by:
Specifying the aspect Discard_Names can be used to request a reduction in storage used for the names of entities with runtime name text.
Static Semantics
An entity with runtime name text is a nonderived enumeration first subtype, a tagged first subtype, or an exception.
For an entity with runtime name text, the following language-defined representation aspect may be specified:
Discard_Names
The type of aspect Discard_Names is Boolean. If directly specified, the aspect_definition shall be a static expression. If not specified (including by inheritance), the aspect is False.
!corrigendum C.5(5)
Replace the paragraph:
The local_name (if present) shall denote a nonderived enumeration [first] subtype, a tagged [first] subtype, or an exception. The pragma applies to the type or exception. Without a local_name, the pragma applies to all such entities declared after the pragma, within the same declarative region. Alternatively, the pragma can be used as a configuration pragma. If the pragma applies to a type, then it applies also to all descendants of the type.
by:
The local_name (if present) shall denote an entity with runtime name text. The pragma specifies that the aspect Discard_Names for the type or exception has the value True. Without a local_name, the pragma specifies that all entities with runtime name text declared after the pragma, within the same declarative region have the value True for aspect Discard_Names. Alternatively, the pragma can be used as a configuration pragma. If the configuration pragma Discard_Names applies to a compilation unit, all entities with runtime name text declared in the compilation unit have the value True for the aspect Discard_Names.
!corrigendum C.5(7/2)
Replace the paragraph:
If the pragma applies to an enumeration type, then the semantics of the Wide_Wide_Image and Wide_Wide_Value attributes are implementation defined for that type; the semantics of Image, Wide_Image, Value, and Wide_Value are still defined in terms of Wide_Wide_Image and Wide_Wide_Value. In addition, the semantics of Text_IO.Enumeration_IO are implementation defined. If the pragma applies to a tagged type, then the semantics of the Tags.Wide_Wide_Expanded_Name function are implementation defined for that type; the semantics of Tags.Expanded_Name and Tags.Wide_Expanded_Name are still defined in terms of Tags.Wide_Wide_Expanded_Name. If the pragma applies to an exception, then the semantics of the Exceptions.Wide_Wide_Exception_Name function are implementation defined for that exception; the semantics of Exceptions.Exception_Name and Exceptions.Wide_Exception_Name are still defined in terms of Exceptions.Wide_Wide_Exception_Name.
by:
If the aspect Discard_Names is True for an enumeration type, then the semantics of the Wide_Wide_Image and Wide_Wide_Value attributes are implementation defined for that type; the semantics of Image, Wide_Image, Value, and Wide_Value are still defined in terms of Wide_Wide_Image and Wide_Wide_Value. In addition, the semantics of Text_IO.Enumeration_IO are implementation defined. If the aspect Discard_Names is True for a tagged type, then the semantics of the Tags.Wide_Wide_Expanded_Name function are implementation defined for that type; the semantics of Tags.Expanded_Name and Tags.Wide_Expanded_Name are still defined in terms of Tags.Wide_Wide_Expanded_Name. If the aspect Discard_Names is True for an exception, then the semantics of the Exceptions.Wide_Wide_Exception_Name function are implementation defined for that exception; the semantics of Exceptions.Exception_Name and Exceptions.Wide_Exception_Name are still defined in terms of Exceptions.Wide_Wide_Exception_Name.
!corrigendum C.5(8)
Replace the paragraph:
If the pragma applies to an entity, then the implementation should reduce the amount of storage used for storing names associated with that entity.
by:
If the aspect Discard_Names is True for an entity, then the implementation should reduce the amount of storage used for storing names associated with that entity.
!ACATS Test
A test of aspect Discard_Names should be created (possibly an existing pragma test could be used as a basis).
!ASIS
No ASIS effect.
!appendix

From: Randy Brukardt
Sent: Friday, May  3, 2013  7:42 PM

AARM Note C.5(6.a/3) says:

Representation pragmas automatically specify aspects of the same name, so
Discard_Names can be used as an aspect_mark in an aspect_specification instead of
using the pragma on individual entities.

Unlike a lot of other pragmas, this one was not obsolesced because it can also act
as a configuration pragma (and there is no such thing as a configuration aspect -
what would it be an aspect of?). As such, the text of this subclause was unchanged
from Ada 2005.

However, I note that this aspect didn't make it into the list of language-defined
aspects, presumably because there is no text defining that it exists (unlike
virtually every other aspect).

I presume that its being omitted from the list of language-defineed aspects is an
oversight. However, it probably would be good to put some text in C.5 mentioning
that this aspect exists. Otherwise, someone coming from the list of aspects to C.5
is going to be mightly confused (the rule that makes it exist is in 13.1, after
all).

Thoughts? If there is agreement that this should be done, I'll propose some wording
and write up a ramification AI to do it. (It's a bit more than a pure presentation
change; I'd write it as a confirmation AI, but those don't allow any associated
wording changes.)

****************************************************************

From: Randy Brukardt
Sent: Saturday, June 15, 2013  9:14 AM

Here is an attempt at the wording for the Discard_Names AI [this is version
/02 - ED]; I need a nice term to use, however. Ideas welcome.

****************************************************************

From: Randy Brukardt
Sent: Saturday, June 15, 2013  12:09 PM

Here is wording using "entities with runtime name text" as decided earlier
today. It looks good to me. [This is version /03 of the AI - ED]

****************************************************************


Questions? Ask the ACAA Technical Agent