Version 1.31 of ai05s/ai05-0183-1.txt

Unformatted version of ai05s/ai05-0183-1.txt version 1.31
Other versions for file ai05s/ai05-0183-1.txt

!standard 3.2.1(3)          11-04-19 AI05-0183-1/13
!standard 3.2.2(2)
!standard 3.3.1(2/2)
!standard 3.8(6)
!standard 3.9.3(1.1/2)
!standard 6.1(2/2)
!standard 6.3(2/2)
!standard 6.7(2/2)
!standard 9.5.2(2/2)
!standard 7.1(3)
!standard 7.3(2)
!standard 7.3(3)
!standard 8.2(10.1/2)
!standard 8.3(23.1/2)
!standard 8.5.1(2/2)
!standard 8.5.2(2)
!standard 8.5.3(2)
!standard 8.5.4(2/2)
!standard 8.5.5(2)
!standard 9.1(2/2)
!standard 9.1(3/2)
!standard 9.4(2/2)
!standard 9.4(3/2)
!standard 9.5.2(2/2)
!standard 11.1(2)
!standard 12.1(3)
!standard 12.3(2/2)
!standard 12.4(2/2)
!standard 12.5(2)
!standard 12.6(2.1/2)
!standard 12.6(2.2/2)
!standard 12.7(2)
!standard 13.1(0.1/2)
!standard 13.1(8.1/1)
!standard 13.1(9)
!standard 13.1(9.1/1)
!standard 13.1(11/2)
!standard 13.1.1(0)
!standard 13.1(15.1/2)
!standard 13.3(5/1)
!standard 13.3(73.1/1)
!standard 13.13.2(1/1)
!standard 13.14(7.1/2)
!standard 13.14(8/2)
!class amendment 09-11-01
!status Amendment 2012 10-09-01
!status ARG Approved (by Letter Ballot) 10-1-0 11-05-16
!status work item 10-11-19
!status ARG Approved 8-0-2 10-10-29
!status work item 09-11-01
!status received 09-11-01
!priority Medium
!difficulty Medium
!subject Aspect Specifications
!summary
To support the specification of pre- and postconditions, as well as invariants on types and objects, we propose a general notation for specifying "aspects" of an entity as part of its declaration, rather than with a separate aspect clause.
!problem
There is a desire to be able to specify "aspects" of subprograms such as pre- and postconditions. Unfortunately, specifying aspects for subprograms using a pragma or an attribute_definition_clause is generally awkward in Ada, because subprograms can be overloaded. Having to insert a local renaming simply to provide a unique name is verbose, and at least in some cases, the aspect to be specified belongs in close proximity with the declaration. More generally, specifying attributes or other aspects of an entity with a separate clause or pragma is not always desirable, as the aspect may be integral to the appropriate use of the entity.
!proposal
We propose to allow certain aspects of an entity to be specified as part of the declaration of the entity, using an aspect_specification that is placed immediately in front of the semicolon ending the declaration:
aspect_specification ::= with aspect_mark [=> expression] {, aspect_mark [=> expression] }
The aspect_specification is an optional element in the following kinds of declarations:
* object_declaration;
* full_type_declaration;
* subtype_declaration;
* component_declaration;
* subprogram_declaration;
* abstract_subprogram_declaration;
* null_procedure_declaration;
* subprogram_body;
* package_declaration;
* private_type_declaration;
* private_extension_declaration;
* renaming_declaration;
* task_type_declaration;
* single_task_declaration;
* protected_type_declaration;
* single_protected_declaration;
* entry_declaration;
* exception_declaration;
* generic_declaration;
* generic_instantiation;
* generic_formal_parameter_declaration.
At most one occurrence of each aspect is allowed within a single aspect_specification. The named aspect must be an aspect that can be specified for the given kind of entity.
The names in the expressions of an aspect_specification are resolved not at the point of the associated declaration, but rather at the end of the immediately enclosing declaration list, or the first freezing point, whichever comes first. If the aspect_specification occurs within a visible part, declarations occuring after the freezing point or within the corresponding private part are not considered.
The expression may be omitted only when the aspect is of a boolean type, in which case it is equivalent to being specified as True.
!wording
Replace 3.2.1(3) by:
full_type_declaration ::= type defining_identifier [known_discriminant_part] is type_definition [aspect_specification];
| task_type_declaration | protected_type_declaration
Replace 3.2.2(2) by:
subtype_declaration ::= subtype defining_identifier is subtype_indication [aspect_specification];
Replace 3.3.1(2/2) by:
object_declaration ::= defining_identifier_list : [aliased] [constant] subtype_indication [:= expression] [aspect_specification]; | defining_identifier_list : [aliased] [constant] access_definition [:= expression] [aspect_specification]; | defining_identifier_list : [aliased] [constant] array_type_definition [:= expression] [aspect_specification]; | single_task_declaration | single_protected_declaration
Replace 3.8(6) by:
component_declaration ::= defining_identifier_list : component_definition [:= default_expression] [aspect_specification];
Replace 3.9.3(1.1/2) by:
abstract_subprogram_declaration ::= [overriding_indicator] subprogram_specification is abstract [aspect_specification];
Replace 6.1(2/2) by:
subprogram_declaration ::= [overriding_indicator] subprogram_specification [aspect_specification];
Replace 6.3(2/2) by:
subprogram_body ::= [overriding_indicator] subprogram_specification [aspect_specification] is declarative_part begin handled_sequence_of_statements end [designator];
Replace 6.7(2/2) by:
null_procedure_declaration ::= [overriding_indicator] procedure_specification is null [aspect_specification];
Replace 7.1(3) by:
package_specification ::= package defining_program_unit_name [aspect_specification] is {basic_declarative_item} [private {basic_declarative_item}] end [[parent_unit_name.]identifier]
Replace 7.3(2) by:
private_type_declaration ::= type defining_identifier [discriminant_part] is [[abstract] tagged] [limited] private [aspect_specification];
Replace 7.3(3/2) by:
private_extension_declaration ::= type defining_identifier [discriminant_part] is [abstract] [limited | synchronized] new ancestor_subtype_indication [and interface_list] with private [aspect_specification];
Modify 8.2(10.1/2):
The scope of an attribute_definition_clause is identical to the scope of a declaration that would occur at the point of the attribute_definition_clause. {The scope of an aspect_specification is identical to the scope of the associated declaration.}
Modify 8.3(23.1/2):
An attribute_definition_clause {or an aspect_specification} is visible everywhere within its scope.
Replace 8.5.1(2/2) by:
object_renaming_declaration ::= defining_identifier : [null_exclusion] subtype_mark renames object_name [aspect_specification]; | defining_identifier : access_definition renames object_name [aspect_specification];
Replace 8.5.2(2) by:
exception_renaming_declaration ::= defining_identifier : exception renames exception_name [aspect_specification];
Replace 8.5.3(2) by:
package_renaming_declaration ::= package defining_program_unit_name renames package_name [aspect_specification];
Replace 8.5.4(2/2) by:
subprogram_renaming_declaration ::= [overriding_indicator] subprogram_specification renames callable_entity_name [aspect_specification];
Replace 8.5.5(2) by:
generic_renaming_declaration ::= generic package defining_program_unit_name renames generic_package_name [aspect_specification]; | generic procedure defining_program_unit_name renames generic_procedure_name [aspect_specification]; | generic function defining_program_unit_name renames generic_function_name [aspect_specification];
Replace 9.1(2/2) by:
task_type_declaration ::= task type defining_identifier [known_discriminant_part] [aspect_specification] [is [new interface_list with] task_definition];
Replace 9.1(3/2) by:
single_task_declaration ::= task defining_identifier [aspect_specification] [is [new interface_list with] task_definition];
Replace 9.4(2/2) by:
protected_type_declaration ::= protected type defining_identifier [known_discriminant_part] [aspect_specification] is [new interface_list with] protected_definition;
Replace 9.4(3/2) by:
single_protected_declaration ::= protected defining_identifier [aspect_specification] is [new interface_list with] protected_definition;
Replace 9.5.2(2/2) by:
entry_declaration ::= [overriding_indicator] entry defining_identifier [(discrete_subtype_definition)] parameter_profile [aspect_specification];
Replace 11.1(2) by:
exception_declaration ::= defining_identifier_list : exception [aspect_specification];
Replace 12.1(3) by:
generic_subprogram_declaration ::= generic_formal_part subprogram_specification [aspect_specification];
[AARM NOTE: a generic package can have an aspect_specification because a package_specification allows an aspect_specification.]
Replace 12.3(2/2) by:
generic_instantiation ::= package defining_program_unit_name is new generic_package_name [generic_actual_part] [aspect_specification]; | [overriding_indicator] procedure defining_program_unit_name is new generic_procedure_name [generic_actual_part] [aspect_specification]; | [overriding_indicator] function defining_designator is new generic_function_name [generic_actual_part] [aspect_specification];
Replace 12.4(2/2) by:
formal_object_declaration ::= defining_identifier_list : mode [null_exclusion] subtype_mark [:= default_expression] [aspect_specification]; | defining_identifier_list : mode access_definition [:= default_expression] [aspect_specification];
Replace 12.5(2) by:
formal_type_declaration ::= type defining_identifier[discriminant_part] is formal_type_definition [aspect_specification];
Replace 12.6(2.1/2-2.2/2) by:
formal_concrete_subprogram_declaration ::= with subprogram_specification [is subprogram_default] [aspect_specification];
formal_abstract_subprogram_declaration ::= with subprogram_specification is abstract [subprogram_default] [aspect_specification];
Replace 12.7(2) by:
formal_package_declaration ::= with package defining_identifier is new generic_package_name formal_package_actual_part [aspect_specification];
Add the following at the end of 13.1(0.1/1):
In addition to representation and operational items, aspects of entities may be specified using an aspect_specification (see 13.3.1), which is an optional element of certain kinds of declarations.
Modify 13.1(8.1/1) as follows:
An operational item directly specifies an operational aspect of the [type of the subtype]{entity} denoted by the local_name{, except in the case of a type-related operational item, whose local_name shall denote a first subtype, and which directly specifies an aspect of the type of the subtype.} [The local_name of an operational item shall denote a first subtype. An operational item that names a subtype is type-related.]
Modify 13.1(9, 9.1/1) as follows:
A representation item that directly specifies an aspect of a subtype or type shall appear after the type is completely defined (see 3.11.1), and before the subtype or type is frozen (see 13.14). If a representation item {or aspect_specification} is given that directly specifies an aspect of an entity, then it is illegal to give another representation item {or aspect_specification} that directly specifies the same aspect of the entity.
An operational item that directly specifies an aspect of [a type]{an entity} shall appear before the [type]{entity} is frozen (see 13.14). If an operational item {or aspect_specification} is given that directly specifies an aspect of [a type]{an entity}, then it is illegal to give another operational item {or aspect_specification} that directly specifies the same aspect of the [type]{entity}.
Modify 13.1(15.1/2) as follows:
In contrast, whether operational aspects are inherited by a[n untagged] derived type depends on each specific aspect{; unless specified, an operational aspect is not inherited}. [[Operational aspects are never inherited for a tagged type.]] When operational aspects are inherited by a[n untagged] derived type, aspects that were directly specified by operational items that are visible at the point of the derived type declaration, or (in the case where the parent is derived) that were inherited by the parent type from the grandparent type are inherited. An inherited operational aspect is overridden by a subsequent operational item that specifies the same aspect of the type.
Revise 13.3(5/1) as follows:
... Each specifiable attribute constitutes an operational aspect or aspect of representation{; the name of the aspect is that of the attribute}.
Modify 13.3(73.1/1) as follows:
The following {type-related} operational attribute is defined: External_Tag.
Add the following section:
13.3.1 Aspect Specifications
[Redundant: Certain representation or operational aspects of an entity may be specified as part of its declaration using an aspect_specification, rather than using a separate representation or operational item.] The declaration with the aspect_specification is termed the associated declaration.
Syntax
aspect_specification ::= with aspect_mark [=> aspect_definition] {, aspect_mark [=> aspect_definition] }
aspect_mark ::= aspect_identifier['Class]
aspect_definition ::= name | expression | identifier
AARM NOTE: The aspect_specification is an optional element
in most kinds of declarations. Here is a list of all kinds of declarations and an indication of whether or not they allow aspect clauses, and in some cases a short discussion of why (* = allowed, NO = not allowed)
basic_declaration
type_declaration full_type_declaration*
... task_type_declaration* protected_type_declaration* incomplete_type_declaration -- NO private_type_declaration* private_extension_declaration* subtype_declaration* object_declaration*
... single_task_declaration* single_protected_declaration* number_declaration -- NO subprogram_declaration* abstract_subprogram_declaration* null_procedure_declaration* package_declaration* renaming_declaration* -- There are no -- language-defined aspects specifiable on renames. exception_declaration* generic_declaration* generic_instantiation*
enumeration_literal_specification -- NO discriminant_specification -- NO component_declaration* loop_parameter_specification -- NO parameter_specification -- NO subprogram_body -- NO entry_declaration* entry_index_specification -- NO choice_parameter_specification -- NO generic_formal_parameter_declaration
-- There are no language-defined aspects that may be -- specified on generic formals, but implementations might support some. formal_object_declaration* formal_type_declaration* formal_subprogram_declaration formal_concrete_subprogram_declaration* formal_abstract_subprogram_declaration* formal_package_declaration*
extended_return_statement -- NO
end of AARM Note.
Name Resolution
An aspect_mark identifies an aspect of the entity defined by the associated declaration (the associated entity); the aspect denotes an object, a value, an expression, a subprogram, or some other kind of entity. If the aspect_mark identifies:
* an aspect that denotes an object, the aspect_definition shall be a name; the expected type for the name is the type of the identified aspect of the associated entity;
* an aspect that is a value or an expression, the aspect_definition shall be an expression; the expected type for the expression is the type of the identified aspect of the associated entity;
* an aspect that denotes a subprogram, the aspect_definition shall be a name; the expected profile for the name is the profile required for the aspect of the associated entity;
* an aspect that denotes some other kind of entity, the aspect_definition shall be a name, and the name shall resolve to denote an entity of the appropriate kind;
* an aspect that is given by an identifier specific to the aspect, the aspect_definition shall be an identifier, and the identifier shall be one of the identifiers specific to the identified aspect.
The usage names in an aspect_definition [Redundant: are not resolved at the point of the associated declaration, but rather] are resolved at the end of the immediately enclosing declaration list.
If the associated declaration is for a subprogram or entry, the names of the formal parameters are directly visible within the aspect_definition, as are certain attributes, as specified elsewhere in this International Standard for the identified aspect. If the associated declaration is a type_declaration, within the aspect_definition the names of any visible components, protected subprograms, and entries are directly visible, and the name of the first subtype denotes the current instance of the type (see 8.6). If the associated declaration is a subtype_declaration, within the aspect_definition the name of the new subtype denotes the current instance of the subtype.
Legality Rules
If the first freezing point of the associated entity comes before the end of the immediately enclosing declaration list, then each usage name in the aspect_definition shall resolve to the same entity at the first freezing point as it does at the end of the immediately enclosing declaration list.
At most one occurrence of each aspect_mark is allowed within a single aspect_specification. The aspect identified by the aspect_mark shall be an aspect that can be specified for the associated entity (or view of the entity defined by the associated declaration).
The aspect_definition associated with a given aspect_mark may be omitted only when the aspect_mark identifies an aspect of a boolean type, in which case it is equivalent to the aspect_definition being specified as True.
If the aspect_mark includes 'Class, then the associated entity shall be a tagged type or a primitive subprogram of a tagged type.
Static Semantics
Depending on which aspect is identified by the aspect_mark, an aspect_definition specifies:
* a name that denotes a subprogram, object, or other kind of entity;
* an expression, which is either evaluated to produce a single
value, or which (as in a precondition) is to be evaluated at particular points during later execution; or
* an identifier specific to the aspect.
The identified aspect of the associated entity, or in some cases, the view of the entity defined by the declaration, is as specified by the aspect_definition (or by the default of True when boolean). Whether an aspect_specification applies to an entity or only to the particular view of the entity defined by the declaration is determined by the aspect_mark and the kind of entity. The following aspects are view specific:
* An aspect specified on an object_declaration;
* An aspect specified on a subprogram_declaration;
* An aspect specified on a renaming_declaration.
All other aspect_specifications are associated with the entity, and apply to all views of the entity, unless otherwise specified in this International Standard.
If the aspect_mark includes 'Class, then:
* if the associated entity is a tagged type, the specification applies to all descendants of the type;
* if the associated entity is a primitive subprogram of a tagged type T, the specification applies to the corresponding primitive subprogram of all descendants of T.
All specifiable operational and representation attributes may be specified with an aspect_specification instead of an attribute_definition_clause (see 13.3). The attribute_designator is used for the aspect_mark. In addition, certain other operational and representation aspects not associated with specifiable attributes may be specified, as specified elsewhere in this International Standard. In the case of aspects specifiable with pragmas, the pragma identifier is used for the aspect_mark, unless otherwise specified in this International Standard.
If an aspect of a derived type is inherited from an ancestor type and has the boolean value True, the inherited value shall not be overridden to have the value False for the derived type, unless otherwise specified in this International Standard.
If a Legality Rule or Static Semantics rule only applies when a particular aspect has been specified, the aspect is considered to have been specified only when the aspect_specification or attribute_definition_clause is visible (see 8.3) at the point of the application of the rule.
AARM Reason: Some rules only apply when an aspect has been specified (for instance, an indexable type is one that has aspect Variable_Indexing specified). In order to prevent privacy breaking, this can only be true when the specification of the aspect is visible. In particular, if the Variable_Indexing aspect is specified on the full view of a private type, the private type is not considered an indexable type.
There are no language-defined aspects that may be specified on a renaming_declaration or on a formal_type_declaration.
AARM Discussion: Implementation-defined aspects can be allowed on these, of course; the implementation will need to define the semantics. In particular, the implementation will need to define actual type matching rules for any aspects allowed on formal types; there are no default matching rules defined by the language.
An aspect shall not be specified in an aspect_specification given on a subprogram_body that is a completion of another declaration.
AARM Reason: Most aspects (for example, preconditions) are intended to be available to callers, and specifying them on a body that has a separate declaration hides them from callers. Specific aspects (both language-defined and implementation-defined) may allow this, but they have to do so explicitly (by appealing the following rule or the Implementation Permission), and provide any needed rules about visibility.
[Note: We write this in terms of specifying an aspect, rather than simply saying that an aspect_specification is not allowed, so that specific aspects can allow this.]
Alternative legality and semantics rules may apply for particular aspects, as specified elsewhere in this International Standard.
Dynamic Semantics
At the freezing point of the associated entity, the aspect_specification is elaborated. The elaboration of the aspect_specification includes the evaluation of the name or expression, if any, unless the aspect itself is an expression. If the corresponding aspect represents an expression (as in a precondition), the elaboration has no effect; the expression is evaluated later at points within the execution as specified elsewhere in this International Standard for the particular aspect.
Implementation Permissions
Implementations may support implementation-defined aspects. The aspect_specification for an implementation-defined aspect may use an implementation-defined syntax for the aspect_definition, and may follow implementation-defined legality and semantics rules.
AARM Discussion: The intent is to allow implementations to support aspects that are defined, for example, by a subtype_indication rather than an expression or a name. We chose not to try to enumerate all possible aspect_definition syntaxes, but to give implementations maximum freedom.
Modify 13.13.2(1/1):
The {type-related} operational attributes Write, Read, Output, and Input attributes convert values to a stream of elements and reconstruct values from a stream.
Add after 13.14(7.1/2):
* At the freezing point of the entity associated with an aspect_specification,
any expressions or names within the aspect_specification cause freezing. Any static expressions within an aspect_specification also cause freezing at the end of the immediately enclosing declaration list.
Modify 13.14(8/3):
A static expression {(other than within an aspect_specification)} causes freezing where it occurs. An object name or nonstatic expression causes freezing where it occurs, unless the name or expression is part of a default_expression, a default_name, the expression of an expression function{, an aspect_specification,} or a per-object expression of a component's constraint, in which case, the freezing occurs later as part of another construct {or at the freezing point of an associated entity}.
!discussion
This syntax was invented to allow pre- and postconditions to be specified for subprograms without worrying about overloading, and without resorting to pragmas. The syntax allows additional aspect names to be added without introducing additional reserved words. Various uses are imagined over and above pre- and postconditions. Here are a number of examples:
function Pop(S : in out Stack) return Elem with Pre => not Is_Empty(S), Post => not Is_Full(S);
type Atomic_Array is array(Positive range <>) of Natural with Atomic_Components;
type Set is interface with Invariant'Class => (Is_Empty(X)) = (Count(X) = 0);
function Union(X, Y : Set) return Set is abstract with Post'Class => Count(Union'Result) = Count(X) + Count(Y);
type R is record X : Positive := 0 with Independent => True; Y : Natural := 77 with Atomic => True; end record;
type Shared_Bit_Vector is array(0..15) of Boolean with Packing, Independent_Components;
type Bit_Vector is array(0..15) of Boolean with Component_Size => 1;
This presumes that aspect identifiers generally match attribute names or pragma names. We considered, in the case of pragmas, choosing nouns rather than adjectives for aspect names, so the names might work better after the preposition "with". Hence, we considered "Atomicity" or "Independence" rather than "Atomic" and "Independent." However, that seemed to be introducing unnecessary complexity, and adding "=> True" makes the adjectives work grammatically, so by default the aspect name will be presumed to be the same as the pragma. Pragma Pack currently specifies that its aspect is "packing," but we might want to change that for consistency. See AI05-0112-1.
We use "'Class" as an indication that the aspect specification applies to all descendants of the type, or for a subprogram, the corresponding primitive subprogram for all descendants of the type. Other alternatives would be names such as "Inherited_Pre", but Pre'Class meaning it applies to T'Class seems more natural.
We defer resolving the names in the aspect_definition to end of the enclosing declaration list because in many cases the entities referenced in the aspect_definition will necessarily, or more conveniently, be declared after the entity with the aspect specification. For example, for a type, any aspect that refers to an operation of the type will be a forward reference. For a subprogram, an aspect that refers to another subprogram will often be a forward reference, as ordering the subprograms based on the aspect_definitions would be painful and sometimes impossible.
If the freezing point comes before the end of the enclosing declaration list, we require the usage names in the aspect_definition to resolve to the same entities at the two places. Because there is no explicit indication of where a freezing point occurs in the source, we felt it would be too confusing if we didn't require this. This means that if a freezing point "moves" and thereby crosses over, for example, the overriding of an inherited subprogram (of a non-tagged type), the compiler would complain rather than silently reinterpreting the name in the aspect_definition. For example:
type New_T is new T with Type_Invariant => Is_Valid(New_T);
Default_Obj : New_T; -- Here we freeze New_T
function Is_Valid(Y : New_T) return Boolean; -- Here we override Is_Valid
private -- Here we reach the end of the declaration list.
In a case like this, the user almost certainly wants to refer to the overriding of Is_Valid, but since the freezing happens before the overriding, without the rule to require that the names in the aspect_definition resolve to the same thing, they would not get what they expected. With this rule, the compiler would complain, and the user would (hopefully ;-) realize they need to move the declaration of Default_Obj down a little further so Is_Valid can be overridden first.
We don't bother talking about the case of a declaration with multiple defining_identifiers in its defining_identifier_list, because RM 3.3.1(7) already says such a multi-defining-identifier declaration is equivalent to a sequence of single-defining-identifier declarations.
Much of the semantics is left to the particular aspects, as it is hard to talk about such things in a general way. Implementations are permitted maximum freedom in defining their own aspects.
!corrigendum 3.2.1(3)
Replace the paragraph:
full_type_declaration ::= type defining_identifier [known_discriminant_part] is type_definition; | task_type_declaration | protected_type_declaration
by:
full_type_declaration ::= type defining_identifier [known_discriminant_part] is type_definition [aspect_specification]; | task_type_declaration | protected_type_declaration
!corrigendum 3.2.2(2)
Replace the paragraph:
subtype_declaration ::= subtype defining_identifier is subtype_indication;
by:
subtype_declaration ::= subtype defining_identifier is subtype_indication [aspect_specification];
!corrigendum 3.3.1(2/2)
Replace the paragraph:
object_declaration ::= defining_identifier_list : [aliased] [constant] subtype_indication [:= expression]; | defining_identifier_list : [aliased] [constant] access_definition [:= expression]; | defining_identifier_list : [aliased] [constant] array_type_definition [:= expression]; | single_task_declaration | single_protected_declaration
by:
object_declaration ::= defining_identifier_list : [aliased] [constant] subtype_indication [:= expression] [aspect_specification]; | defining_identifier_list : [aliased] [constant] access_definition [:= expression] [aspect_specification]; | defining_identifier_list : [aliased] [constant] array_type_definitirn [:= expression] [aspect_specification]; | single_task_declaration | single_protected_declaration
!corrigendum 3.8(6)
Replace the paragraph:
component_declaration ::= defining_identifier_list : component_definition [:= default_expr ssion];
by:
component_declaration ::= defining_identifier_list : component_definition [:= default_expression] [aspect_specification];
!corrigendum 3.9.3(1.1/2)
Replace the paragraph:
abstract_subprogram_declaration ::= [overriding_indicator] subprogram_specification is abstract;
by:
abstract_subprogram_declaration ::= [overriding_indicator] subprogram_specification is abstract [aspect_specification];
!corrigendum 6.1(2/2)
Replace the paragraph:
subprogram_declaration ::= [overriding_indicator] subprogram_specification;
by:
subprogram_declaration ::= [overriding_indicator] subprogram_specification [aspect_specification];
!corrigendum 6.3(2/2)
Replace the paragraph:
subprogram_body ::= [overriding_indicator] subprogram_specification is declarative_part begin handled_sequence_of_statements end [designator];
by:
subprogram_body ::= [overriding_indicator] subprogram_specification [aspect_specification] is declarative_part begin handled_sequence_of_statements end [designator];
!corrigendum 6.7(2/2)
Replace the paragraph:
null_procedure_declaration ::= [overriding_indicator] procedure_specification is null;
by:
null_procedure_declaration ::= [overriding_indicator] procedure_specification is null [aspect_specification];
!corrigendum 7.1(3)
Replace the paragraph:
package_specification ::= package defining_program_unit_name is {basic_declarative_item} [private {basic_declarative_item}] end [[parent_unit_name.]identifier]
by:
package_specification ::= package defining_program_unit_name [aspect_specification] is {basic_declarative_item} [private {basic_declarative_item}] end [[parent_unit_name.]identifier]
!corrigendum 7.3(2)
Replace the paragraph:
private_type_declaration ::= type defining_identifier [discriminant_part] is [[abstract] tagged] [limited] private;
by:
private_type_declaration ::= type defining_identifier [discriminant_part] is [[abstract] tagged] [limited] private [aspect_specification];
!corrigendum 7.3(3/2)
Replace the paragraph:
private_extension_declaration ::= type defining_identifier [discriminant_part] is [abstract] [limited | synchronized] new ancestor_subtype_indication [and interface_list] with private;
by:
private_extension_declaration ::= type defining_identifier [discriminant_part] is [abstract] [limited | synchronized] new ancestor_subtype_indication [and interface_list] with private [aspect_specification];
!corrigendum 8.2(10.1/2)
Replace the paragraph:
The scope of an attribute_definition_clause is identical to the scope of a declaration that would occur at the point of the attribute_definition_clause.
by:
The scope of an attribute_definition_clause is identical to the scope of a declaration that would occur at the point of the attribute_definition_clause. The scope of an aspect_specification is identical to the scope of the associated declaration.
!corrigendum 8.3(23.1/2)
Replace the paragraph:
An attribute_definition_clause is visible everywhere within its scope.
by:
An attribute_definition_clause or an aspect_specification is visible everywhere within its scope.
!corrigendum 8.5.1(2/2)
Replace the paragraph:
object_renaming_declaration ::= defining_identifier : [null_exclusion] subtype_mark renames object_name; | defining_identifier : access_definition renames object_name;
by:
object_renaming_declaration ::= defining_identifier : [null_exclusion] subtype_mark renames object_name [aspect_specification]; | defining_identifier : access_definition renames object_name [aspect_specification];
!corrigendum 8.5.2(2)
Replace the paragraph:
exception_renaming_declaration ::= defining_identifier : exception renames exception_name;
by:
exception_renaming_declaration ::= defining_identifier : exception renames exception_name [aspect_specification];
!corrigendum 8.5.2(3)
Replace the paragraph:
package_renaming_declaration ::= package defining_program_unit_name renames package_
name;>
by:
package_renaming_declaration ::= package defining_program_unit_name renames package_
name [aspect_specification];>
!corrigendum 8.5.4(2/2)
Replace the paragraph:
subprogram_renaming_declaration ::= [overriding_indicator] subprogram_specification renames callable_entity_name;
by:
subprogram_renaming_declaration ::= [overriding_indicator] subprogram_specification renames callable_entity_name; [aspect_specification];
!corrigendum 8.5.5(2)
Replace the paragraph:
generic_renaming_declaration ::= generic package defining_program_unit_name renames generic_package_name; | generic procedure defining_program_unit_name renames generic_procedure_name; | generic function defining_program_unit_name renames generic_function_name;
by:
generic_renaming_declaration ::= generic package defining_program_unit_name renames generic_package_name [aspect_specification]; | generic procedure defining_program_unit_name renames generic_procedure_name [aspect_specification]; | generic function defining_program_unit_name renames generic_function_name [aspect_specification];
!corrigendum 9.1(2/2)
Replace the paragraph:
task_type_declaration ::= task type defining_identifier [known_discriminant_part] [is [new interface_list with] task_definition];
by:
task_type_declaration ::= task type defining_identifier [known_discriminant_part] [aspect_specification] [is [new interface_list with] task_definition];
!corrigendum 9.1(3/2)
Replace the paragraph:
single_task_declaration ::= task defining_identifier [is [new interface_list with] task_definition];
by:
single_task_declaration ::= task defining_identifier [aspect_specification] [is [new interface_list with] task_definition];
!corrigendum 9.4(2/2)
Replace the paragraph:
protected_type_declaration ::= protected type defining_identifier [known_discriminant_part] is [new interface_list with] protected_definition;
by:
protected_type_declaration ::= protected type defining_identifier [known_discriminant_part] [aspect_specification] is [new interface_list with] protected_definition;
!corrigendum 9.4(3/2)
Replace the paragraph:
single_protected_declaration ::= protected defining_identifier is [new interface_list with] protected_definition;
by:
single_protected_declaration ::= protected defining_identifier [aspect_specification] is [new interface_list with] protected_definition;
!corrigendum 9.5.2(2/2)
Replace the paragraph:
entry_declaration ::= [overriding_indicator] entry defining_identifier [(discrete_subtype_definition)] parameter_profile;
by:
entry_declaration ::= [overriding_indicator] entry defining_identifier [(discrete_subtype_definition)] parameter_profile [aspect_specification];
!corrigendum 11.1(2)
Replace the paragraph:
exception_declaration ::= defining_identifier_list : exception;
by:
exception_declaration ::= defining_identifier_list : exception [aspect_specification];
!corrigendum 12.1(3)
Replace the paragraph:
generic_subprogram_declaration ::= generic_formal_part subprogram_specification [aspect_specification];
by:
generic_subprogram_declaration ::= generic_formal_part subprogram_specification [aspect_specification];
!corrigendum 12.3(2/2)
Replace the paragraph:
generic_instantiation ::= package defining_program_unit_name is new generic_package_name [generic_actual_part]; | [overriding_indicator] procedure defining_program_unit_name is new generic_procedure_name [generic_actual_part]; | [overriding_indicator] function defining_designator is new generic_function_name [generic_actual_part];
by:
generic_instantiation ::= package defining_program_unit_name is new generic_package_name [generic_actual_part] [aspect_specification]; | [overriding_indicator] procedure defining_program_unit_name is new generic_procedure_name [generic_actual_part] [aspect_specification]; | [overriding_indicator] function defining_designator is new generic_function_name [generic_actual_part] [aspect_specification];
!corrigendum 12.4(2/2)
Replace the paragraph:
formal_object_declaration ::= defining_identifier_list : mode [null_exclusion] subtype_mark [:= default_expression]; | defining_identifier_list : mode access_definition [:= default_expression];
by:
formal_object_declaration ::= defining_identifier_list : mode [null_exclusion] subtype_mark [:= default_expression] [aspect_specification]; | defining_identifier_list : mode access_definition [:= default_expression] [aspect_specification];
!corrigendum 12.5(2)
Replace the paragraph:
formal_type_declaration ::= type defining_identifier[discriminant_part] is formal_type_definition;
by:
formal_type_declaration ::= type defining_identifier[discriminant_part] is formal_type_definition [aspect_specification];
!corrigendum 12.6(2.1/2)
Replace the paragraph:
formal_concrete_subprogram_declaration ::= with subprogram_specification [is subprogram_default];
by:
formal_concrete_subprogram_declaration ::= with subprogram_specification [is subprogram_default] [aspect_specification];
!corrigendum 12.6(2.2/2)
Replace the paragraph:
formal_abstract_subprogram_declaration ::= with subprogram_specification is abstract [subprogram_default];
by:
formal_abstract_subprogram_declaration ::= with subprogram_specification is abstract [subprogram_default] [aspect_specification];
!corrigendum 12.7(2)
Replace the paragraph:
formal_package_declaration ::= with package defining_identifier is new generic_package_name formal_package_actual_part;
by:
formal_package_declaration ::= with package defining_identifier is new generic_package_name formal_package_actual_part [aspect_specification];
!corrigendum 13.1(0.1/1)
Replace the paragraph:
Representation and operational items can be used to specify aspects of entities. Two kinds of aspects of entities can be specified: aspects of representation and operational aspects. Representation items specify how the types and other entities of the language are to be mapped onto the underlying machine. Operational items specify other properties of entities.
by:
Representation and operational items can be used to specify aspects of entities. Two kinds of aspects of entities can be specified: aspects of representation and operational aspects. Representation items specify how the types and other entities of the language are to be mapped onto the underlying machine. Operational items specify other properties of entities. In addition to representation and operational items, aspects of entities may be specified using an aspect_specification (see 13.3.1), which is an optional element of certain kinds of declarations.
!corrigendum 13.1(8.1/1)
Replace the paragraph:
An operational item directly specifies an operational aspect of the type of the subtype denoted by the local_name. The local_name of an operational item shall denote a first subtype. An operational item that names a subtype is type-related.
by:
An operational item directly specifies an operational aspect of the entity denoted by the local_name, except in the case of a type-related operational item, whose local_name shall denote a first subtype, and which directly specifies an aspect of the type of the subtype.
!corrigendum 13.1(9)
Replace the paragraph:
A representation item that directly specifies an aspect of a subtype or type shall appear after the type is completely defined (see 3.11.1), and before the subtype or type is frozen (see 13.14). If a representation item is given that directly specifies an aspect of an entity, then it is illegal to give another representation item that directly specifies the same aspect of the entity.
by:
A representation item that directly specifies an aspect of a subtype or type shall appear after the type is completely defined (see 3.11.1), and before the subtype or type is frozen (see 13.14). If a representation item or aspect_specification is given that directly specifies an aspect of an entity, then it is illegal to give another representation item or aspect_specification that directly specifies the same aspect of the entity.
!corrigendum 13.1(9.1/1)
Replace the paragraph:
An operational item that directly specifies an aspect of a type shall appear before the type is frozen (see 13.14). If an operational item is given that directly specifies an aspect of a type, then it is illegal to give another operational item that directly specifies the same aspect of the type.
by:
An operational item that directly specifies an aspect of an entity shall appear before the entity is frozen (see 13.14). If an operational item or aspect_specification is given that directly specifies an aspect of an entity, then it is illegal to give another operational item or aspect_specification that directly specifies the same aspect of the entity.
!corrigendum 13.1(15.1/2)
Replace the paragraph:
In contrast, whether operational aspects are inherited by an untagged derived type depends on each specific aspect. Operational aspects are never inherited for a tagged type. When operational aspects are inherited by an untagged derived type, aspects that were directly specified by operational items that are visible at the point of the derived type declaration, or (in the case where the parent is derived) that were inherited by the parent type from the grandparent type are inherited. An inherited operational aspect is overridden by a subsequent operational item that specifies the same aspect of the type.
by:
In contrast, whether operational aspects are inherited by a derived type depends on each specific aspect; unless specified, an operational aspect is not inherited. When operational aspects are inherited by a derived type, aspects that were directly specified by operational items that are visible at the point of the derived type declaration, or (in the case where the parent is derived) that were inherited by the parent type from the grandparent type are inherited. An inherited operational aspect is overridden by a subsequent operational item that specifies the same aspect of the type.
!corrigendum 13.1.1(0)
!comment Moved by AI05-0295-1.
@dinsc
Certain representation or operational aspects of an entity may be specified as part of its declaration using an @fa<aspect_specification>, rather than using a separate representation or operational item. The declaration with the @fa<aspect_specification> is termed the @i<associated declaration>.
@i<@s8<Syntax>>
@xcode<@fa<aspect_specification ::=
>@b<@ft<with>>@fa< aspect_mark [=@> aspect_definition] {,
aspect_mark [=@> aspect_definition] }>>
@xcode<@fa<aspect_mark ::= >@i<@ft<aspect_>>@fa<identifier['>@ft<Class>@fa<]>>
@xcode<@fa<aspect_definition ::= name | expression | identifier>>
@i<@s8<Name Resolution Rules>>
An @fa<aspect_mark> identifies an aspect of the entity defined by the associated declaration (the @i<associated entity>); the aspect denotes an object, a value, an expression, a subprogram, or some other kind of entity. If the @fa<aspect_mark> identifies:
@xbullet<an aspect that denotes an object, the @fa<aspect_definition> shall be a @fa<name>. The expected type for the @fa<name> is the type of the identified aspect of the associated entity;>
@xbullet<an aspect that is a value or an expression, the @fa<aspect_definition> shall be an @fa<expression>. The expected type for the @fa<expression> is the type of the identified aspect of the associated entity;>
@xbullet<an aspect that denotes a subprogram, the @fa<aspect_definition> shall be a @fa<name>; the expected profile for the @fa<name> is the profile required for the aspect of the associated entity;>
@xbullet<an aspect that denotes some other kind of entity, the @fa<aspect_definition> shall be a @fa<name>, and the @fa<name> shall resolve to denote an entity of the appropriate kind;>
@xbullet<an aspect that is given by an identifier specific to the aspect, the @fa<aspect_definition> shall be an @fa<identifier>, and the @fa<identifier> shall be one of the identifiers specific to the identified aspect.>
The usage names in an @fa<aspect_definition> are not resolved at the point of the associated declaration, but rather are resolved at the end of the immediately enclosing declaration list.
If the associated declaration is for a subprogram or entry, the names of the formal parameters are directly visible within the @fa<aspect_definition>, as are certain attributes, as specified elsewhere in this International Standard for the identified aspect. If the associated declaration is a @fa<type_declaration>, within the @fa<aspect_definition> the names of any components are directly visible, and the name of the first subtype denotes the current instance of the type (see 8.6). If the associated declaration is a @fa<subtype_declaration>, within the @fa<aspect_definition> the name of the new subtype denotes the current instance of the subtype.
@i<@s8<Legality Rules>>
If the first freezing point of the associated entity comes before the end of the immediately enclosing declaration list, then each usage name in the @fa<aspect_definition> shall resolve to the same entity at the first freezing point as it does at the end of the immediately enclosing declaration list.
At most one occurrence of each @fa<aspect_mark> is allowed within a single @fa<aspect_specification>. The aspect identified by the @fa<aspect_mark> shall be an aspect that can be specified for the associated entity (or view of the entity defined by the associated declaration).
The @fa<aspect_definition> associated with a given @fa<aspect_mark> may be omitted only when the @fa<aspect_mark> identifies an aspect of a boolean type, in which case it is equivalent to the @fa<aspect_definition> being specified as True.
If the @fa<aspect_mark> includes 'Class, then the associated entity shall be a tagged type or a primitive subprogram of a tagged type.
@i<@s8<Static Semantics>>
Depending on which aspect is identified by the @fa<aspect_mark>, an @fa<aspect_definition> specifies:
@xbullet<a @fa<name> that denotes a subprogram, object, or other kind of entity;>
@xbullet<an @fa<expression>, which is either evaluated to produce a single value, or which (as in a precondition) is to be evaluated at particular points during later execution; or>
@xbullet<an @fa<identifier> specific to the aspect.>
The identified aspect of the associated entity, or in some cases, the view of the entity defined by the declaration, is as specified by the @fa<aspect_definition> (or by the default of True when boolean). Whether an @fa<aspect_specification> applies to an entity or only to the particular view of the entity defined by the declaration is determined by the @fa<aspect_mark> and the kind of entity. The following aspects are view specific:
@xbullet<An aspect specified on an @fa<object_declaration>;>
@xbullet<An aspect specified on a @fa<subprogram_declaration>;>
@xbullet<An aspect specified on a @fa<renaming_declaration>.>
All other @fa<aspect_specification>s are associated with the entity, and apply to all views of the entity, unless otherwise specified in this International Standard.>
If the @fa<aspect_mark> includes 'Class, then:
@xbullet<if the associated entity is a tagged type, the specification applies to all descendants of the type;>
@xbullet<if the associated entity is a primitive subprogram of a tagged type @i<T>, the specification applies to the corresponding primitive subprogram of all descendants of @i<T>.>
All specifiable operational and representation attributes may be specified with an @fa<aspect_specification> instead of an @fa<attribute_definition_clause> (see 13.3). The @fa<attribute_designator> is used for the @fa<aspect_mark>. In addition, certain other operational and representation aspects not associated with specifiable attributes may be specified, as specified elsewhere in this International Standard. In the case of aspects specifiable with pragmas, the pragma @fa<identifier> is used for the @fa<aspect_mark>, unless otherwise specified in this International Standard.
If an aspect of a derived type is inherited from an ancestor type and has the boolean value True, the inherited value shall not be overridden to have the value False for the derived type, unless otherwise specified in this International Standard.
If a Legality Rule or Static Semantics rule only applies when a particular aspect has been specified, the aspect is considered to have been specified only when the @fa<aspect_specification> or @fa<attribute_definition_clause> is visible (see 8.3) at the point of the application of the rule.
There are no language-defined aspects that may be specified on a @fa<renaming_declaration> or on a @fa<formal_type_declaration>.
An aspect shall not be specified in an @fa<aspect_specification> given on a @fa<subprogram_body> that is a completion of another declaration.
Alternative legality and semantics rules may apply for particular aspects, as specified elsewhere in this International Standard.
@i<@s8<Dynamic Semantics>>
At the freezing point of the associated entity, the @fa<aspect_specification> is elaborated. The elaboration of the @fa<aspect_specification> includes the evaluation of the @fa<name> or @fa<expression>, if any, unless the aspect itself is an @fa<expression>. If the corresponding aspect represents an @fa<expression> (as in a precondition), the elaboration has no effect; the @fa<expression> is evaluated later at points within the execution as specified elsewhere in this International Standard for the particular aspect.
@i<@s8<Implementation Permissions>>
Implementations may support implementation-defined aspects. The @fa<aspect_specification> for an implementation-defined aspect may use an implementation-defined syntax for the @fa<aspect_definition>, and may follow implementation-defined legality and semantics rules.
!corrigendum 13.3(5/1)
Replace the paragraph:
An attribute_designator is allowed in an attribute_definition_clause only if this International Standard explicitly allows it, or for an implementation-defined attribute if the implementation allows it. Each specifiable attribute constitutes an operational aspect or aspect of representation.
by:
An attribute_designator is allowed in an attribute_definition_clause only if this International Standard explicitly allows it, or for an implementation-defined attribute if the implementation allows it. Each specifiable attribute constitutes an operational aspect or aspect of representation; the name of the aspect is that of the attribute.
!corrigendum 13.3(73.1/1)
Replace the paragraph:
The following operational attribute is defined: External_Tag.
by:
The following type-related operational attribute is defined: External_Tag.
!corrigendum 13.13.2(1/1)
Replace the paragraph:
The operational attributes Write, Read, Output, and Input convert values to a stream of elements and reconstruct values from a stream.
by:
The type-related operational attributes Write, Read, Output, and Input convert values to a stream of elements and reconstruct values from a stream.
!corrigendum 13.14(7.1/2)
Insert after the paragraph:
the new paragraph:
!corrigendum 13.14(8/2)
Replace the paragraph:
A static expression causes freezing where it occurs. An object name or nonstatic expression causes freezing where it occurs, unless the name or expression is part of a default_expression, a default_name, or a per-object expression of a component's constraint, in which case, the freezing occurs later as part of another construct.
by:
A static expression (other than within an aspect_specification) causes freezing where it occurs. An object name or nonstatic expression causes freezing where it occurs, unless the name or expression is part of a default_expression, a default_name, an aspect_specification, or a per-object expression of a component's constraint, in which case, the freezing occurs later as part of another construct or at the freezing point of an associated entity.
!example
(See discussion.)
!ACATS test
ACATS B-Tests should be generated for the legality rules here.
ACATS C-Tests will be generated for specific aspects; there isn't a need to see if the clauses are supported individually.
!ASIS
[From Tucker.]
!appendix

From: Yannick Moy
Sent: Tuesday, April 20, 2010  8:58 AM

I would like to question the following legality rule for user-defined kinds of
aspect_mark:

"At most one occurrence of each aspect_mark is allowed within a single
aspect_specification."

Indeed, it could be useful to have multiple user aspects of the same kind. This
is the case, e.g., for an aspect we could add to GNAT, which would give the
ability to specify unit tests, as in:

function Sqrt (X : Integer) return Integer
  with Test => if X > 100 then Sqrt'Result >= 10,
       Test => if X < 100 then Sqrt'Result < 10,
       Test => if X = 100 then Sqrt'Result = 10,
       Test => Sqrt'Result >= 0;

Notice that this aspect is essentially a special kind of postcondition. The goal
in having a special aspect for it and allowing multiple occurrences of this
aspect on the same subprogram is to allow compilers and analysis tools to treat
differently postconditions and these sorts of specifications for unit tests.

As a side note, notice that, although not needed in the example above, it will
in general be necessary to use attribute 'Old to refer to the pre-state of the
call, like in:

procedure Sqrt (X : in out Integer)
  with Test => if X'Old > 100 then X >= 10;

I was told that the "with Blah => ..." syntax is meant to be more-or-less
equivalent to "for ...'Blah use ...". Then, allowing multiple aspects of the
same kind could require that such aspects are named in some way, so that you can
access them in the code with 'Blah("name")?

As Bob suggested that I submit an exact wording, I'll only propose for now:

"Unless specified otherwise for a specific aspect_mark, more than one occurrence
of each aspect_mark is allowed within a single aspect_specification."

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

From: Yannick Moy
Sent: Tuesday, April 27, 2010  11:38 AM

I'll answer my own question, thanks to an idea that Cyrille Comar gave me. He
proposed that we use different identifiers for different aspects of the same
kind that apply to the same declaration, so that the Sqrt example I gave in my
previous email would read:

function Sqrt (X : Integer) return Integer
  with Test_1 => if X > 100 then Sqrt'Result >= 10,
       Test_2 => if X < 100 then Sqrt'Result < 10,
       Test_3 => if X = 100 then Sqrt'Result = 10,
       Test_4 => Sqrt'Result >= 0;

This is already allowed in the current wording, and it fits our needs well, so
please ignore the previous request for allowing multiple user aspects of the
same kind within a single aspect_specification.

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

From: Tucker Taft
Sent: Wednesday, April 28, 2010  2:19 AM

Here is an update to the AI on aspect specifications.
Comments welcome. (yeah, right ;-)
[This is version /03 of the AI - Editor.]

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

From: Bob Duff
Sent: Wednesday, April 28, 2010  6:32 PM

> Here is an update to the AI on aspect specifications.
> Comments welcome. (yeah, right ;-)

;-)

Looks great.  Thanks.

I think we need an Impl Perm to add impl-def aspects.

> !subject Aspect Specifications

>   [AARM NOTE: The aspect_specification is an optional element in the following
>    kinds of declarations:
>     * object_declaration;
>     * full_type_declaration;
>     * subtype_declaration;
>     * component_declaration;
>     * subprogram_declaration;
>     * abstract_subprogram_declaration;
>     * null_procedure_declaration;
>     * package_declaration;
>     * private_type_declaration;
>     * private_extension_declaration;
>     * task_type_declaration;
>     * single_task_declaration;
>     * protected_type_declaration;
>     * single_protected_declaration;
>     * entry_declaration;
>     * generic_declaration.]

It would be useful to list all the kinds of declarations that do not allow
aspect_specs.

I suppose they're not allowed on bodies, even if the body acts as a spec
(subps).

>             Name Resolution
>
>   The expected type for an expression associated with a given
>   aspect_mark is the type of the identified aspect of the entity defined
>   by the associated declaration (the *associated entity*). The names in
>   such an expression [Redundant: are not resolved at the point of the
>   associated declaration, but rather] are resolved at the end of the
>   immediately enclosing declaration list or at the first freezing point
>   of the associated entity, whichever comes first.
>
>   If the associated declaration is for a subprogram or entry, the names of the
>   formal parameters are visible within the expression, as are certain
>   attributes, as specified elsewhere in this International Standard for
>   the identified aspect.  If the associated declaration is a type_declaration,
>   within the expression the names of any components are visible, and the
>   name of the first subtype denotes the current instance of the type (see 8.6).

I think you want "directly visible" above.

We need "current instances" for subtypes, too:

    subtype Nonzero is Integer
        with Predicate => Nonzero /= 0;

>      function Union(X, Y : Set) return Set
>        is abstract with
>          Post'Class =>
>            Count(Union'Result) = Count(X) + Count(Y);

I think "<=" would be more correct than "=" in this example.

> This presumes that aspect identifiers generally match attribute names
> or pragma names.  However, particularly in the case of pragmas, we may
> prefer to choose nouns rather than adjectives for aspect names, so the
> names work better after the preposition "with".  Hence, perhaps
> "Atomicity" or "Independence" rather than "Atomic" and "Independent."

I'm not sure what my opinion is on this.  I'm sure we can discuss it endlessly.
"with Pack" looks funny, but it's a simple rule to say that it matches the
pragma name.

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

From: Randy Brukardt
Sent: Wednesday, April 28, 2010  6:44 PM

> I'm not sure what my opinion is on this.  I'm sure we can discuss it
> endlessly.  "with Pack" looks funny, but it's a simple rule to say
> that it matches the pragma name.

The current Ada aspect name for pragma Pack is "Packing". Ada 95 explicitly
defined this (not sure why). So we have "with Packing =>", not "with Pack". Most
of the others don't have names, however. The question of whether to bother
giving them names probably is an endless pit, as you suggest.

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

From: Bob Duff
Sent: Wednesday, April 28, 2010  7:15 PM

We can have "with Packing" or "with Pack", (with or without "=> True") as we
wish.

Or even "with Packed" or "with Packedness".  ;-)

I think the "packing" in 13.2:

    A pragma Pack specifies the packing aspect of representation; the type (or
    the extension part) is said to be packed.

is my handiwork.  It's not cast in stone.  I think I just wanted it to fit in
with whatever rule forbids specifying the same aspect twice.

> Most of the others don't have names, however. The question of whether
> to bother giving them names probably is an endless pit, as you suggest.

So let's defer that discussion, and concentrate on more important things, like
"Are there any decls that don't allow aspect_clauses, and if so, is there a good
reason, or just because we forgot about them?"

What about formal params?

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

From: Randy Brukardt
Sent: Wednesday, April 28, 2010  7:34 PM

> What about formal params?

I don't think we want those; it would require new kinds of generic matching. And
we don't allow rep clauses or operational clauses on them now; why change that?

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

From: Tucker Taft
Sent: Wednesday, April 28, 2010  7:34 PM

> ...
> So let's defer that discussion, and concentrate on more important
> things, like "Are there any decls that don't allow aspect_clauses, and
> if so, is there a good reason, or just because we forgot about them?"
>
> What about formal params?

And discriminants.

And loop indices.

I didn't include those, but I don't have a strong feeling either way.  Putting
them on formals does add complexity to conformance.

I guess my instinct would be to leave them off, and rely on putting them on
subtypes rather than individual parameters or discriminants.

Randy is right we need to address static matching of subtypes.  It seems we
could allow matching when the same aspects are specified with equal static
expressions.  Alternatively, don't provide static matching at all if the two
subtypes have different sets of aspect_specifications applying to them (include
even "confirming" aspect_specifications).

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

From: Tucker Taft
Sent: Wednesday, April 28, 2010  7:53 PM

Actually I did allow them on generic formal parameters, but not on subprogram
formals. They seem like they might be important on generic formals, but I agree
they will need some generic matching rules if we allow them. At this point we
can simply say that matching rules are specific to each aspect that is allowed
on a generic formal.

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

From: Randy Brukardt
Sent: Wednesday, April 28, 2010  8:03 PM

That might be OK, but then we'll have to check every existing aspect for whether
or not we need to add wording about this case. Which I don't find very
appealing, because I know who will get stuck with the job. :-)

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

From: Bob Duff
Sent: Wednesday, April 28, 2010  8:13 PM

> > What about formal params?
>
> I don't think we want those; ...

I'm not saying we want those.  I'm just saying we want to think about  whether
we want those.  And I'd like to have a complete list of which ones need thinking
about.

(I have an uneasy feeling I'm going to be assigned the task of coming up with
that complete list.  Sigh.  I guess that's fair.)

>... it would require new kinds of generic matching.
> And we don't allow rep clauses or operational clauses on them now; why
>change that?

Well, I recall Robert griping that pragmas are not allowed in formal parts.  I
don't remember the context, but I guess it's related.

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

From: Randy Brukardt
Sent: Wednesday, April 28, 2010  10:02 PM

> Here is an update to the AI on aspect specifications.
> Comments welcome. (yeah, right ;-)

Wording that appears to be missing based on the minutes of the St. Pete meeting:

(1) List of declarations that these are *not* allowed on. It appears currently
    to be renames and bodies. Explain any missing ones.

(2) How does this relate to conformance and static matching? It seems to be
    ignored for subprograms (if it isn't on the body); do we need to say that
    somewhere? Probably need an AARM note even if nothing else changes. Static
    matching surely needs wording (even if to put it off to the individual
    aspects).

(3) There is no wording explaining what identifier an "aspect_mark" is. We've
    put this off, we need an actual answer. (I've always assumed it was the
    aspect names, which are fully defined by the language now, but in any case
    there needs to be wording to say that. I cannot find any now.)

(4) Unrecognized aspects are an error; something needs to be said about this.

(5) We need a standard style for introducing new aspects. That probably should
    be mentioned in the !discussion of this one.

(6) We want to add an index of aspects that can be used here. That probably
    could be another AI (someone needs to propose that formally).

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

From: Randy Brukardt
Sent: Wednesday, April 28, 2010  10:21 PM

> I'm not saying we want those.  I'm just saying we want to think about
> whether we want those.  And I'd like to have a complete list of which
> ones need thinking about.
>
> (I have an uneasy feeling I'm going to be assigned the task of coming
> up with that complete list.  Sigh.  I guess that's fair.)

Bob, come up with that complete list! :-)

Seriously, given Tucker's difficulty in finding time to do things, it would be
best if the rest of us pitched in on "easy" things, which this appears to be. So
go for it.

> >... it would require new kinds of generic matching.
> > And we don't allow rep clauses or operational clauses on
> them now; why
> >change that?
>
> Well, I recall Robert griping that pragmas are not allowed in formal
> parts.  I don't remember the context, but I guess it's related.

I also recall that we convinced him that it was a bad idea, and we didn't do
anything about it (I believe you can find the mail in the second AI about pragma
placement).

I'm against allowing these on any kind of formal parameter; we don't allow any
such things currently on any of the things Tucker listed (subprogram formal
parameters, discriminants, loop parameters, etc.) and it would be a significant
amount of work to change that. (Do you want people to specify how many bits you
can use to pass a parameter? I didn't think so.)

I'm also against allowing it on generic formal parameters, for similar reasons.
Plus the massive number of generic matching rules that would be needed. I
suppose it would be OK to say:

Unless otherwise specified, aspects cannot be given on generic formals.

So that it is illegal unless something really needs it and then specifies what
it means. I surely don't want to be doing matching of preconditions for formal
subprograms!!

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

From: Bob Duff
Sent: Monday, May 10, 2010  2:25 PM

This is my response to this homework item:

AI05-0183-1: Work with Tucker on a list of declarations that don't allow
aspect_specifications, and why not.

which was assigned to me at the April 29 telephone meeting.
I'm not sure about the "why not" part.

There is a list of declarations that include aspect_spec in the !proposal, and
again in the AARM.  The latter is missing generic_formal_parameter_declaration.
It's also missing from the syntax rules.
Seems like it should be included.
I suggest putting the list only in the AARM, and put something like this in the
proposal:

  The aspect_specification is an optional element allowed by the syntax rules
  for many kinds of declarations.

Here's the list:

    * object_declaration;
    * full_type_declaration;
    * subtype_declaration;
    * component_declaration;
    * subprogram_declaration;
    * abstract_subprogram_declaration;
    * null_procedure_declaration;
    * package_declaration;
    * private_type_declaration;
    * private_extension_declaration;
    * task_type_declaration;
    * single_task_declaration;
    * protected_type_declaration;
    * single_protected_declaration;
    * entry_declaration;
    * generic_declaration;
    * generic_formal_parameter_declaration.

     [What about renaming declarations?]

I did not carefully review the syntax rules in the AI to see if they in fact
match the above list.

Here's a list of all the kinds of declaration, with "*" marking the ones
mentioned above, and NO marking the ones that currently do not allow an
aspect_specification.

basic_declaration
  type_declaration
    full_type_declaration*
      ...
      task_type_declaration*
      protected_type_declaration*
    incomplete_type_declaration  --  NO
    private_type_declaration*
    private_extension_declaration*
  subtype_declaration*
  object_declaration*
    ...
    single_task_declaration*
    single_protected_declaration*
  number_declaration  --  NO
  subprogram_declaration*
  abstract_subprogram_declaration*
  null_procedure_declaration*
  package_declaration*
  renaming_declaration  --  NO
  exception_declaration  --  NO
  generic_declaration*
  generic_instantiation  --  NO
enumeration_literal_specification  --  NO
discriminant_specification  --  NO
component_declaration*
loop_parameter_specification  --  NO
parameter_specification  --  NO
subprogram_body  --  NO
entry_declaration*
entry_index_specification  --  NO
choice_parameter_specification  --  NO
generic_formal_parameter_declaration*  (or NO -- not clear)
extended_return_statement  --  NO

I guess we should add renaming_declaration and exception_declaration.
I guess generic_formal_parameter_declaration should be included.
It seems a little odd to allow component_declaration, but not
discriminant_specification.  Not sure about parameter_specification.

Please discuss.  When that's done, we should add AARM text after the list of
declarations that allow it, like:

  The syntax rules do not allow aspect_specifications on the other kinds of
  declarations, which are:

    ... (list them)

  Also, aspect_specifications are not allowed on bodies or accept statements,
  even though these things are sort of like declarations, and in the case of
  subprogram_bodies can actually be declarations. If you want an
  aspect_specification on a subprogram, you have to give an explicit
  declaration before the body.

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

From: Gary Dismukes
Sent: Monday, May 10, 2010  7:09 PM

> I guess we should add renaming_declaration and exception_declaration.

I agree those should be included.

> I guess generic_formal_parameter_declaration should be included.

Dunno.  Doesn't that get into matching complexities?

> It seems a little odd to allow component_declaration, but not
> discriminant_specification.  Not sure about parameter_specification.

It does seem inconsistent to disallow them for discriminants.  Is there any
significant argument for not allowing them on discriminants and parameter specs?
I suppose it tends to interfere with readability, plus there's the issue of
conformance for spec/body and multipart declarations.

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

From: Tucker Taft
Sent: Monday, May 10, 2010  9:12 PM

I am reluctant to allow specifying aspects on a renaming declaration.  That
could really confuse the model and add a lot of complexity to handling renames,
which are already pretty tricky.  I agree that exception declarations should
allow aspect specifications.

Randy suggested that by default, aspect specifications would not be permitted on
generic_formal_parameter_decls, but that they could be permitted for particular
aspects. We would have to define the matching rules for any aspects that we
allow being specified on a generic formal.  But it seems like it could be useful
at least in some cases.

Allowing them on discriminants or parameters definitely adds complexity to
conformance rules.  It doesn't seem so odd that discriminants are special, since
they have other unique properties, such as being read-only, and being
specifiable in a subtype indication, etc.

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

From: Jean-Pierre Rosen
Sent: Tuesday, May 11, 2010  1:44 AM

> I am reluctant to allow specifying aspects on a renaming declaration.
> That could really confuse the model and add a lot of complexity to
> handling renames, which are already pretty tricky.  I agree that
> exception declarations should allow aspect specifications.

I fully agree here. Aspects are a property of the entity, not of the view. We
already have the problem that constraints on the subtype of a renaming are
ignored, let's not make it worse.

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

From: Bob Duff
Sent: Tuesday, May 11, 2010  8:46 PM

> I am reluctant to allow specifying aspects on a renaming declaration.
> That could really confuse the model and add a lot of complexity to
> handling renames, which are already pretty tricky.

If we have no aspects that are specifiable on renames, we could still allow the
syntax, just in case an implementation wants to do it for an impl-def aspect.
Then whatever complexity there is belongs to the implementer.

Renames can be dispatching ops.  So you can't put a precondition on one?  Hmm...

>...I agree that exception declarations
> should allow aspect specifications.
>
> Randy suggested that by default, aspect specifications would not be
> permitted on generic_formal_parameter_decls, but that they could be
> permitted for particular aspects.

But that's true for everything.  That is, we define the syntax to allow
aspect_specs on certain decls.  Then, for each aspect, we say "this is allowed
on so-and-so decls".

If there are no language-defined aspects that are allowed on
generic_formal_parameter_decls, we can still allow the syntax.

> We would have to define the matching rules for any aspects that we
> allow being specified on a generic formal.

If there are no language-defined ones, we can let implementers worry about that.

>...But it seems like it could be useful at  least in some cases.
>
> Allowing them on discriminants or parameters definitely adds
> complexity to conformance rules.  It doesn't seem so odd that
> discriminants are special, since they have other unique properties,
> such as being read-only, and being specifiable in a subtype
> indication, etc.

Again, all the complexity can be placed on the implementer, if all we do is
allow the syntax.  On the other hand, the syntax gets pretty ugly in these
cases.

I don't feel strongly about any of this, except that I strongly believe we
should have a list in the AARM of the decls (and bodies) that don't allow
aspects syntactically, so we can be sure we did it deliberately.  I suggested
wording in my previous e-mail.

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

From: Randy Brukardt
Sent: Wednesday, May 19, 2010  10:14 PM

> This is my response to this homework item:
>
> AI05-0183-1: Work with Tucker on a list of declarations that don't
> allow aspect_specifications, and why not.
>
> which was assigned to me at the April 29 telephone meeting.
> I'm not sure about the "why not" part.

I think you were supposed to explain why each basic declaration that doesn't
allow aspect clauses doesn't allow aspect clauses. (I can't think of any way to
say this that isn't redundant!) Maybe it would be better to say that there needs
to be an explanation for each declaration on the list of declarations that don't
allow aspect_clauses -- the idea being that the default is that they *are*
allowed. This seems like useful information for the AARM.

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

From: Bob Duff
Sent: Friday, May 20, 2010  7:07 AM

Right, I understood that, and my "I'm not sure..." comment was meant to mean "I
don't know the answer to those questions".

I'm the one who raised the issue, and I'm happy with just having the list, so I
can look at it and say "yeah, OK, seems reasonable I guess". If Tuck can put
coherent reasons on them, that's fine too.

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

From: Randy Brukardt
Sent: Wednesday, May 19, 2010  10:24 PM

> > Randy suggested that by default, aspect specifications would not be
> > permitted on generic_formal_parameter_decls, but that they could be
> > permitted for particular aspects.
>
> But that's true for everything.  That is, we define the syntax to
> allow aspect_specs on certain decls.  Then, for each aspect, we say
> "this is allowed on so-and-so decls".

Sadly, we don't do a good job of that for the existing aspects in Ada 95 and
2005. However, the rule added by AI05-0106-1 (13.1(9.2/3)) should cover it, so
we don't need any additional wording for this AI.

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

From: Bob Duff
Sent: Friday, May 14, 2010  8:08 AM

I think AI05-0183-1 (Aspect Specifications) needs some verbiage about
visibility.  In particluar, this (from Yannick's recent ada-comment@ e-mail):

   type Part (Max_Players : Positive) is record
      ...
      Num_Players : Positive;  --  Number of players
      Pos         : Positions (1 .. Max_Players);  --  Position of each player
   end record
    with Predicate => Num_Players in 1 .. Max_Players;

should be legal.  So should this:

    with Predicate => Part.Num_Players in 1 .. Part.Max_Players;

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

From: Tucker Taft
Sent: Monday, June 7, 2010  2:58 PM

Here is an update to the aspect specification AI. [This is version /04 - Editor.]
There are still some things missing, such as the
Annex of specifiable aspects.  I am
also a little unclear how we should
indicate in the body of the RM
(as opposed to in the eventual annex) which aspects can be specified.

My guess is that all specifiable attributes should be specifiable using an
aspect_specification. But it is not clear which pragmas nor
which of the other aspects associated
with record and enum rep clauses should
be specifiable with an aspect_specification.

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

From: Randy Brukardt
Sent: Thursday, June 10, 2010  9:22 PM

> Here is an update to the aspect
> specification AI.  There are still
> some things missing, such as the
> Annex of specifiable aspects.  I am
> also a little unclear how we should
> indicate in the body of the RM
> (as opposed to in the eventual annex)
> which aspects can be specified.

So are the rest of us! Someone needs to invent something, and you're one of the
best inventors.

> My guess is that all specifiable attributes should be specifiable
> using an aspect_specification.
> But it is not clear which pragmas nor
> which of the other aspects associated
> with record and enum rep clauses should be specifiable with an
> aspect_specification.

I think a straw-man here would be helpful. I'm not even sure that most of us are
considering everything that might be possible to specify.

So I think it would be helpful if you would make a stab at figuring how these
things might work. (But only after the rest of your homework is done, the two
remaining AIs are more important than these details of this one.)

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

From: Robert Dewar
Sent: Monday, July 26, 2010  7:04 PM

I assume the idea is that you have a big list of aspects that are allowed, and
for each aspect it is clear what entities it applies to, what it does, and
whether it needs no argument, a name argument, or an expression argument.

Regarding the latter, we have the examples:

    Atomic_Components

and

    Atomic => True

Can you also say

    Atomic => False

that would be interesting to cancel atomicity in a derived type (not currently
possible).

Can you also say something like

    Pack => False;

again, interesting to be able to cancel packing, not currently possible.

Does

    Pack

mean the same as

    Pack => True

Can you say

    Atomic => Machine_64

where Machine_64 is a static boolean constant? If so interesting way to
parametrize things??

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

From: Tucker Taft
Sent: Saturday, July 31, 2010  8:29 AM

> I assume the idea is that you have a big list of aspects that are
> allowed, and for each aspect it is clear what entities it applies to,
> what it does, and whether it needs no argument, a name argument, or an
> expression argument.

Leaving out the expression is exactly equivalent to writing "=> True".
Generally you can use this notation for any specifiable attribute, as well many
of the representation pragmas.  In addition, there are a few "aspects" that can
only be specified using this syntax (e.g. "Pre" and "Post").

> Regarding the latter, we have the examples:
>
>     Atomic_Components
>
> and
>
>     Atomic => True
>
> Can you also say
>
>     Atomic => False
>
> that would be interesting to cancel atomicity in a derived type (not
> currently possible).

Interesting question.  You are right that for aspects corresponding to pragmas,
we may be giving a new capability without realizing it.  We clearly have to be
sure we really want that!

> Can you also say something like
>
>     Pack => False;
>
> again, interesting to be able to cancel packing, not currently
> possible.

Good point.

>
> Does
>
>     Pack
>
> mean the same as
>
>     Pack => True

Yes, presuming the aspect name is "Pack."  This is one pragma where the aspect
name is specified in the manual to be something other than the pragma name
("Packing" vs. "Pack").  That could be confusing, so the AI says something about
wheter to always use the pragma name for aspect names.  I forget what was the
conclusion relative to the "Pack" pragma...

> Can you say
>
>     Atomic => Machine_64
>
> where Machine_64 is a static boolean constant? If so interesting way
> to parametrize things??

Yes, presumably any static expression of the right type, as in an attribute
definition clause.

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

From: Robert A Duff
Sent: Saturday, July 31, 2010  5:30 PM

> I forget what was the conclusion relative to the "Pack" pragma...

I think we decided that the place(s) where the RM says "packing aspect" should
be changed to "pack aspect". or "Pack aspect"?

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

From: Robert Dewar
Sent: Sunday, August 1, 2010  6:24 AM

> Yes, presuming the aspect name is "Pack."  This is one pragma where
> the aspect name is specified in the manual to be something other than
> the pragma name ("Packing" vs. "Pack").  That could be confusing, so
> the AI says something about wheter to always use the pragma name for
> aspect names.  I forget what was the conclusion relative to the "Pack"
> pragma...

Well I would implement Pack even if the official name were Packing (which could
be a synonym), it would be plain confusing to have a different name from the
pragma.

>> Can you say
>>
>>     Atomic => Machine_64
>>
>> where Machine_64 is a static boolean constant? If so interesting way
>> to parametrize things??
>
> Yes, presumably any static expression of the right type, as in an
> attribute definition clause.

Sure but the boolean attributes are always done with pragmas now, which do NOT
permit this kind of parametrization, so this seems like a new (and valuable)
feature.

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

From: Robert Dewar
Sent: Sunday, August 1, 2010  6:45 AM

> I think we decided that the place(s) where the RM says "packing
> aspect" should be changed to "pack aspect".
> or "Pack aspect"?

Seems reasonable, the important point anyway is that the aspect be the same name
as the pragma, anything else would be mega-confusing, no matter WHAT the RM says
:-)

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

From: Tucker Taft
Sent: Sunday, August 1, 2010  9:36 AM

For a while we were trying to make "with Blah" sound natural, such as "with
Atomicity" and "with Packing". But if you are concerned about the way it sounds,
you could easily write "with Atomic => True" or "with Pack => True," so that
concern seems misplaced in retrospect.  So I think by the end we all agreed that
we should do what is simplest, and make the aspect name match the pragma name in
all cases.

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

From: Steve Baird
Sent: Monday, August 2, 2010  11:04 AM

> Can you also say something like
>
>     Pack => False;
>
> again, interesting to be able to cancel packing,

When the RM says something like

    A pragma Pack specifies the packing aspect of representation or
    Unless otherwise specified, the name of the aspect of
    representation specified by a representation pragma is
    the name of the pragma.

it gives no hint as to what "values" (I'm using this term very loosely here)
might be specified using Aspect-specification syntax. For example, it does not
say that Pack is Boolean-valued aspect for which values True or False might be
specified.

The AI says:
   An aspect_mark identifies an aspect of the entity defined by the
   associated declaration (the associated entity); the aspect denotes
   an object, a value, an expression, a subprogram, or some other kind
   of entity. If the aspect_mark identifies an aspect that denotes an
   object, the aspect_definition shall be a name.
   If the aspect_mark identifies a value or an expression, the
   aspect_definition shall be an expression. The expected type for the
   name or expression is the type of the identified aspect of the
   associated entity.

It seems to me that the "some other kind of entity" case might include, for
example, pragma Pack. The aspect "value" could be more like a a restriction name
for a Restriction pragma or a check name for a Suppress pragma.

 > Can you say
 >
 >     Atomic => Machine_64
 >
 > where Machine_64 is a static boolean constant?

If it were specified that the "value or an expression" case (as opposed to the
"some other kind of entity" case) applied to pragma Atomic, and that the
specified value is of type Boolean, then it would make sense that an arbitrary
static expression would be allowed. However, where is the wording for that? In
particular, where is the wording that would disallow a non-static Boolean
expression? Obviously a particular implementation might choose to reject such a
construct, but this rule shouldn't be implementation-dependent, should it?

This doesn't seem like a bad idea, but I think some new RM wording is needed to
support this.

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

From: Tucker Taft
Sent: Tuesday, August 3, 2010  11:46 AM

It was certainly my expectation that
pragmas like Pack, Atomic, Atomic_Components, etc. would all be considered to
specify boolean-valued aspects.  I agree that the RM needs to spell that out
somewhere.

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

From: Randy Brukardt
Sent: Tuesday, August 3, 2010   4:16 PM

In Valencia, we elected Bob Duff to write an AI to define all of the wording
changes to individual aspects that will be needed. The intent we discussed was a
blanket rules covering all specifiable aspects (which I think is already in
AI-183), and then everything else will be worded explicitly. There is also
supposed to be an annex similar to the pragma one that lists all specifiable
aspects - Bob and I will need to work out the form of the individual entries for
that (I will want to try to make it automatically generated similarly to the
pragma and attribute annexes).

P.S. Bob, see what happens when you don't come to a meeting? You get piles of
new assignments! ;-)

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

From: Robert Dewar
Sent: Friday, August 6, 2010   11:55 AM

This is a small excerpt from the GNAT implementation:

>       --  We modify the RM grammar here, the RM grammar is:
>
>       --     ASPECT_SPECIFICATION ::=
>       --       with ASPECT_MARK [=> ASPECT_DEFINITION] {.
>       --            ASPECT_MARK [=> ASPECT_DEFINITION] }
>
>       --     ASPECT_MARK ::= aspect_IDENTIFIER['Class]
>
>       --     ASPECT_DEFINITION ::= NAME | EXPRESSION
>
>       --  That's inconvenient, since there is no non-terminal name for a single
>       --  entry in the list of aspects. So we use this grammar instead:
>
>       --     ASPECT_SPECIFICATIONS ::=
>       --       with ASPECT_SPECIFICATION {, ASPECT_SPECIFICATION};
>
>       --     ASPECT_SPECIFICATION =>
>       --       ASPECT_MARK [=> ASPECT_DEFINITION]
>
>       --     ASPECT_MARK ::= aspect_IDENTIFIER['Class]
>
>       --     ASPECT_DEFINITION ::= NAME | EXPRESSION

We certainly find it useful to be able to talk about a single clause, which is
why we made this change, I am surprised the same consideration does not apply to
the RM description.

No big deal certainly, since there is no requirement that we use exactly the RM
grammar in the implementation. But worth a note to this list.

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

From: Robert Dewar
Sent: Saturday, August 7, 2010   5:36 PM

Am I understanding right that you can only give one Pre or Post entry for a
given subprogram?

If so, I think that's a huge mistake,

yes, sure you can join a bunch of conditions together with AND THEN, but this is
a debugging mess if you have a huge conditional, and you don't know which part
failed.

In GNAT programmers can always use the Precondition and Postcondition pragmas
(which are more flexible anyway, since you can give failure messages for each,
and indeed multiple entries are allowed), but it seems unfortunate for the
official version to be hobbled this way.

If I misread the rules, ignore this!

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

From: Tucker Taft
Sent: Saturday, August 7, 2010   8:02 PM

> Am I understanding right that you can only give one Pre or Post entry
> for a given subprogram?

Only one each.  They specify the "Pre" or "Post"
aspect, so it seems inconsistent to allow that to be done more than once.
Another problem is the confusion between when there are multiple specifications
that  apply, whether they are "or"ed or "and"ed.  In the case of Pre'Class, they
are "or"ed in when inherited.  We could say that all the ones at the same
"level" are "and"ed, but it just seemed easier to require the programmer to
write "and" themselves.


> If so, I think that's a huge mistake,
>
> yes, sure you can join a bunch of conditions together with AND THEN,
> but this is a debugging mess if you have a huge conditional, and you
> don't know which part failed.


Debugging seems like something the implementation could help with.  If the Pre
is structured as a series of "and"ed boolean expressions, then it seems quite
possible for the implementation to treat them exactly equivalently to separate
precondition pragmas, if it feels that provides helpful information to the user.
Effectively there would be separate source positions associated with each
operand of "and" so that the exception-message could identify the first operand
that evaluated to False.

That would also be a useful feature for a normal "Assert" pragma.  I often write
them as a series of "and"ed conditions, and it would be nice if the
implementation would identify the first operand that evaluated to False.

> In GNAT programmers can always use the Precondition and Postcondition
> pragmas (which are more flexible anyway, since you can give failure
> messages for each, and indeed multiple entries are allowed), but it
> seems unfortunate for the official version to be hobbled this way.
>
> If I misread the rules, ignore this!

We thought about the issue, and concluded the confusion between "and" and "or"
was a serious concern. I see your point about debugging, but I believe the
implementation can help here without changing the language rules.

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

From: Randy Brukardt
Sent: Sunday, August 8, 2010   6:00 PM

When we discussed this within the ARG, we concluded that using Pre and Post for
debugging ought to be discouraged, and thus having messages associated with them
actually encouraged bad behavior.

Debugging Pre and Post themselves is a different issue, but I think that is a
general problem that needs to be solved more by tools (and perhaps by the
implementation) than by the language. Making the semantics confusing (and how
these things combine [only for inheritance] is completely confusing as it is) is
not going to help anything. Besides, this is a problem with any complex
conditional, and it makes sense to solve it for all conditionals, not just Pre
and Post.

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

From: Robert Dewar
Sent: Sunday, August 8, 2010   10:51 PM

> When we discussed this within the ARG, we concluded that using Pre and
> Post for debugging ought to be discouraged, and thus having messages
> associated with them actually encouraged bad behavior.

If you have preconditions and post conditions, then sometimes they will fail. If
they fail, you need to be able to find out how they are failing.

> Debugging Pre and Post themselves is a different issue, but I think
> that is a general problem that needs to be solved more by tools (and
> perhaps by the
> implementation) than by the language. Making the semantics confusing
> (and how these things combine [only for inheritance] is completely
> confusing as it is) is not going to help anything. Besides, this is a
> problem with any complex conditional, and it makes sense to solve it
> for all conditionals, not just Pre and Post.

But complex conditionals are evil, and easily broken up in most cases, and most
certainly SHOULD be broken up, but you are making this normal good programming
practice impossible for preconditions and postconditions.

I don't mind too much, obviously we are not going to change the semantics of the
GNAT pragmas, so if the official version is less capable, that's no big deal for
us!

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

From: Robert Dewar
Sent: Sunday, August 8, 2010   10:55 PM

> Debugging seems like something the implementation could help with.  If
> the Pre is structured as a series of "and"ed boolean expressions, then
> it seems quite possible for the implementation to treat them exactly
> equivalently to separate precondition pragmas, if it feels that
> provides helpful information to the user.  Effectively there would be
> separate source positions associated with each operand of "and" so
> that the exception-message could identify the first operand that
> evaluated to False.

Sure, but that's much too difficult to do in our context, so it won't happen.

> That would also be a useful feature for a normal "Assert"
> pragma.  I often write them as a series of "and"ed conditions, and it
> would be nice if the implementation would identify the first operand
> that evaluated to False.

I always prefer a series of separate assertions, I don't like complex
conditionals ANYwhere in ANY code :-)

...
> We thought about the issue, and concluded the confusion between "and"
> and "or" was a serious concern.
> I see your point about debugging, but I believe the implementation can
> help here without changing the language rules.

I understand the reasoning, but I still don't like it, but as I noted in my
preious message, I don't really care, since people can always use the GNAT
pragmas which don't have this limitation instead.

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

From: Robert Dewar
Sent: Sunday, August 15, 2010  8:31 PM

For the case of pre/post conditions etc, we definitely want to delay visibility
analysis until the freeze point, but what about something like

    type Int is new Integer
      with Size => B'Size;

We have three options. Robert initially argued in an internal discussion, that
the simples was to treat this the same as

    type Int is new Integer;
    for Int'Size use B'Size;

And in particular, does not like the visibility of B depending on the freeze
point for Int, since programmers really don't know the details of where things
get frozen.

But Tuck argues that it is undesirable to cause what might be premature freezing
of B. In the case of the rep clause, this can be solved by simply moving the rep
clause later, but you don't have this option with the Aspect form.

He suggests doing the visibility analysis right away, but deferring evaluation
of the expression and consequent freezing to the freeze point for the entity
(same kind of mechanism as for default parameter expressions).

Robert is convinced by this argument, and agrees with this proposal, if everyone
agrees the AI needs updating to reflect this.

I have implemented this approach, as shown by the following test program:

>      1. with Text_IO; use Text_IO;
>      2. procedure AttrDelay is
>      3.    type S is new Integer range 1 .. 10;
>      4.
>      5.    --  Size should be 8 at freeze point
>      6.    type R is new Integer range 1 .. 2
>      7.      with Size => S'Size;
>      8.
>      9.    --  Pack should be effective (size 32)
>     10.    --  since S'Size = 8 at freeze point
>     11.    type R2 is array (0 .. 31) of Boolean
>     12.      with Pack => S'Size = 8;
>     13.
>     14.    for S'Size use 8;
>     15.
>     16. begin
>     17.    Blk : declare
>     18.       --  Get S above, not S below (evaluation is
>     19.       --  delayed, but not visibility) so 8, not 32
>     20.       type R3 is new Integer range 1 .. 2
>     21.         with Size => S'Size;
>     22.       type S is new Integer;
>     23.    begin
>     24.       Put_Line (R'Size'Img);
>     25.       Put_Line (R2'Size'Img);
>     26.       Put_Line (Blk.R3'Size'Img);
>     27.    end Blk;
>     28. end;

This outputs:

  8
  32
  8

If we didn't delay evaluation, the program would be illegal, since the aspect at
line 7 would freeze S, and the rep clause on line 14 would be too late.

If we delayed visibility analysis to the freeze point, the last line of output
would be 32 rather than 8.

I definitely think the compromise suggested by Tuck, and implemented above is
the way to go!

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

From: Robert A Duff
Sent: Monday, August 16, 2010  8:28 AM

> If we didn't delay evaluation, the program would be illegal, since the
> aspect at line 7 would freeze S, and the rep clause on line
> 14 would be too late.

Undesirable, but not the end of the world.  You can always use the old syntax
for Size clauses.

I'm not sure I fully understand the issue -- if we chose this, would it affect
any of the new attributes (Pre, Post, Invariant, Predicate, ...)?

> If we delayed visibility analysis to the freeze point, the last line
> of output would be 32 rather than 8.

That seems very bad.  It would mean S'Size evaluates to different values at
different places, if I understand correctly.

> I definitely think the compromise suggested by Tuck, and implemented
> above is the way to go!

I think I agree with that.

But there's another option to consider: Do we really need this new syntax for
all the old attributes?  I mean, we already have a way to specify Size and Pack
and so on.  What problem does this solve?

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

From: Randy Brukardt
Sent: Monday, August 16, 2010  2:40 PM

> > If we didn't delay evaluation, the program would be
> illegal, since the
> > aspect at line 7 would freeze S, and the rep clause on line
> > 14 would be too late.
>
> Undesirable, but not the end of the world.  You can always use the old
> syntax for Size clauses.
>
> I'm not sure I fully understand the issue -- if we chose this, would
> it affect any of the new attributes (Pre, Post, Invariant, Predicate,
> ...)?

Pre/Post delay *resolution* to the end of the declarative part, or something
like that. Those are different rules, I think.

> > If we delayed visibility analysis to the freeze point, the last line
> > of output would be 32 rather than 8.
>
> That seems very bad.  It would mean S'Size evaluates to different
> values at different places, if I understand correctly.

We discussed a problem somewhat like this in Valencia. "Freeze point" is a bad
place to do anything (because it moves easily and programmers don't really know
where it is); I think we had decided to make programs illegal if the resolution
changes between the aspect clause and the end of the declarative part. (Or
something like that.)

> > I definitely think the compromise suggested by Tuck, and implemented
> > above is the way to go!
>
> I think I agree with that.
>
> But there's another option to consider: Do we really need this new
> syntax for all the old attributes?  I mean, we already have a way to
> specify Size and Pack and so on.  What problem does this solve?

The problem solved is applying an aspect to one of a set of overloaded entities.
The current mechanisms make that impossible.

For other things, it's just a unification. But it seems a valuable one to me,
since it is much less likely be applied to the wrong entity or get the wrong
value because of changes.

The latter factor makes me wonder if we would be better off without a fancy rule
for the "normal" case of specifying an attribute; leaving Robert's example
illegal -- since, as Bob notes, you can always fall back to a regular size
clause if you need something like that. It's not clear (it seems valuable to
have some sort of delay rule so that aspect clauses can be used to provide
stream attributes, the routines of which cannot possibly be declared at the
point of the type declaration).

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

From: Robert Dewar
Sent: Monday, August 16, 2010  3:16 PM

> I'm not sure I fully understand the issue -- if we chose this, would
> it affect any of the new attributes (Pre, Post, Invariant, Predicate,
> ...)?

No, these are cases where the evaluation of the expression is not associated
with the freeze point of the entity, but is delayed to much later, so in these
cases, we do delay analysis of the expression to the freeze point to allow
forward references (just as the pragmas do in GNAT now).

...
> But there's another option to consider: Do we really need this new
> syntax for all the old attributes?  I mean, we already have a way to
> specify Size and Pack and so on.  What problem does this solve?

I think it's nice to have, don't use it if you don't like it.
It's all implemented already, so the implementation is not a barrier, and it
gives additional capabilities (cancelling and parametrizing attributes) that we
do not have now.

I see no reason to back pedal on this nice feature.

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

From: Robert Dewar
Sent: Monday, August 16, 2010  3:25 PM

> The latter factor makes me wonder if we would be better off without a
> fancy rule for the "normal" case of specifying an attribute; leaving
> Robert's example illegal -- since, as Bob notes, you can always fall
> back to a regular size clause if you need something like that. It's
> not clear (it seems valuable to have some sort of delay rule so that
> aspect clauses can be used to provide stream attributes, the routines
> of which cannot possibly be declared at the point of the type declaration).

I like Tuck's suggestion. If you get things wrong, you get a clear message that
some rep clause is too late, and GNAT will point out the freeze point involved
precisely.

I do think that you don't want the meaning to change with the freeze point. But
it is OK if you get a rep item too late, you can just fiddle to fix it.

The point is that we already have these expressions which are resolved early,
but evaluated late (e.g. default expressions), and so this is familiar and easy
to implement.

> We discussed a problem somewhat like this in Valencia. "Freeze point"
> is a bad place to do anything (because it moves easily and programmers
> don't really know where it is); I think we had decided to make
> programs illegal if the resolution changes between the aspect clause
> and the end of the declarative part. (Or something like that.)

UGHHHHH! That would be complicated to describe and a huge effort to implement
for zero gain! Anything like this that tinkers with the visibility mechanism is
diabolical!

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

From: Randy Brukardt
Sent: Monday, August 16, 2010  3:54 PM

Steve Baird showed examples where the value of the expression (and the entities
involved) could depend on the freeze point. That would be a *massive*
maintenance hazard, since freeze points change easily and often during
maintenance (and it usually doesn't matter at all).

The model that we were talking about is that the compiler would resolve the
expression at both points, and if it gets a different answer at the two points,
then the expression is illegal. There would be no "visibility changes" involved.
You might be right that that will be complicated to explain in RM terms, but I
don't think it will be hard to explain to users or difficult to implement.

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

From: Robert Dewar
Sent: Monday, August 16, 2010  4:08 PM

> Steve Baird showed examples where the value of the expression (and the
> entities involved) could depend on the freeze point. That would be a
> *massive* maintenance hazard, since freeze points change easily and
> often during maintenance (and it usually doesn't matter at all).

I an unconvinced, tempest in a teapot, almost always these expressions are
simple and all three approaches would give the same result. I really think this
is worrying about nonsense. The "*massive* maintenance hazard" phrase above is
unreasonale hyperobole. Almost always the issue would be a too late rep clause.
I know you can concoct examples. Indeed I had to concoct pretty peculiar
examples to test, and furthermore I discovered that we have had a bug in
handling attributes in default expressions that has gone unnoticed for 15 years
(X'Size is evaluated prematurely at the preanalysis point and thus could give
the wrong result).

> The model that we were talking about is that the compiler would
> resolve the expression at both points, and if it gets a different
> answer at the two points, then the expression is illegal. There would
> be no "visibility changes" involved. You might be right that that will
> be complicated to explain in RM terms, but I don't think it will be
> hard to explain to users or difficult to implement.

it will be difficult to implement, I would not even think of doing this, even if
it is required by the RM, any attempt to do double resolution like this would be
a huge earthquake.

I don't seriously object to the rule being in the RM, but I doubt we would ever
implement it. Just not worth the effort IMO. It's always possible there is some
clever way of doing this, but I sure don't see if right now.

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

From: Randy Brukardt
Sent: Monday, August 16, 2010  4:27 PM

> it will be difficult to implement, I would not even think of doing
> this, even if it is required by the RM, any attempt to do double
> resolution like this would be a huge earthquake.

Doesn't seem that difficult to me. For Janus/Ada, all that would be required
would be to make a copy of the tree and give the copy to the expression
resolver. You'd only do this if the first resolution was successful, so any
errors that occurred on the second resolution would necessarily indicate
differences and would therefore be real errors -- so no special machinery is
needed to do the resolution. There would need to be a tree compare routine, but
it's major job would be to check that the identifier symbol resolutions match
(the rest of the tree would have to be identical, of course).

Obviously, just because it seems easy in Janus/Ada doesn't mean anything about
the effort in another implementation, but no one in Valencia indicated that this
check would be a significant hardship in their compilers. (Of course, no one had
thought about it that deeply.)

> I don't seriously object to the rule being in the RM, but I doubt we
> would ever implement it. Just not worth the effort IMO. It's always
> possible there is some clever way of doing this, but I sure don't see
> if right now.

The above is how I would do it; it would be similar to the way we handle default
expressions now (the difference being that we would be redoing the resolution
phase rather than the legality check phase). But of course YMMV.

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

From: Robert Dewar
Sent: Monday, August 16, 2010  4:38 PM

I still think it is a case of worrying about zero probability events :-)

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

From: Robert Dewar
Sent: Monday, August 16, 2010  4:40 PM

>> I don't seriously object to the rule being in the RM, but I doubt we
>> would ever implement it. Just not worth the effort IMO. It's always
>> possible there is some clever way of doing this, but I sure don't see
>> if right now.
>
> The above is how I would do it; it would be similar to the way we
> handle default expressions now (the difference being that we would be
> redoing the resolution phase rather than the legality check phase). But of
> course YMMV.

In practice I would guess that the delay NEVER EVER will affect the value of the
aspect expression. You may then ask, why do it? The answer is that the premature
freezing could be a problem, e.g. for declarting primitive operations. The ARG's
taste for complexity never ceases to amaze me :-) :-)

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

From: Robert A Duff
Sent: Monday, August 16, 2010  7:15 PM

> > But there's another option to consider: Do we really need this new
> > syntax for all the old attributes?  I mean, we already have a way to
> > specify Size and Pack and so on.  What problem does this solve?
>
> The problem solved is applying an aspect to one of a set of overloaded
> entities. The current mechanisms make that impossible.
>
> For other things, it's just a unification. But it seems a valuable one
> to me, since it is much less likely be applied to the wrong entity or
> get the wrong value because of changes.

OK, those are strong arguments.  I withdraw my suggestion of "another option to
consider".

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

From: Robert Dewar
Sent: Monday, August 16, 2010  6:59 AM

The AI has a list of declarations to which aspects may be attached.

Not clear if there are standard aspects for all these declarations or not.

Wouldn't it be easier to just list the standard aspects together with what
declarations they apply to, then as implementation permission allow
implementations to define implementation dependent aspects on whatever
declarations they like

(for instance in GNAT, the aspect

    with Warnings => Off;

applies to all entities)

This may seem non-portable, but it is not more non-portable than allowing
impl-defined aspects in the first place. After all an unrecognized aspect
(unlike an unrecognized pragma) is an illegality (though we could reconsider
that decision???)

BTW, in GNAT we will introduce new pragmas for new aspects like Invariant in any
case. The advantage of pragmas over aspects is that they can be retrofitted into
earlier versions of Ada.

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

From: Robert A Duff
Sent: Monday, August 16, 2010  2:15 PM

> Wouldn't it be easier to just list the standard aspects together with
> what declarations they apply to, then as implementation permission
> allow implementations to define implementation dependent aspects on
> whatever declarations they like

I don't see how this can work.  It's not just a "list of declarations" -- it's a
whole bunch of new syntax rules.  I don't think we want to let implementations
define their own syntax (in the standard-conforming mode).

Or am I misunderstanding the idea?

> (for instance in GNAT, the aspect
>
>     with Warnings => Off;
>
> applies to all entities)

Hmm.  The AI says you can't have an aspect clause on a renaming_declaration.
I think you can have pragma Warnings(Off) on a renaming...

> This may seem non-portable, but it is not more non-portable than
> allowing impl-defined aspects in the first place. After all an
> unrecognized aspect (unlike an unrecognized pragma) is an illegality
> (though we could reconsider that decision???)

Unrecognized pragmas are legal.  I guess you meant unrecognized attributes are
illegal.  But I don't see how to reconsider that -- the compiler needs to know
the overload resultion rules for every attribute.

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

From: Randy Brukardt
Sent: Monday, August 16, 2010  2:46 PM

> Unrecognized pragmas are legal.  I guess you meant unrecognized
> attributes are illegal.  But I don't see how to reconsider that -- the
> compiler needs to know the overload resultion rules for every
> attribute.

I think aspect clauses have the same problem: we need to know the expected type
for the expression of the aspect clause.

I suppose we might be able to say that the expression is not resolved at all in
that case; but that seems like a good way to hide errors (which depends on what
the compiler does with warnings, I guess). That is, if someone mistakenly
writes:

    when Invariant => Whatever,

rather than

    when Type_Invariant => Whatever,

they could get a false sense of security as Whatever wouldn't be checked.

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

From: Robert Dewar
Sent: Monday, August 16, 2010  3:19 PM

> I don't see how this can work.  It's not just a "list of declarations"
> -- it's a whole bunch of new syntax rules.  I don't think we want to
> let implementations define their own syntax (in the standard-conforming mode).
>
> Or am I misunderstanding the idea?

I would allow syntactically aspects after almost any declaration, whether
implementations take advantage of them is up to them.

>> (for instance in GNAT, the aspect
>>
>>     with Warnings => Off;
>>
>> applies to all entities)
>
> Hmm.  The AI says you can't have an aspect clause on a renaming_declaration.
> I think you can have pragma Warnings(Off) on a renaming...

Right, so why not allow

    X : Integer renames Y with Warnings => Off;

what's the harm?

>> This may seem non-portable, but it is not more non-portable than
>> allowing impl-defined aspects in the first place. After all an
>> unrecognized aspect (unlike an unrecognized pragma) is an illegality
>> (though we could reconsider that decision???)
>
> Unrecognized pragmas are legal.  I guess you meant unrecognized
> attributes are illegal.  But I don't see how to reconsider that -- the
> compiler needs to know the overload resultion rules for every
> attribute.

No, I meant *EXACTLY* what I said, unrecognized aspects are illegal, unlike
unrecognized pragmas which are legal. Reread my sentence it is exactly what I
meant to say! And it has nothing to do with attributes!

My suggestion was possibly that compilers be allowed to ignore unrecognized
aspects with a warning, like they do for pragmas.

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

From: Robert Dewar
Sent: Monday, August 16, 2010  3:26 PM

> I think aspect clauses have the same problem: we need to know the
> expected type for the expression of the aspect clause.

Not if you are ignoring it! It's the same as pragmas, if you ignore a pragma,
you ignore the expressions

> I suppose we might be able to say that the expression is not resolved
> at all in that case; but that seems like a good way to hide errors
> (which depends on what the compiler does with warnings, I guess). That
> is, if someone mistakenly writes:
>
>     when Invariant => Whatever,
>
> rather than
>
>     when Type_Invariant => Whatever,
>
> they could get a false sense of security as Whatever wouldn't be checked.

There would of course be a warning, same issue happens with pragmas now after
all.

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

From: Randy Brukardt
Sent: Monday, August 16, 2010  4:04 PM

...
> > Hmm.  The AI says you can't have an aspect clause on a renaming_declaration.
> > I think you can have pragma Warnings(Off) on a renaming...
>
> Right, so why not allow
>
>     X : Integer renames Y with Warnings => Off;
>
> what's the harm?

The harm is that is completely destroys the model of aspects (and of
renaming) in the language. All aspects have an important property that they are
the same for all views of an entity. An important correllary is that aspects are
not changed by renaming an entity.

If you have some property that is different for different views, then is it not
an aspect. (The language generally calls those things characteristics.) Ergo, it
cannot be specified by an aspect clause.

Warnings => Off is clearly not an aspect if it can apply to a rename.

If we did allow an aspect clause on a renames, we would need to invent some sort
of matching rules for aspects, since the language-defined aspects cannot be
changed on a renames. That is an utter mess (and it is why while we allow
aspects on generic formal parameters, there is a blanket rule disallowing the
use of any aspects there unless they are explicitly allowed and define an
appropriate matching rule).

Now, obviously no one is going to go around and check if any
implementation-defined things aren't formally aspects, but there is no reason
for the language to encourage the abuse of aspects by implementations. So if you
want to allow Warnings => Off as an aspect but not have it act like one, no one
is going to stop you, but it is still not right.

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

From: Robert Dewar
Sent: Monday, August 16, 2010  4:15 PM

It's useful, and useful to users of GNAT trumps Randy's idea of "right" :-)

Anyway, no big deal, for now, the GNAT aspects apply only to the official
declarations, and actually, to be truthful, I have had enough of molesting the
parser for these declarations, and don't really want to extend the use of
aspects, so I withdraw the suggestion.

I do think it's a pity that you can't have aspects on formal parameters of
subprograms. Oh well.

For interest here is the list of aspects implemented by GNAT (I did not do
Pre/Post condition, invariant, predicate yet)

     Ada_2005                      -- GNAT
     Ada_2012                      -- GNAT
     Address
     Alignment
     Atomic
     Atomic_Components
     Bit_Order
     Component_Size
     Discard_Names
     External_Tag
     Favor_Top_Level               -- GNAT
     Inline
     Inline_Always                 -- GNAT
     Invariant
     Machine_Radix
     No_Return
     Object_Size                   -- GNAT
     Pack
     Persistent_BSS                -- GNAT
     Post
     Pre
     Predicate
     Preelaborable_Initialization
     Pure_Function                 -- GNAT
     Shared                        -- GNAT
     Size
     Storage_Pool
     Storage_Size
     Stream_Size
     Suppress
     Suppress_Debug_Info           -- GNAT
     Unchecked_Union
     Universal_Aliasing            -- GNAT
     Unmodified                    -- GNAT
     Unreferenced                  -- GNAT
     Unreferenced_Objects          -- GNAT
     Unsuppress
     Value_Size                    -- GNAT
     Volatile
     Volatile_Components
     Warnings                      -- GNAT

This was the biggest AI to implement so far, LOTS of changes, but it seems to be
all working now.

I can easkly change to the model of immediate evaluation (I don't like it, but
Randy and Bob seem favorably inclined). Or to the deffered visibility analysis
that is in the AI (but that's horrible I think we can all agree).

I am dubious about changing to the business of resolving twice to see if you get
the same result, I don't see any easy way of doing that, but as I say, you never
know, things that seem difficult have a way of proving easier after all.

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

From: Robert A Duff
Sent: Monday, August 16, 2010  7:20 PM

> I would allow syntactically aspects after almost any declaration,
> whether implementations take advantage of them is up to them.

Seems reasonable.

> Right, so why not allow
>
>     X : Integer renames Y with Warnings => Off;
>
> what's the harm?

No harm.

> >> This may seem non-portable, but it is not more non-portable than
> >> allowing impl-defined aspects in the first place. After all an
> >> unrecognized aspect (unlike an unrecognized pragma) is an
> >> illegality (though we could reconsider that decision???)
> >
> > Unrecognized pragmas are legal.  I guess you meant unrecognized
> > attributes are illegal.  But I don't see how to reconsider that --
> > the compiler needs to know the overload resultion rules for every
> > attribute.
>
> No, I meant *EXACTLY* what I said, unrecognized aspects are illegal,
> unlike unrecognized pragmas which are legal.
> Reread my sentence it is exactly what I meant to say! And it has
> nothing to do with attributes!

Sorry for the noise!  I must have misread "unlike" to be "like", or something.
Now I understand.

> My suggestion was possibly that compilers be allowed to ignore
> unrecognized aspects with a warning, like they do for pragmas.

Seems OK.  No big deal -- any compiler can have warnings-as-errors mode, and/or
errors-as-warnings mode.

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

From: Randy Brukardt
Sent: Wednesday, September  1, 2010  10:54 PM

I'm putting the wording of this AI into the standard, and got mildly confused
over the meaning of "names" in wording like:

The names in an @fa<aspect_definition> are not resolved at the point of the
associated declaration, but rather are resolved at the end of the immediately
enclosing declaration list, or at the first freezing point of the associated
entity, whichever comes first.

I was wondering if this meant "name"s as in the syntax of 4.1, or really meant
identifiers and the like. Looking in 8.6, it uses "usage names" for the latter
(and this term is defined in 3.1(10) for this use). I suspect that this text in
AI05-0183-1 ought to be using "usage names" here and in similar paragraphs.

P.S. Note that this AI is still open and assigned to Tucker; I'm making some
rough fixes before putting part of it into the Standard (it has to be there so
that syntax references from other, approved AIs work).

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

From: Robert Dewar
Sent: Thursday, September  2, 2010  2:14 AM

What I have implemented for this in GNAT is that for aspects
precondition/postcondition, the resolution is delayed as described above.

For other aspects, such as size, the expression is treated like a default
initial expression, the names are resolved at the point of appearence, but
evaluation of the expression and associated freeing is delayed to the freeze
point.

I don't think there is any necessity for the kind of special checking that Randy
suggested that visibililty has not changed by the freeze point, at least for the
cases other than pre/postconditions, since the situation is no different from
default initial expressions, and visibility is at the point of occurrence.

For pre/postconditions, the situation that Randy is worrying about is something
like

      function Complete (A : Integer) is visible at this point

      declare
         procedure X (A : Integer) with
            Pre => Complete (A);

         function Complete (A : Integer);

         ....


Now in this situation, the Pre gets the inner Complete, not the outer Complete.
In general you definitely want this possibility of forward referencing for Pre
and Post since you want to be able to add pre/post conditions without having to
reorder subprogram declarations. We have implemented this for some time now in
GNAT with the precondition/postcondition pragmas, and I definitely think that's
highly useful, even though it is a bit unusual in terms of semantics of
visibility elsewhere in the language.

The question is, in the unusual situation (never seen it happen in practice) in
the example above, is the confusion of getting the inner Complete instead of the
outer Complete worth worrying about.

Three possible answers

a) don't worry about it, that's what we have done in GNAT, and so far, noone has
   been confused or bothered by such a case.

b) generate a warning, might be nice, not clear it is worth the effort, but in
   any case, not the job of the standard. I actually think that a warning is
   worth it in the inverse case:

          function Decorate (A : Integer) return Integer
          --  visible out here

          declare
             X : Integer := Decorate (12);

             function Decorate (A : Integer) return Integer;

             ...


where we get the outer Decorate instead of the inner one. But this warning would
be hard work and we have never considered it in GNAT.

c) Make this situation illegal and require a check. I don't like this for two
   reasons:

   --  It's hard to implement, requiring tinkering in a very
       delicate area of the compiler

   --  In practice I think there may be cases where you know
       what you want in the inner region, and it is annoying
       to have to modify names because of some function in the
       global environment that you don't know about and don't
       care about.

BTW, final list of aspects implemented in GNAT is:

>       Aspect_Ada_2005,                      -- GNAT
>       Aspect_Ada_2012,                      -- GNAT
>       Aspect_Address,
>       Aspect_Alignment,
>       Aspect_Atomic,
>       Aspect_Atomic_Components,
>       Aspect_Bit_Order,
>       Aspect_Component_Size,
>       Aspect_Discard_Names,
>       Aspect_External_Tag,
>       Aspect_Favor_Top_Level,               -- GNAT
>       Aspect_Inline,
>       Aspect_Inline_Always,                 -- GNAT
>       Aspect_Invariant,
>       Aspect_Machine_Radix,
>       Aspect_No_Return,
>       Aspect_Object_Size,                   -- GNAT
>       Aspect_Pack,
>       Aspect_Persistent_BSS,                -- GNAT
>       Aspect_Post,
>       Aspect_Pre,
>       Aspect_Predicate,                     -- GNAT???
>       Aspect_Preelaborable_Initialization,
>       Aspect_Pure_Function,                 -- GNAT
>       Aspect_Shared,                        -- GNAT (equivalent to Atomic)
>       Aspect_Size,
>       Aspect_Storage_Pool,
>       Aspect_Storage_Size,
>       Aspect_Stream_Size,
>       Aspect_Suppress,
>       Aspect_Suppress_Debug_Info,           -- GNAT
>       Aspect_Unchecked_Union,
>       Aspect_Universal_Aliasing,            -- GNAT
>       Aspect_Unmodified,                    -- GNAT
>       Aspect_Unreferenced,                  -- GNAT
>       Aspect_Unreferenced_Objects,          -- GNAT
>       Aspect_Unsuppress,
>       Aspect_Value_Size,                    -- GNAT
>       Aspect_Volatile,
>       Aspect_Volatile_Components,
>       Aspect_Warnings);                     -- GNAT

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

From: Bob Duff
Sent: Thursday, September  2, 2010   7:41 AM

> Three possible answers
>
> a) don't worry about it, that's what we have done in GNAT, and so far,
> noone has been confused or bothered by such a case.

This is my choice, although I don't think we have evidence that "noone has been confused" -- I'd say, "we don't know of anyone who has been confused or bothered, and it doesn't seem all that likely".

Two reasons:

1. As illustrated by (b) below, this sort of thing already occurs.  That's a
   language design flaw, but we're not going to fix it.  The case of (b) is
   rare, but the case we're talking about here is far more rare, hence silly to
   worry about.

2. If you didn't design your overload resolution with this in mind, then running
   overload resolution twice is a huge complication.  I would require this in a
   from-scratch language design, but now it just not worth it.

> b) generate a warning, might be nice, not clear it is worth the
> effort, but in any case, not the job of the standard. I actually think
> that a warning is worth it in the inverse case:
>
>           function Decorate (A : Integer) return Integer
>           --  visible out here
>
>           declare
>              X : Integer := Decorate (12);
>
>              function Decorate (A : Integer) return Integer;
>
>              ...
>
>
> where we get the outer Decorate instead of the inner one. But this
> warning would be hard work and we have never considered it in GNAT.

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

From: Bob Duff
Sent: Thursday, September  2, 2010  7:45 AM

> I was wondering if this meant "name"s as in the syntax of 4.1, or
> really meant identifiers and the like. Looking in 8.6, it uses "usage
> names" for the latter (and this term is defined in 3.1(10) for this
> use). I suspect that this text in AI05-0183-1 ought to be using "usage
> names" here and in similar paragraphs.

Yes, I think "usage names" would be OK.  Or perhaps, "Name Resolution is not
performed on aspect clauses at the point where they occur, but instead at the
end...".

The phrase "are not resolved" is pretty informal anyway, so I wouldn't spend too
much time getting this perfect, so long as we understand what it means.

By the way, in "at the first freezing point of the associated entity", I assume
the associated entity is the one we're defining an aspect of, not the entity
denoted by the usage name we're trying to resolve. Right?  The latter wouldn't
make sense.

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

From: Tucker Taft
Sent: Thursday, September  2, 2010  8:13 AM

Yes, "usage names" is probably more correct.

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

From: Tucker Taft
Sent: Thursday, September  2, 2010  8:18 AM

> ...
> By the way, in "at the first freezing point of the associated entity",
> I assume the associated entity is the one we're defining an aspect of,
> not the entity denoted by the usage name we're trying to resolve.
> Right?  The latter wouldn't make sense.
>

The wording includes a definition of the "associated entity"
I believe, and it is the entity whose aspect is being defined.

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

From: Randy Brukardt
Sent: Thursday, September  2, 2010  3:20 PM

...
> What I have implemented for this in GNAT is that for aspects
> precondition/postcondition, the resolution is delayed as described
> above.
>
> For other aspects, such as size, the expression is treated like a
> default initial expression, the names are resolved at the point of
> appearence, but evaluation of the expression and associated freeing is
> delayed to the freeze point.

That doesn't work for subprogram-valued aspects (such as the stream attributes).
When the type is declared, it's not possible for the stream routines to have
been declared yet (since they necessarily take the type name). Thus the delay in
resolution is needed.

[You may have not noticed that as your list of supported aspects seems to be
missing Read, Write, Input, and Output. :-)]

Given that it is needed in quite a few cases, it seems confusing to have
different resolution rules for different kinds of aspects. It also makes the
wording a lot larger, as the resolution rules would have to be described for
each individual aspect (probably using some simplified description so that the
entire description wouldn't need to be distributed).

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

From: Robert Dewar
Sent: Thursday, September  2, 2010  5:45 PM

I still think it would be a big mistake to delay resolution for things like Size
and Alignment, just plain confusing and unnecessary.

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

From: Robert Dewar
Sent: Friday, September  3, 2010  2:02 AM

> That doesn't work for subprogram-valued aspects (such as the stream
> attributes). When the type is declared, it's not possible for the
> stream routines to have been declared yet (since they necessarily take
> the type name). Thus the delay in resolution is needed.
>
> [You may have not noticed that as your list of supported aspects seems
> to be missing Read, Write, Input, and Output. :-)]

I agree these are missing, I was just guessing what should and should not be on
the list (as you know there is no list in the AI yet :-)

And of course, the delay is required for these.

I do see a somewhat clear distinction between the two classes of attributes, one
class establishes actions that will be applied when the entity is in use, not
when it is frozen, and the other supplies simple values that determine the
representation at freeze time.

> Given that it is needed in quite a few cases, it seems confusing to
> have different resolution rules for different kinds of aspects. It
> also makes the wording a lot larger, as the resolution rules would
> have to be described for each individual aspect (probably using some
> simplified description so that the entire description wouldn't need to be distributed).

I don't know about a "lot larger", relatively few aspects need this delay, and
all you need is a central description saying that the evaluation of some aspects
is delayed bla bla bla, and that these will be identified in separate sections
on the aspects, and then one sentence in each of the 7 or 8 aspects involved.

I must say that I am not so adamant as I was on avoiding the delay in the other
(great majority) of cases. It's certainly trivial to do, and in practice it will
never make a difference.

I would by the way at this stage be VERY opposed to some gizmo that made it an
error if the delay changes the visibility. This would have the very undesirable
effect of an outer change making an inner block illegal with no way to defend
against this in the inner block (that would be something new and undesirable).

I do agree that a warning would be nice

     warning: "ghx" refers to the entity declared on line 27
              not the entity declared on line 5.

But I looked into it, and generating this warning is definitely not easy. It's
on the list of enhancements, but I don't know if it will ever get done :-(

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

From: Tucker Taft
Sent: Friday, September  3, 2010  8:24 AM

One distinction we could use is operational aspects vs. representational
aspects.

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

From: Robert Dewar
Sent: Thursday, September  2, 2010  2:20 AM

One more point on aspect stuff.

For language defined aspects, we have agreed that aspects can only be specified
once. Personally I would prefer to allow multiple Pre/Post aspects, rather than
force the user to assemble them using AND THEN, and then make the compiler work
to disassemble them back into separate clauses so that decent messages can be
output, but I can live with (and have implemented) this restriction (although we
still allow multiple precondition and postcondition pragmas, as we always have).

But I think for implementation defined aspects, this requirement should be
relaxed. We lose nothing in portability by relaxing the requirement in this
case, and we definitely gain in flexibility.

We have encountered a number of situations, notably in connection with the
Hi-Lite project, where the aspect notation is very helpful, but we need to be
able to specify a particular aspect (e.g. Test_Case) multiple times.

Yes, we can always put this under the -gnatX (language extensions allowed)
switch, but I see no reason for the language enforcing this restriction for
aspects it knows nothing about!

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

From: Bob Duff
Sent: Thursday, September  2, 2010  7:35 AM

> But I think for implementation defined aspects, this requirement
> should be relaxed. We lose nothing in portability by relaxing the
> requirement in this case, and we definitely gain in flexibility.

I agree 100%.

More generally, whenever the RM allows implementation defined things, then the
implementation should have completely free rein to define the semantics of those
things.

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

From: Randy Brukardt
Sent: Thursday, September  2, 2010  3:50 PM

> But I think for implementation defined aspects, this requirement
> should be relaxed. We lose nothing in portability by relaxing the
> requirement in this case, and we definitely gain in flexibility.

This is really the wrong description. The basic model of aspects, as described
in 13.1, is that each one can only be specified once. The wording in the
standard unfortunately ties that to *how* it is specified, but that's really the
wrong model. I'd be in favor of eliminating the last sentences of 13.1(9) and
13.1(9.1/1) and replacing them with a blanket rule that an aspect can only be
specified once (in any way). The method of specification is irrelevant.

That's important as an aspect is a property of an entity, never a property of a
view of an entity: an aspect always has the same value for every view of an
entity.

One of the advantages of a blanket rule on aspects is that it gives you what you
want. There is nothing wrong with an implementation-defined characteristic (that
is *not* an aspect per-se) being specified in an aspect specifiication. (There
is no language purity cop passing on the language correctness of
implementation-defined stuff!!) In that case, the rules for aspects (such as
only one definition) don't necessarily apply.

So I am suggesting removing the last sentence of 13.1(9) and 13.1(9.1/1) (and
the corresponding wording in AI05-0183-1), and adding a new paragraph after
13.1(9.1/1):

It is illegal to directly specify an aspect of an entity (by any means) if there
is another representation item, operational item, or aspect clause for the same
aspect of the entity.

We might also want to loosen the wording of AI05-0183-1 at bit (or maybe just a
"to-be-honest" AARM note) to make it clear that implementations can use this
syntax for implementation-defined things that aren't quite aspects (that is,
they might allow multiple versions, they might be view dependent, etc.). (I
would not be surprised if we wanted to do that at some point down the road in
the Standard.)

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

From: Robert Dewar
Sent: Thursday, September  2, 2010  5:44 PM

> We might also want to loosen the wording of AI05-0183-1 at bit (or
> maybe just a "to-be-honest" AARM note) to make it clear that
> implementations can use this syntax for implementation-defined things
> that aren't quite aspects (that is, they might allow multiple
> versions, they might be view dependent, etc.). (I would not be
> surprised if we wanted to do that at some point down the road in the
> Standard.)

Right, all I am arguing for is freedom in implementation defined aspects. after
all you can't make legitimate ACATS tests for such attributes anyway, so any
restrictions would be untestable :-)

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

From: Robert Dewar
Sent: Friday, September 10, 2010  10:59 AM

Revisiting the delayed evaluation issue.

Clearly read/write/input/output HAVE to be delayed, otherwise they would be
useless, since in 100% of the cases you will reference entities not declared
yet.

I think we all agree that it is really useful to delay precondition,
postcondition in the same way. Note that the GNAT pragmas have always
implemented this delay.

Invariant really has to be delayed too, since often the expression will be a
function call referencing the type to which the aspect is attached.

So we have a bunch of cases where the full delay is required (no visibility
analysis till the end of the declarative part).

So revisiting the issue of other aspects, e.g.

     type R is range 1 .. 10 with
        Size => S'Size;

Originally I liked the idea that this was equivalent
to:

     type R is range 1 .. 10;
     for R'Size use S'Size;

Since that is easy to explain, and does not cause any surprises.

But Tuck argues that there will be too many cases where this causes premature
freezing, so instead he argues for a preanalysis (like default expressions) to
establish visibility at the point of declaration, but then leave the full
analysis (and freezing) to the end of the declarative part.

Randy argues that it is too confusing to have different rules.

I must say I am inclined to change my mind, if we can't have the simple
equivalence I first suggested, I think I would prefer uniformity. In practice
for something like Size, it will never make a difference. Yes you can create
examples where it does make a difference but these will be very rare in
practice, and in any case we have some of those same situations with
precondition/postcondition or invariant delays.

The AI is written delaying everything, and I think that's probably the better
choice, and is also the path of least resistance (no change needed).

If we go this route, it will be trivial to change the GNAT implementation to
conform to this (just a matter of removing the boolean variable Delay_Required,
since it will now always be True :-))

Randy has also argued for making the situation where the visibility changes
illegal, e.g. the following would be illegal:

        type R is range 1 .. 512;

        declare
           type S is range 1 .. 10 with
             Size => R'Size;

           type R is range 1 .. 511;

        begin
           ...

I don't mind having or suggesting a warning in this situation (though at least
for us this is extremely difficult to do, yes its conceptually easy to do the
analysis twice and see if it changed, but it would have a big impact on the
details of visibility processing).

I do mind VERY MUCH making this illegal, it seems a really bad idea that you
write a declare block with no global references, and it's legal, and then you
add a global declaration to some withed package miles away and suddenly:

a) the declare block is illegal

b) the only way to defend against it is to change
    names (fiddling till you find something that does
    not happen to be used globally now, and hoping
    it won't be used later).

So I am really opposed to trying to forge illegality rules here. Yes, you can
construct confusing cases like the one above (which can be made more confusing
by adding hundreds of declarations before the second declaration of R), but in
practice such cases will be very rare.

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

From: Christoph Grein
Sent: Tuesday, September 28, 2010  2:33 AM

6.7(2/3) null_procedure_declaration ::=
[overriding_indicator]
procedure_specification is null
[aspect_specification];;

Additional semicolon at end.

[Editor's note: This is a typo in the draft AARM.]

13.3.2 (16/3) ... a precondition check is performed. This begins with the
evaluation of the precondition expressions that apply to the subprogram or
entry... The order of performing the checks is not specified, ...

Does it make sense to say with which check the evaluation begins without
saying what then follows, and at the same time specifying that the sequence of
checks is unspecified?

(No further comments since the chapters 13.3.1 and 2 are incomplete.

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

From: Randy Brukardt
Sent: Tuesday, September 28, 2010  9:00 PM

Probably not. The additional of "begins" doesn't seem to add anything here;
the rest of it says what's done with the results of the evaluation and makes
it clear that they all might not be evaluated. The wording probably would be
better to just say "The check evaluates the precondition expressions..." or
even "This evaluates...".

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

From: Robert Dewar
Sent: Monday, October 25, 2010  3:08 PM

Did we (by default if no other way) decide that all aspects get delayed to the
end of the declarative region, i.e. that this works fine:

      type R is range 1 .. 10 with
        Size => R_Size;
      R_Size : constant := 8;

I don't really mind, but I would like to implement what's decided. I am still
a bit worried about circular address clauses.

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

From: Tucker Taft
Sent: Monday, October 25, 2010  2:55 PM

Here is a relatively minor update to AI05-0183-1. [This is version /06 of
the AI.]

I added a requirement that all usage_names that appear in an aspect_definition
resolve to the same thing if freezing happens before the end of the declaration
list, along with an example in the !discussion.

I added some general statements about attribute-defs and pragmas that can be
replaced by aspect_specs.

I made some other minor fixes as requested in the minutes.

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

From: Robert Dewar
Sent: Monday, October 25, 2010  3:13 PM

> If the freezing point comes before the end of the enclosing
> declaration list, we require the usage names in the aspect_definition
> to resolve to the same entities at the two places.  Because there is
> no explicit indication of where a freezing point occurs in the source,
> we felt it would be too confusing if we didn't require this.

I really have NO idea how to implement this without a major earthquake.
I think we will just leave this unimplemented in GNAT and not bother with it. At
this stage ACATS tests are merely useful tools anway, formal validation has
entirely disappeared as an issue.

Perhaps Ed has some ideas.

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

From: Tucker Taft
Sent: Monday, October 25, 2010  3:19 PM

Did you take a look at the example in the !discussion?
It does seem pretty convincing (at least to me) that this is a legitimate
concern.  Here it is again.

===

If the freezing point comes before the end of the enclosing declaration list, we
require the usage names in the aspect_definition to resolve to the same entities
at the two places.  Because there is no explicit indication of where a freezing
point occurs in the source, we felt it would be too confusing if we didn't
require this.  This means that if a freezing point "moves" and thereby crosses
over, for example, the overriding of an inherited subprogram (of a non-tagged
type), the compiler would complain rather than silently reinterpreting the name
in the aspect_definition.  For example:

     type New_T is new T
       with Type_Invariant => Is_Valid(New_T);

     Default_Obj : New_T;  -- Here we freeze New_T

     function Is_Valid(Y : New_T) return Boolean;
       -- Here we override Is_Valid

   private  -- Here we reach the end of the declaration list.

In a case like this, the user almost certainly wants to refer to the overriding
of Is_Valid, but since the freezing happens before the overriding, without the
rule to require that the names in the aspect_definition resolve to the same
thing, they would not get what they expected.  With this rule, the compiler
would complain, and the user would (hopefully ;-) realize they need to move the
declaration of Default_Obj down a little further so Is_Valid can be overridden
first.

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

From: Robert Dewar
Sent: Monday, October 25, 2010  3:54 PM

Are these things really called Type_Invariant, rather than just Invariant? I
don't really mind, but it is a pain to change and I prefer the shorter name
anyway.

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

From: Robert Dewar
Sent: Monday, October 25, 2010  3:55 PM

> Did you take a look at the example in the !discussion?
> It does seem pretty convincing (at least to me) that this is a
> legitimate concern.  Here it is again.

I think whenever you cause a major impossible pain to an existing implementation
(Ed agrees with me that this is that category), then you have to be sure it is
worth it. To recall, for Ada 95, we went out of our way to accomodate displays
because one implementation demanded it, despite the fact that it

a) really damaged expressive power

b) turned out to be quite unnecessary, the one implementation involved never
   made it to Ada 95 anyway.

I don't think this begins to be in the category of critical things that are
worth causing major pain to an implementation (especially considering that you
can't really do that any more, implementations will just ignore things they
can't implement, especially when it is just a matter of diagnosing unexpected
behavior).

To me this is more in the warning category anyway I would just settle for
implementation advice that says it is desirable to warn in this situation.

Yes, I see the example, but as I say, it is more a case where a warning is more
appropriate anyway, I am always nervous when I see a language designer say

"the user almost certainly wants to ..."

which is more likely worth a warning if true.

In this case, what GNAT could do, and actually it seems a good idea, is to have
optional information messages that say

    "warning: Invariant expression from line 12 is resolved here"
    "warning: since type& is frozen here"

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

From: Robert Dewar
Sent: Thursday, October 28, 2010  5:29 AM

Back to implementation .. I am still furiously trying to figure out a way to do
even a partial job of the proposed requirements for aspects of making it illegal
for the visibiliy to change between the freeze point and the end of the
declarative part.

This is *really* hard, because analysis in our compiler has all kinds of side
effects (generating error messages if the analysis fails, generating
cross-references, generating internal entities, etc) all of which is really hard
to turn off for a trial visibility analysis).

I think the best I can do for now is the warning I proposed:

      warning: "foo" aspects analyzed here (at freezing point)

or some such, the warning can easily be suppressed in the common case where
there is obviously no possibility of a shift in visibility (e.g. Size => 32),.

Oddly PAck => True (if this form survives) is not such a case because of the
infamous possibility of

     True : Booelan := False;

on the other hand, this is just a warning, so we really don't need the warning
if someone writes an idiotic test that does this :-)

In practice I suspect the ONLY case where there is a concern will be the (rather
worrisome) example of the call to an overridden function.

Will be interesting to see how many false positives such a warning generates.

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

From: Tucker Taft
Sent: Thursday, October 28, 2010  7:14 AM

Could you create two copies of the tree, analyze one at the freezing point, and
the other at the end of the enclosing declaration list, and then do your normal
expression conformance check between them, similar to what you do between the
default expressions on a spec and a body?

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

From: Robert Dewar
Sent: Thursday, October 28, 2010  7:24 AM

The problem is that this bogus analysis will have all sorts of side effects,
such as making bogus extra references, and creating bogus internal entities not
to mention generating bogus error messages if the second analysis simply fails
because the new visibility gives e.g. type errors. Of course such type errors
would be formally conforming, but could result in very obscure messages.

Looking at this right now, using the conformance mechanism is indeed an
interesting idea.

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

From: Bob Duff
Sent: Thursday, October 28, 2010  7:30 AM

> This is *really* hard,...

Yeah, I really doubt it's worth all this trouble.
Can't we solve the problem with some warnings?
E.g. collect up a set of names used in the aspect expression, and see if
something of the same name is later declared.  Or something like that.

Tucker's rule is far more elegant, but nobody planned for that in their compiler
designs.

> In practice I suspect the ONLY case where there is a concern will be
> the (rather worrisome) example of the call to an overridden function.

Well, we could record a use of a primitive in an aspect, and wanrn later if it
gets overridden.  Or something like that.

P.S. Sorry you're sick.  Take it easy, and get well soon!

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

From: Robert Dewar
Sent: Thursday, October 28, 2010  7:36 AM

> Tucker's rule is far more elegant, but nobody planned for that in
> their compiler designs.

I am seeing if I can kludge something that is general, stay tuned!

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

From: Robert Dewar
Sent: Friday, October 29, 2010  11:56 AM

OK, installed a rather giant kludge, but it's at least beginning to work:

(I do find that example that Tuck quoted convincing!)

      1. pragma Ada_2012;
      2. package AspectVis is
      3.    R_Size : constant Integer := 32;
      4.
      5.    package Inner is
      6.       type R is new Integer with
      7.         Size => R_Size;
                 |
         >>> visibility of aspect for "R" changes after freeze point

      8.       F : R; -- freezes
               |
         >>> info: "R" is frozen here, aspects evaluated at this point

      9.       R_Size : constant Integer := 64;
     10.       S : constant Integer := R'Size; -- 32 not 64
     11.    end Inner;
     12. end AspectVis;

  12 lines: 1 error, 1 warning
Tuck, thanks for the suggestion of using conformance checking to compare the two
expressions, very valuable!

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

From: Robert Dewar
Sent: Friday, October 29, 2010  2:33 PM

Ha, I found an interesting bug in using conformance to check equivalence of
expressions

   A : Integer := 32;
   package P is
     type R is new integer with Size => A;
     RR : R;
     A : Integer := 32;
   end P;

the expression ends up being a static expression with value 32 before and after
the freeze, so they conform, but do not meet the rule of names being separate.

Fixable, but entertaining!

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

From: Brad Moore
Sent: Friday, November 12, 2010  8:24 AM

> Well, I did say I only had brief glimpses but it did seem that there was the
> risk of confusion with multiple use of with.

I'm wondering if it's a bit messy that the aspect syntax for a package
declaration ends up being quite different than the aspect syntax for a package
instance declaration. In the first case, the aspects come immediately before the
"is", and in the second case they comes a long ways after the "is".  This is the
reason my previous example had the incorrect syntax. I had mistakenly assumed
that aspects for all package declarations came before the "is". I wonder how
many others will make that same mistake.

Instead of writing;

package P1 with Pure is
end P1;

package P2 is new P3 with Pure;

Would it be better to write?

package P1 with Pure is
end P1;

package P2 with Pure is new P3;

In the case of the instantiation, it seems clearer to me that the Pure attribute
is now being associated with the new package, rather than somehow being
associated with the original package.

If package declarations are a special case for aspect syntax, maybe package
instance declarations should be lumped into that special case as well.

I suppose one might argue that its better to limit the special case as much as
possible, rather than have it creep into other syntax forms.

On the other hand, maybe all aspect clauses should come before the "is", This
would eliminate the special case, and might make things more consistent.

Some examples ...

full_type_declaration example-------------------------

type T1 (Length : Integer) with pack is
    record
        S : String (1 .. Length);
    end record;

instead of

type T1 (Length : Integer) is
     record
         S : String (1 .. Length);
    end record with pack;

task type declaration aspects already come before the is -----------

protected type declaration aspects already come before the is ---------

private type declaration example ---------------------

type T1 (Length : Integer) with pack is limited private;
instead of
type T1 (Length : Integer) is limited private with pack;

private extension declaration example -------------------

type T1 (Length : Integer) with pack is new limited T2 with private;
instead of
type T1 (Length : Integer) is new limited T2 with private with pack;

(I find these last two examples particularly compelling. The fact that this is
an incomplete declaration can get lost in the declaration. I think private
should be the last word)

object declarations don't have an is ---------------------

function and procedure specifications don't have an is -------------

This is not an exhaustive list of examples, but I don't see any others offhand
that would be problematic. In many cases I find the declarations read better
having the aspect come before the is.

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

From: Robert Dewar
Sent: Friday, November 12, 2010  8:32 AM

> I'm wondering if it's a bit messy that the aspect syntax for a package
> declaration ends up being quite different than the aspect syntax for a
> package instance declaration. In the first case, the aspects come
> immediately before the "is", and in the second case they comes a long
> ways after the "is".  This is the reason my previous example had the
> incorrect syntax. I had mistakenly assumed that aspects for all
> package declarations came before the "is". I wonder how many others
> will make that same mistake.

Actually GNAT has this wrong, and it is a huge pain, because it means you have
to get all the way through the aspects then start looking at what is after IS,
to know that the aspects you have parsed do not belong there. This is really
messy.

I agree with Brad, this is confusing, I would always put the aspects before IS
for all the program unit type syntax.

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

From: Tucker Taft
Sent: Friday, November 12, 2010  8:52 AM

I agree that the placement of the aspect specification is a bit tricky.  I
actually found the placement before the "is new" quite jarring.  But it is
annoying that the placement jumps around depending on the construct.  The one
that seems hardest for me to remember is the one for a record type.

The general rule is that it comes just before the ";" except for a non-instance
package specification, task declaration, or protected declaration, where it
comes just before the "is".

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

From: Bob Duff
Sent: Friday, November 12, 2010  9:07 AM

> In many cases I find the declarations read better having the aspect
> come before the is.

Hmm.  I think I agree.

The "with private with Pack" syntax seems particularly odd.

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

From: Stephen Michell
Sent: Friday, November 12, 2010  11:07 AM

Good catch Brad. I think that you explained that well.

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

From: Tucker Taft
Sent: Friday, November 12, 2010  11:26 AM

What about "type T is new Integer;"?
Or "procedure Foo(X: Integer) is null;".
And what about "renames"?  Is "renames" like "is"?

Not an easy choice...
On the other hand, once we make it, the compiler will help us all learn what is
the right way to do it. ;-)

I think I still somewhat prefer seeing aspect specifications at the end unless
that is ridiculously far away as in a non-instance package spec. This is
especially true if they start getting complex, as in:

   with Dynamic_Predicate =>
     Sorted_Arr_Type(Arr_Type'First) <= Sorted_Arr_Type(Arr_Type'Last)

This seems like something that doesn't want to be interspersed in the middle of
an array type definition.

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

From: Randy Brukardt
Sent: Friday, November 12, 2010  4:30 PM

> What about "type T is new Integer;"?
> Or "procedure Foo(X: Integer) is null;".
> And what about "renames"?  Is "renames" like "is"?

The last isn't possible: we don't allow aspects on renames. (Aspects are the
same as those from the renamed object, since they're not view-specific.)

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

From: Robert Dewar
Sent: Saturday, November 13, 2010  5:26 AM

> What about "type T is new Integer;"?

No one is suggesting the change here, don't use it as a strawman.

> Or "procedure Foo(X: Integer) is null;".

No one is suggesting the change here, don't use it as a strawman.

> And what about "renames"?  Is "renames" like "is"?

No, it isn't, no one has suggested that either.

The suggestion is simply to treat the unit cases differently and uniformly.

> I think I still somewhat prefer seeing aspect specifications at the
> end unless that is ridiculously far away as in a non-instance package
> spec.
> This is especially true if they start getting complex, as in:
>
>     with Dynamic_Predicate =>
>       Sorted_Arr_Type(Arr_Type'First)<= Sorted_Arr_Type(Arr_Type'Last)
>
> This seems like something that doesn't want to be interspersed in the
> middle of an array type definition.

No one is suggesting interspersing this, don't use it as a strawman :-)

The suggesting is that we should have uniform treatment for

   package pack is bla;

regardless of what bla is, and I think that's a real improvement over what you
propose. To me it is just weird (to the parser and to a human reader to have)

   package pack with
     lots of aspects
   is

and still not know if the aspects belonged there. It's not hard to implement
in the parser of course, but it's a real oddity to treat these cases
differently, and will surely cause confusion.

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

From: Robert Dewar
Sent: Saturday, November 13, 2010  5:27 AM

>> What about "type T is new Integer;"?
>> Or "procedure Foo(X: Integer) is null;".
>> And what about "renames"?  Is "renames" like "is"?
>
> The last isn't possible: we don't allow aspects on renames. (Aspects
> are the same as those from the renamed object, since they're not
> view-specific.)

Personally I would prefer the rule to be that we allow aspects, but none of the
language ones can be used for renamings, since that allows useful use of the
notation for implementation defined aspects, but it's not a big deal, and if we
have an arbitrary limitation that prevents this, we can live with it.

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

From: Bob Duff
Sent: Saturday, November 13, 2010  7:50 AM

> Personally I would prefer the rule to be that we allow aspects, but
> none of the language ones can be used for renamings, since that allows
> useful use of the notation for implementation defined aspects, ...

I agree.

>...but it's not a
> big deal, and if we have an arbitrary limitation that prevents this,
>we  can live with it.

That, too.

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

From: Bob Duff
Sent: Saturday, November 13, 2010  7:44 AM

> > What about "type T is new Integer;"?
>
> No one is suggesting the change here, don't use it as a strawman.
...
> The suggestion is simply to treat the unit cases differently and
> uniformly.

Brad's suggestion goes further than that, so I don't see any "straw men" from
Tucker.

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

From: Brad Moore
Sent: Saturday, November 13, 2010  10:42 AM

> The general rule is that it comes just before the ";" except for a
> non-instance package specification, task declaration, or protected
> declaration, where it comes just before the "is".

There is something to be said though, for simpler rules being easier to
memorize.

E.g. It always comes before "is", otherwise comes before ";"

> What about "type T is new Integer;"?

I find this to be a similar case to the package instantiation declaration.
If the aspects are at the end, it might be confusing for a novice because one
might think the aspects are somehow defining requirements on the base type. If
they come after the type name it is clearer that they apply to the new type.

eg.

type T is new Foo with Atomic;

vs

type T with Atomic is new Foo;


> Or "procedure Foo(X: Integer) is null;".

I find this case to be similar to the private type and private extension case.

The important part of the declaration is that it is a null procedure.
If the aspects at the end, the "is null" might get lost in the text.

eg.

     procedure Foo (C : Class; X : in out Integer)
     is null
          with Pre'Class => X = 0, Post'Class => X > 0; vs
     procedure Foo (C : Class; X : in out Integer)
             with Pre'Class => X = 0, Post'Class => X > 0
     is null;

> And what about "renames"?  Is "renames" like "is"?

According to the latest version of AI 183, aspects are not permitted on renaming
declarations. Is that still correct?

> I think I still somewhat prefer seeing aspect specifications at the
> end unless that is ridiculously far away as in a non-instance package
> spec.
> This is especially true if they start getting complex, as in:
>
>   with Dynamic_Predicate =>
>     Sorted_Arr_Type(Arr_Type'First) <= Sorted_Arr_Type(Arr_Type'Last)
>
> This seems like something that doesn't want to be interspersed in the
> middle of an array type definition.

I share your concern. It might end up looking weird if it appears that a bunch
of code occurs in the middle of a declaration.

type Sorted_Arr_Type is array (Integer range <>) of Foo
    with Dynamic_Predicate =>
        Sorted_Arr_Type(Arr_Type'First) <= Sorted_Arr_Type(Arr_Type'Last) ;

vs

type Sorted_Arr_Type
     with Dynamic_Predicate =>
        Sorted_Arr_Type(Arr_Type'First) <= Sorted_Arr_Type(Arr_Type'Last)
   is array (Integer range <>) of Foo;

The first version is more pleasing to my eye, though the second isn't horrible.
I think I like the first better in this case, because it fits better on
3 lines.
The second one "looks" bigger.

With shorter aspects, I find my preference goes the other way.

eg

I like
type Sorted_Arr_Type with Atomic_Components is array (Integer range <>) of Foo;

better than

type Sorted_Arr_Type is array (Integer range <>) of Foo with Atomic_Components;

Probably to convince ourselves one way or the other, we need to look at a more
complete set of examples.

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

From: Tucker Taft
Sent: Saturday, November 13, 2010  10:44 AM

>>> What about "type T is new Integer;"?
>>
>> No one is suggesting the change here, don't use it as a strawman.
> ...
>> The suggestion is simply to treat the unit cases differently and
>> uniformly.
>
> Brad's suggestion goes further than that, so I don't see any "straw
> men" from Tucker.

Correct.  I was reacting to Brad's suggestion that we move *all*
aspect_specifications before the "is", including on "normal" type definitions.
I understand Brad's motivation, but I was illustrating why I think it would be
unwise.

As far as package instantiations, I can see accept it either way, though I did
react somewhat negatively when I first saw it before the "is new".

I presume we are not allowing aspect specifications on bodies.  If we were, then
I would wonder where the aspect_specification should go on:

    procedure Blubber(...) is null/abstract;

Before the "is" or before the ";".
Ditto for a subprogram instantiation.

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

From: Jean-Pierre Rosen
Sent: Saturday, November 13, 2010  10:55 AM

> I find this to be a similar case to the package instantiation declaration.
> If the aspects are at the end, it might be confusing for a novice
> because one might think the aspects are somehow defining requirements
> on the base type. If they come after the type name it is clearer that
> they apply to the new type.
>
> eg.
>
> type T is new Foo with Atomic;
>
> vs
>
> type T with Atomic is new Foo;

I prefer the first one, because I read it as "type T is a foo, with an extra
property: it is atomic".

[...]
> Probably to convince ourselves one way or the other, we need to look
> at a more complete set of examples.

I fully agree with that statement!

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

From: Robert Dewar
Sent: Saturday, November 13, 2010  8:23 PM

> Brad's suggestion goes further than that, so I don't see any "straw
> men" from Tucker.

I had not realized that Brad was suggesting

    type x is array with size => 64 of ...

I find that suggestion ludicrous, are you really sure Brad was suggesting this?

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

From: Robert Dewar
Sent: Saturday, November 13, 2010  8:28 PM

> type T is new Foo with Atomic;
>
> vs
>
> type T with Atomic is new Foo;

So Brad really *was* suggesting this. Apologies for the straw man comment to
Tuck.

Well I think it is simply horrible to read, and do not support this change at
all.

> eg.
>
>       procedure Foo (C : Class; X : in out Integer)
>       is null
>            with Pre'Class =>  X = 0, Post'Class =>  X>  0; vs
>       procedure Foo (C : Class; X : in out Integer)
>               with Pre'Class =>  X = 0, Post'Class =>  X>  0
>       is null;

Again, IMO horrible! I really dislike putting aspects before the IS in these
cases.

> Probably to convince ourselves one way or the other, we need to look
> at a more complete set of examples.

Except for the package case which we are still discussing, I think we have a
fine set of rules now, and I see no significant argument for changing them.

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

From: Robert Dewar
Sent: Saturday, November 13, 2010  8:29 PM

> Correct.  I was reacting to Brad's suggestion that we move *all*
> aspect_specifications before the "is", including on "normal" type
> definitions.  I understand Brad's motivation, but I was illustrating
> why I think it would be unwise.

I 100% agree with you Tuck on this!

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

From: Brad Moore
Sent: Saturday, November 13, 2010  10:03 PM

>> type T is new Foo with Atomic;
>>
>> vs
>>
>> type T with Atomic is new Foo;
>
> So Brad really *was* suggesting this. Apologies for the straw man
> comment to Tuck.

Well, I actually had two independent suggestions.

One was just do deal with the package instantiation case, and the other was a
more general suggestion as an attempt to bring a more consistent approach with
regard to aspect placement when "is" is present.

For the package instantiation case, you convinced me a while back that the
aspect on a package declaration has to come before the "is". That suggests to me
that to do anything about the package instantiation case, the aspect would
likely also have to come before the "is", unless someone comes up with a better
idea.


Just curious though,

Do you also prefer

type T is new Foo with private with pack;

over

type T with pack is new Foo with private;

Having two with's connected together with very different meaning seems like it
could be a source of confusion, and I imagine might be awkward to explain to a
class of Ada 101 students.

Maybe it would be nice if we could combine the two with's into one, and treat
private as a sort of pseudo-aspect for private types and private extensions.

eg.

type T is new Foo with private, pack;

I suspect that I've already stirred up enough with my previous suggestions.
I think I better put on my asbestos suit and crash helmet.... :-)

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

From: Robert Dewar
Sent: Sunday, November 14, 2010  9:58 AM

(grab flame thrower!)

> For the package instantiation case, you convinced me a while back that
> the aspect on a package declaration has to come before the "is". That
> suggests to me that to do anything about the package instantiation
> case, the aspect would likely also have to come before the "is",
> unless someone comes up with a better idea.

It doesn't *have* to come before the IS, I slightly prefer that it does, but can
live with Tuck's viewpoint, and the latter has the advantage of being the status
quo!

> Just curious though,
>
> Do you also prefer
>
> type T is new Foo with private with pack;

Yes, I prefer this consistent form, even though depending how you write it, it
could be confusing, for me, the format would always be

   type T is new Foo with private with
     Pack => True;

BTW I think I *do* prefer to keep the => True possibility (again has the
advantage of being the status quo), precisely because it makes it very clear
that you are talking about the aspect case syntactically. I would not insist on
it, but I would usually use it I think in a case like this.

> over
>
> type T with pack is new Foo with private;
>
> Having two with's connected together with very different meaning seems
> like it could be a source of confusion, and I imagine might be awkward
> to explain to a class of Ada 101 students.

I doubt this (illegal) form would be a likely discussing item in Ada 101, and I
really don't think it's such a problem anyway.

> Maybe it would be nice if we could combine the two with's into one,
> and treat private as a sort of pseudo-aspect for private types and
> private extensions.
>
> eg.
>
> type T is new Foo with private, pack;

Absolutely not, this is a gratitous and troublesome change in existing syntax.

> I suspect that I've already stirred up enough with my previous suggestions.
> I think I better put on my asbestos suit and crash helmet.... :-)

suit up!

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

From: Randy Brukardt
Sent: Monday, November 15, 2010  4:15 PM

...
> Well, I actually had two independent suggestions.
>
> One was just do deal with the package instantiation case, and the
> other was a more general suggestion as an attempt to bring a more
> consistent approach with regard to aspect placement when "is" is
> present.
>
> For the package instantiation case, you convinced me a while back that
> the aspect on a package declaration has to come before the "is". That
> suggests to me that to do anything about the package instantiation
> case, the aspect would likely also have to come before the "is",
> unless someone comes up with a better idea.

I sympathize with this position.

But keep in mind that presuming that we leave aspect clause placement for
subprograms as it is, we have a nasty problem with instances, in that they are
used both for subprograms and packages. (And I'm presuming that subprograms are
left as is since the current syntax reads the best for Pre and Post.)

Given that subprograms are written thus:

    procedure Pro (A, B : in Integer) with Pre => A > B;

and packages are written thus:

    package Pack with Pure => True is
        ...

we have three choices for instantiations:

(1) Always at the end (like subprograms); the existing proposal:

   procedure Pro is new Gen_Pro with Inline => True;

   package Pack is new Gen_Pack with Pure => True;

(2) Always before the is (like packages); the new proposal (I think):

   procedure Pro with Inline => True is new Gen_Pro;

   package Pack with Pure => True is new Gen_Pack;

(3) Always the same as the associated non-generic entity:

   procedure Pro is new Gen_Pro with Inline => True;

   package Pack with Pure => True is new Gen_Pack;


(1) is inconsistent with packages; (2) is inconsistent with subprograms; and
(3) is inconsistent between types of instantations. This doesn't seem
particularly good no matter what we choose.

I do think package instantiations are more common than subprogram instantations,
so that argues for using (2) or (3). I think I slightly lean toward (3), but
none of them is clearly better than the others.

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

From: Tucker Taft
Sent: Monday, November 15, 2010  4:46 PM

I think I still prefer choice (1), that is, the current AI wording.  Putting
more stuff into the middle of an instantiation seems unwieldy.

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

From: Robert Dewar
Sent: Monday, November 15, 2010  5:28 PM

I agree with this, and plan to change the GNAT implementation to conform with
this thinking.

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

From: Brad Moore
Sent: Monday, November 15, 2010  7:27 PM

> (1) is inconsistent with packages; (2) is inconsistent with
> subprograms; and
> (3) is inconsistent between types of instantations. This doesn't seem
> particularly good no matter what we choose.
>
> I do think package instantiations are more common than subprogram
> instantations, so that argues for using (2) or (3). I think I slightly
> lean toward (3), but none of them is clearly better than the others.

Actually, there is one other set of possibilities which so far has not been
discussed, (to the best of my knowledge).

This again comes as two separate somewhat independent suggestions.

1) To just fix the package declaration case, move the aspect to immediately
before the semi-colon.

eg.
        package Ada is
        end Ada with Pure;

For a larger package declaration the aspect comes long after where the pragma
would typically appear. However, this might be something we get used to, perhaps
a small price to pay for having a more consistent syntax.

I suspect for smaller, simpler package specs, this form would generally be
preferable to using pragmas. For larger packages, it may be a style preference,
but there's nothing saying you can't still use pragmas, if you think that makes
better sense.

Since I had my eyebrows singed from yesterdays email :-) , I might as well
continue with my other suggestion, which you can probably already guess.

2) That is, we could say that *all* aspect syntax always comes immediately
before the semi-colon.

This would make for a very simple rule for people to remember.

It only impacts task type and protected type declarations (and package
declarations), as those are the only syntax forms where aspect clauses come
before the "is".

Again, it might take a bit of getting used to, but might be worthwhile if the
benefits outweigh the costs.

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

From: Robert Dewar
Sent: Monday, November 15, 2010  7:57 PM

> eg.
>          package Ada is
>          end Ada with Pure;

I *very* strongly dislike this, you really want to see the Pure or Preelaborate
at the start of the package and not at the end of the private part. This is why
we require the pragmas to be at the start after all.

> I suspect for smaller, simpler package specs, this form would
> generally be preferable to using pragmas. For larger packages, it may
> be a style preference, but there's nothing saying you can't still use
> pragmas, if you think that makes better sense.

You are saying "we did a bad job of designing placement of attributes so in a
large package [almost any package is large enough as far as I am concerned] you
won't be happy using the lousily designed aspect syntax. Never mind, we were
forced to keep the pragmas for compatibility reasons, so you can still use
those.

> Since I had my eyebrows singed from yesterdays email :-) , I might as
> well continue with my other suggestion, which you can probably already
> guess.
>
> 2) That is, we could say that *all* aspect syntax always comes
> immediately before the semi-colon.
>
> This would make for a very simple rule for people to remember.
>
> It only impacts task type and protected type declarations (and package
> declarations), as those are the only syntax forms where aspect clauses
> come before the "is".
>
> Again, it might take a bit of getting used to, but might be worthwhile
> if the benefits outweigh the costs.

Again, simply horrible, this is consistency gone mad!

At this stage, I am strongly in favor of maintaining the status quo as written
up. The suggestions for changing it seem to be opening up a can of worms (aka
horrible suggestions for changing things).

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

From: Randy Brukardt
Sent: Monday, November 15, 2010  8:05 PM

...
> This again comes as two separate somewhat independent suggestions.
>
> 1) To just fix the package declaration case, move the aspect to
> immediately before the semi-colon.
>
> eg.
>         package Ada is
>         end Ada with Pure;
>
> For a larger package declaration the aspect comes long after where the
> pragma would typically appear.
> However, this might be something we get used to, perhaps a small price
> to pay for having a more consistent syntax.

It's not about "getting used to it". It's about adding a whole lot of
implementation difficulty. "Pragma Pure" is implemented by setting a compiler
flag or state, and then checking each declaration as it appears whether it meets
the requirements of that flag/state. That cannot be done if the aspect is at the
end.

The same holds anytime the aspect can affect the legality of the contents; that
is, anytime there are significant independent declarations inside of the entity.
Which is the program unit cases that you don't like.

If we were to move the aspects to the end, then we'd have to drop the idea of
converting program-unit pragmas into aspects, and quite possibly also have to
drop and heavily modify various other aspects. (Effectively, we couldn't require
any program unit aspects other than executable ones, because they wouldn't be
implementable.)

Honestly, you had a better argument when you suggested moving everything in
front of the "is". That's only really ugly for types (subprograms usually don't
have an "is" when they'd also have aspects). But since types are likely to be
common

I think readability and implementability trumps consistency here. The only sane
alternative would be to drop the aspect syntax altogether from units, which
*still* would be inconsistent, and we'd be losing a number of capabilities (most
of the ones I care about, apart from the contracts stuff).

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

From: Randy Brukardt
Sent: Monday, November 15, 2010  8:07 PM

...
> At this stage, I am strongly in favor of maintaining the status quo as
> written up. The suggestions for changing it seem to be opening up a
> can of worms (aka horrible suggestions for changing things).

Yup. The more we look at alternatives, the more it looks like we got it right
the second time (the first time it was more like Brad's suggestion(s), which
doesn't work very well.)

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

From: Robert Dewar
Sent: Monday, November 15, 2010  8:13 PM

> It's not about "getting used to it". It's about adding a whole lot of
> implementation difficulty. "Pragma Pure" is implemented by setting a
> compiler flag or state, and then checking each declaration as it
> appears whether it meets the requirements of that flag/state. That
> cannot be done if the aspect is at the end.

And even if we fiddle in the compiler (e.g. by looking ahead and parsing the
aspects first, which is actually likely to be pretty trivial in most compilers,
probably Randy's compiler is an exception), the point is that the same thing
that makes this awkward for the compiler makes things awkward for a reader.

Basically a reader (or a one pass compiler) wants to know things at the
appropriate point, and you definitely want to know that a package is pure as you
read it.

> If we were to move the aspects to the end, then we'd have to drop the
> idea of converting program-unit pragmas into aspects, and quite
> possibly also have to drop and heavily modify various other aspects.
> (Effectively, we couldn't require any program unit aspects other than
> executable ones, because they wouldn't be implementable.)

Saying they are not implementable is much too strong, what Randy means is "I
would have a hard time implementing them in my compiler", it actually would be
trivial in GNAT, since as is more typical of Ada compilers, it builds a parse
tree, then starts the semantic analysis.

To me the stronger argument is difficulty for the reader, and in that sense,
Randy's one pass compiler is a useful test, if he has trouble, then so will a
reader of the code!

> Honestly, you had a better argument when you suggested moving
> everything in front of the "is". That's only really ugly for types
> (subprograms usually don't have an "is" when they'd also have
> aspects). But since types are likely to be common
>
> I think readability and implementability trumps consistency here. The
> only sane alternative would be to drop the aspect syntax altogether
> from units, which *still* would be inconsistent, and we'd be losing a
> number of capabilities (most of the ones I care about, apart from the
> contracts stuff).

So Randy, are you comfortable signing up for the status quo? Sounds like it, and
that's what Tuck prefers. Really I see only Brad at this stage suggesting any
other action.

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

From: Brad Moore
Sent: Monday, November 15, 2010  10:16 PM

> So Randy, are you comfortable signing up for the status quo? Sounds
> like it, and that's what Tuck prefers. Really I see only Brad at this
> stage suggesting any other action.

I see aspect specifications as an important new feature of the language.
At the end of the day, I'd like to be able to say that we got it right.
Knowing that we've considered all the possibilities will go a long way towards
feeling comfortable with whatever decision we make. (Surely we've covered all
the possibilities ...) It's too bad that there isn't one solution that fits
perfectly, but I can be happy with the status quo.

Arguing now for the status quo, I would say that if people get mixed up and try
to put aspects in the wrong place, then I would think it should be easy enough
for the compiler to give a clear error message hopefully that will tell the
programmer where the aspect needs to be placed. I think people will quickly get
the hang of it....

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

From: Bob Duff
Sent: Monday, November 15, 2010  8:17 PM

> > eg.
> >          package Ada is
> >          end Ada with Pure;
>
> I *very* strongly dislike this, you really want to see the Pure or
> Preelaborate at the start of the package and not at the end of the
> private part. This is why we require the pragmas to be at the start
> after all.

Which is why I'm pretty happy with the pragmas.  Yeah, I get that this
new-fangled aspect thing is wonderful, but I'm nervous about how much trouble
we're willing to go to...

The main advantage of aspect clauses is that you don't have to name the thing.
Saying "Foo is an inlined function." is fundamentally simpler than "Foo is a
function.  Foo is inlined." because in the latter case, the reader has to match
up the two occurrences of "Foo".  (The former is English for the aspect syntax;
the latter for pragma syntax.)

But Pure doesn't have that problem -- you can just say "pragma Pure;" and it
refers to "this package". So I don't see why we want to go to a whole lot of
trouble to make "Pure" into an aspect.

Especially since I got "volunteered" to write up the wording that causes
everything under the sun to be an "aspect".

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

From: Robert Dewar
Sent: Tuesday, November 16, 2010  5:49 AM

> But Pure doesn't have that problem -- you can just say "pragma Pure;"
> and it refers to "this package".
> So I don't see why we want to go to a whole lot of trouble to make
> "Pure" into an aspect.

I like the aspect notation for Pure, and I don't see it as a big deal, Certainly
the implementation is trivial (and for GNAT, already done), and the description
is done, so I am not sure what the "whole lot of trouble" you are talking about
might be.

> Especially since I got "volunteered" to write up the wording that
> causes everything under the sun to be an "aspect".

But that part of it is done :-)

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

From: Bob Duff
Sent: Tuesday, November 16, 2010  6:57 AM

It's not done.  It's on my to-do list.

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

From: Robert Dewar
Sent: Tuesday, November 16, 2010  7:01 AM

But the syntax is done, right, which is the issue here.

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

From: Robert Dewar
Sent: Tuesday, November 16, 2010  5:51 AM

> Arguing now for the status quo, I would say that if people get mixed
> up and try to put aspects in the wrong place, then I would think it
> should be easy enough for the compiler to give a clear error message
> hopefully that will tell the programmer where the aspect needs to be
> placed.

Indeed, not hard to do at all.

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

From: Robert Dewar
Sent: Tuesday, November 16, 2010  7:06 AM

Note that it is the syntax that is important to decide on and get into the RM.

To me it doesn't matter so much whether the ARG decides to allow or disallow
e.g. the Pure aspect, since once the syntax is OK, then implementations can
implement any aspects they want.

Which is why I would still like to see the *syntax* allow aspects on renamings,
even if there are no officially allowed aspects.

After all we allow a pragma Inline to apply to a renaming, so it seems quite
arbitrary to say

pragma Inline can be replaced with an Inline aspect, except for renamings, where
only the pragma is allowed, and the aspect is illegal.

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

From: Robert Dewar
Sent: Tuesday, November 16, 2010  8:45 AM

> But the syntax is done, right, which is the issue here.

Yes, there is a propoosed syntax, although it's still being discussed.  At this
point, I tend to agree with you and Tucker that the current propoosed syntax is
the best we're going to get.

Whether or not Pure is an aspect is still open -- no proposal one way or
'tother.  I don't see much point in it, but maybe it's just for uniformity,
which I can't tell without looking at the whole list of potential aspects.

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

From: Robert Dewar
Sent: Tuesday, November 16, 2010  10:04 AM

>> But the syntax is done, right, which is the issue here.
>
> Yes, there is a propoosed syntax, although it's still being discussed.
> At this point, I tend to agree with you and Tucker that the current
> propoosed syntax is the best we're going to get.

And Brad seems to agree too :-) So let's just decide to stick with this syntax.

> Whether or not Pure is an aspect is still open -- no proposal one way
> or 'tother.  I don't see much point in it, but maybe it's just for
> uniformity, which I can't tell without looking at the whole list of
> potential aspects.

Well as I say, it's not critical what the resolution is.
I am in favor of including this aspect, since I like the idea of not relying on
pragmas for this kind of important semantic stuff.

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

From: Robert Dewar
Sent: Tuesday, November 16, 2010  10:06 AM

> Arguing now for the status quo, I would say that if people get mixed
> up and try to put aspects in the wrong place, then I would think it
> should be easy enough for the compiler to give a clear error message
> hopefully that will tell the programmer where the aspect needs to be
> placed

How about

>      1. pragma Ada_2012;
>      2. package AspectInst is
>      3.    generic package P with     -- OK
>      4.      Pure
>      5.    is
>      6.    end;
>      7.
>      8.    generic package P2 is      -- ERROR
>                               |
>         >>> info: aspect specifications belong here
>
>      9.    end with
>                |
>         >>> misplaced aspects for package declaration
>
>     10.      Pure;
>     11.
>     12.    package PP is new P with   -- OK
>     13.      Pure;
>     14.
>     15.    package PQ with            -- ERROR
>                       |
>         >>> misplaced aspects for package instantiation
>
>     16.      Pure
>     17.    is new P;
>                    |
>         >>> info: aspect specifications belong here
>
>     18. end;

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

From: Randy Brukardt
Sent: Thursday, November 18, 2010  12:40 AM

...
> Note that it is the syntax that is important to decide on and get into
> the RM.

The syntax *is* in the RM already, just look at draft 10 or later. :-)

http://www.ada-auth.org/standards/ada12.html

Of course, everything in the draft RM is subject to change. But I've only put
things into it that I think are pretty stable (don't want to redo work).

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

From: Robert Dewar
Sent: Thursday, November 18, 2010  6:29 AM

...
> The syntax *is* in the RM already, just look at draft 10 or later. :-)

Well, not really, because the only "RM" for Ada is the Ada 2005 standard.
Yes, there is a draft RM, and of course I am perfectly aware of what it
says now (that's why I refer to the status quo :-))

> http://www.ada-auth.org/standards/ada12.html
>
> Of course, everything in the draft RM is subject to change. But I've
> only put things into it that I think are pretty stable (don't want to redo
> work).

Well sure, but the discussion of this particular aspect of aspects is still
quite active, so your judgment of it as "pretty stable" is open to question.

I am simply supporting your view that this should be regarded as a pretty
stable feature, not subject to "redoing work" :-)

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

From: Tucker Taft
Sent: Tuesday, November 16, 2010  8:23 AM

[Editor's note: This was split off of a thread that is in AI05-0235-1.]

> BTW, it seems that we really want formal by-reference parameters to be
> a new object that happens to share memory with the old object. Besides
> this accessibility rule (where claiming that dynamic accessibility is
> a view property is unappealing), we also had similar issues with the
> values of representation aspects like 'Size and 'Alignment. We surely
> don't want to have to pass those along with parameters just so we can
> report them accurately. (I recall we decided that wasn't necessary
> with some phony
> hand-waving.) I wouldn't be surprised if this keeps coming up until we
> finally give in and change the definition...

Perhaps, but there are several cases where things like Alignment, Size,
accessibility level, constantness, vary according to the view. Note that a
dereference of an access value gives a view of the designated object.  If there
are several different (general) access values of different types that designate
the same object, the views they give could vary quite dramatically, but clearly
there is only one object.

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

From: Randy Brukardt
Sent: Tuesday, November 16, 2010  3:43 PM

That seems to make a major muddle out of the entire idea of aspects. Either they
have a well-defined model (that they belong to the entity, not the view), or we
have to create a new model (that I do not understand at all), or they are just
anything that Tucker wants (which is not the way to define a programming
language!).

In the first case, either Tucker is wrong here, or these things are just not
aspects (because they don't meet the model of aspects). Neither of these match
up with the existing language, so we have to reject this.

But that means we have no model of aspects other than type aspects. We
supposedly allow aspects for other than types to vary by view, yet there is
nothing explaining how that works. We don't even know what constitutes different
views. (Arguably, we could apply the ASIS definition of views that makes every
usage name a different view - thus there are no requirements at all on such
aspects). That effectively means that anything depending on aspects of entities
other than types is implementation-defined. Perhaps that is OK for
representation aspects (although I doubt it - it means that all of the ACATS
tests on such aspects should be withdrawn, because they are testing things that
are not requirements).

It also means that all of the justification that I have made to Robert and
others about the design of aspect clauses is bullshit. The truth is that they
ought to be allowed on renames and anything else that creates a view; since they
can be different for views at least in some cases, I don't see any reason to
arbitrarily prevent that.

When I asked this question about parameter passing, I was told that I was wrong
and that no definition is needed. Maybe that is OK for representation aspects
(although I strongly disagree), but it is not acceptable for any other aspect.
Meaning that Bob will have to make sure that *every* aspect as wording
describing how it works for views. That seems like a nightmare to me.

What I would prefer is that the language was very clear that aspects are
per-entity, not per-view, except perhaps in a set of specifically defined cases.
So if you want parameters and dereferences to be able to give the "wrong" answer
for object aspects, there should be explicit text allowing those exceptions.

If we don't have some sort of rule like this, then we have descended completely
into anarchy. And effectively, all aspects are completely
implementation-defined, because there is no requirement ever that they have a
particular value. That's madness.

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

From: Edmond Schonberg
Sent: Tuesday, November 16, 2010  3:53 PM

> What I would prefer is that the language was very clear that aspects
> are per-entity, not per-view, except perhaps in a set of specifically
> defined cases. So if you want parameters and dereferences to be able
> to give the "wrong" answer for object aspects, there should be
> explicit text allowing those exceptions.

I fully agree with Randy. Aspects are per-entity, not per-view. I don't see the
usefulness of "allowing" some aspects to depend on the view. Tuck's example that
the alignment of a designated object might depend on the dereference that
produces it can't possibly hold: how do you generate code for this?

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

From: Bob Duff
Sent: Tuesday, November 16, 2010  4:27 PM

Well, GNAT seems to manage.  ;-)

% cat align.adb
cat align.adb
with Text_IO; use Text_IO;
procedure Align is

   procedure P (X : String) is
   begin
      Put_Line (X'Alignment'Img);
   end P;

   S : String := "Hello, world.";
   for S'Alignment use 2**8;

begin
   Put_Line (S'Alignment'Img);
   P(S);
end Align;
% gnatmake -f align.adb
gnatmake -f align.adb
gcc -c align.adb
gnatbind -x align.ali
gnatlink align.ali
% ./align
./align
 256
 1
%

I didn't look at the generated code, but I'd guess it's just "move 256 into EAX"
and  "move 1 into EAX" (or whatever).

Note that it's implementation defined whether or not X is a view of S!

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

From: Tucker Taft
Sent: Tuesday, November 16, 2010  4:27 PM

Here is an example:

      X : aliased Integer
        with Alignment => 1024;

      type Int_Ptr is access all Integer;
      Y : Int_Ptr := X'Access;

      pragma Assert(Y.all'Alignment = Integer'Alignment);
      pragma Assert(Y.all'Alignment /= X'Alignment);

I don't see this as a big deal.

The original discussion was about accessibility level, in any case.

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

From: Edmond Schonberg
Sent: Tuesday, November 16, 2010  5:01 PM

> Well, GNAT seems to manage.  ;-)

Not sure what this proves. Tuck's example involved two different access types
with the same designated type. Here there is just an alignment clause, not two
different contradictory aspects.  This is the quote that worries Randy and me:

Perhaps, but there are several cases where things like Alignment, Size,
accessibility level, constantness, vary according to the view. Note that a
dereference of an access value gives a view of the designated object.  If there
are several different (general) access values of different types that designate
the same object, the views they give could vary quite dramatically, but clearly
there is only one object.

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

From: Randy Brukardt
Sent: Tuesday, November 16, 2010  5:13 PM

...
> Perhaps, but there are several cases where things like Alignment,
> Size, accessibility level, constantness, vary according to the view.
> Note that a dereference of an access value gives a view of the
> designated object.  If there are several different
> (general) access values of different types that designate the same
> object, the views they give could vary quite dramatically, but clearly
> there is only one object.

Note that in this list, "constantness" is definitely not an aspect. We were
originally discussing whether "accessibility level" works like an aspect, but
there is no reason to assume it is one (which was my mistake). So neither of
those really bear on the discussion.

Size and Alignment surely are aspects. And we've discussed this before (in terms
of parameters); we don't want to require the aspects to be required to be the
same, because otherwise it would be necessary to pass them with all parameters
just in case someone queried them. That would be silly.

The problem is that the answer wasn't to explain when the aspects can depend on
the view, but rather to say that they *always* depend on the view and then never
say anything more. That means that you can *never* depend on an aspect other
than a type aspect. That way lies madness. I should never have taken the "don't
care" answer in the first place, but I could see that there would never be a
strong definition for the case of representation aspects of objects. But now we
have a much more general mechanism; we cannot leave it to individual
implementers to do something useful - else we might as well not bother at all
standardizing any of this beyond the syntax. (I get the feeling that Robert is
in this camp.)

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

From: Bob Duff
Sent: Tuesday, November 16, 2010  5:20 PM

> Not sure what this proves.

It proves that, as Tuck said, "things...vary according to the view".
Whether that means the sky is falling, as Randy and Chicken Little might like to
imply, I'm not so sure.  ;-)

>...This is the quote that worries Randy and me:

Can you explain what the worry is?  Is it a worry about RM wording, or something
more substantial?  I mean, X.all and Y.all can be the same object, yet the
accessibility level depends on their (possibly different) access types. Should I
worry about that?

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

From: Edmond Schonberg
Sent: Tuesday, November 16, 2010  5:26 PM

> The problem is that the answer wasn't to explain when the aspects can
> depend on the view, but rather to say that they *always* depend on the
> view and then never say anything more. That means that you can *never*
> depend on an aspect other than a type aspect.

Hopefully pre, post, and package aspects are equally trustworthy!  we are just
speaking about aspects of objects.

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

From: Randy Brukardt
Sent: Tuesday, November 16, 2010  5:50 PM

...
> > The problem is that the answer wasn't to explain when the aspects
> > can depend on the view, but rather to say that they *always* depend
> > on the view and then never say anything more. That means that you
> > can *never* depend on an aspect other than a type aspect.
>
> Hopefully pre, post, and package aspects are equally trustworthy!  we
> are just speaking about aspects of objects.

I would hope that they are trustworthy, but the current definition of aspects
only has a special case defining that they are not view-dependent for types.
(13.1(11/2)). There is no such rule for subprograms, objects, packages, or any
other entities. That is what I'm concerned about.

Bob Duff says:

> It proves that, as Tuck said, "things...vary according to the view".
> Whether that means the sky is falling, as Randy and Chicken Little
> might like to imply, I'm not so sure.  ;-)

Being compared to Chicken Little, even with a smiley, is really nasty.

My concern is simply that in the absense of some idea what an aspect is,
particularly when views are involved, means that everything we've done so far is
done without any clear idea of what we're doing. Everything I've done related to
aspects has assumed that they are not view specific; if that premise is false,
we need to revisit virtually every decision that has been made, because most of
them depend heavily on that premise. (The obvious example is omitting
aspect_clauses from renames.)

Moreover, without a blanket rule defining how aspects work, every individual
aspect has to provide that information. That means that aspects like Pre and
Post need at least a sentence saying "This aspect is the same for every view of
the associated subprogram." And aspects that are not like that need to explain
what the rules are when views are involved. Otherwise, it is completely
impossible to write an ACATS test or any other portable code using an aspect.

The examples that both you and Tucker have shown that 'Alignment can be anything
for an object, even when the value is specified for the object. There is no
justification for the existing ACATS tests on object 'Alignment in that
environment. As I've said, perhaps that is OK for representation aspects of
objects (which are rather implementation-defined in any case), but that is
simply not acceptable for something like Pre.

If you think this is the "sky falling" as opposed to a real concern, then fine,
but then we really have nothing to talk about. And I better brush up my Java
skills, because I won't be doing Ada anymore.

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

From: Bob Duff
Sent: Tuesday, November 16, 2010  6:35 PM

> Being compared to Chicken Little, even with a smiley, is really nasty.

I apologize!  I really didn't mean it as a nasty insult -- just poking a little
fun at you for what seemed to me like slightly over-the-top rhetoric (hence the
smiley!).

I am sorry.

I do think you have a real, legitimate concern about the wording, and we can
address it.

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

From: Tucker Taft
Sent: Tuesday, November 16, 2010  10:19 PM

I suspect Bob and I don't really understand
the issue.   Things like Size and Alignment
have been part of Ada for a long time.
Adding aspect specifications doesn't change much of anything about them, except
for the syntax used to specify them.

Objects are probably the only really special case, since they are clearly
run-time entities, and we have many ways of referring to the same object.  If
you specify an aspect of an object, then at places where that aspect
specification is visible and you are referring to the object via its declared
name (as opposed to by some other name like a formal by-ref parameter or an
access-value dereference), then an attribute reference corresponding to that
aspect will presumably report the specified value.

On the other hand, when referring to an object via a formal by-ref parameter, or
via an access value dereference, then the attribute reference can end up
returning a different value.  It is presumably "conservative" for some
appropriate definition of "conservative."  That is, if you ask for the alignment
of a formal parameter, it might in fact be more aligned.  If you ask for the
size, it might in fact have some extra padding at the end that nobody ever looks
at.  If you ask for the accessibility, it might in fact be longer-lived than it
appears via the formal parameter.

None of this is new with aspect specifications, so I am a bit surprised that
there is any controversy and that this is a hot topic for discussion.  It would
probably help Bob and me if there were an example of an actual problem created
by these long-standing characteristics of object representational aspects, or
what makes this a bigger problem now that we have generalized aspect
specifications.

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

From: Randy Brukardt
Sent: Wednesday, November 17, 2010  9:24 PM

I've covered this several times already (especially in my last message to Bob),
but one more time:

(1) You might have the above model in your head, but there is nothing in the
    Standard that codifies any of it. The standard really only defines aspects
    as entity-specific vs. view-specific for types. For all other kinds of
    entities, there is nothing much said about entity vs. view.

(2) If we're going to generalize aspects as much as we are going to, we need to
    define these things carefully. For instance, your statement that "objects
    probably are the only special case" is not true vis-a-vis the standard
    wording. If we (for instance) want preconditions to be entity-specific
    rather than view specific, then we need wording to that effect somewhere.

(3) Without some definition for other kinds of aspects (other than types), it is
    impossible to write any portable code (or any ACATS tests). That's because
    there is no definition for which views the specified value of an aspect has
    to be returned. The model you give above would be fine, but there is no
    normative justification for it in the Standard.

(4) If indeed objects are the only special case, then the best way to do this is
    simply by saying so: "Unless otherwise specified, aspects are the same for
    all views of an entity." And then following that by an appropriate exception
    for objects: "For representation aspects of objects, views of an object for
    which the specification of an aspect are visible have the aspect as
    specified; other views may have an implementation-defined value of the
    aspect." Or something like that.

(5) I don't view representation aspects of objects to be that big of a deal, as
    their values are implementation-defined anyway. Only ACATS tests really care
    about using them portably. But other kinds of aspects and aspects for other
    kinds of entities need to be dealt with. We surely do not want whether a
    package is Pure to depend on the view of the package, for example.

(6) But note that I opened an AI (AI05-0083-1) specifically to address this
    question definitively for representation aspects of objects. I wanted the
    question answered then, but I only got a "ramification" that contains little
    real guidance (just some vaguely worded AARM notes). So I do not view this
    as a "new" issue, but rather one that has been festering for a long time. I
    only went along with the Ramification because of the implementation-defined
    nature of representation aspects means that not that much useful can be
    assumed about them anyway. But I still would much prefer real wording to
    explain when it is and is not allowed for the aspects to differ from those
    specified for an entity.

(7) Finally, pretty much all of the decisions that we have made about syntax,
    rules, etc. about aspect_clauses have been made assuming that aspects are
    entity-specific rather than view-specific (surely in my case, and judging
    for Ed's reaction, I'm not the only one). Since that is wrong, I am no
    longer certain that we have gotten the right answers in all cases (the
    obvious example being whether to support the clauses on renames). I think it
    is important the we revisit all of the decisions with a new model in mind
    (even if that model is that aspects only differ for objects, we still need
    to think carefully about renames of objects). It's quite possible that not
    much needs to be changed, but I no longer have any confidence in my previous
    thinking on the topic.

I hope this clarifies my position here. Perhaps I put my initial fears too
strongly, but I cannot abide with leaving this all undefined, or assuming that
the answers determined using an incorrect model of aspects are correct.

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

From: Randy Brukardt
Sent: Tuesday, February  1, 2010  5:03 PM

John has been complaining privately about the use of aspects in the Queue
containers. This has led us (John and I, at least) to wonder about whether the
syntax for aspects is ideal. But this is something that the entire group ought
to consider.

Here is an excerpt of our conversation.

The declaration in question:

   protected type Queue
      (Ceiling: System.Any_Priority := Default_Ceiling)
         with Priority => Ceiling is
      new Queue_Interfaces.Queue with

[This is formatted as suggested by the RM layout (that is, by Tucker's original
intention) and not some of the later layouts that we've seen.]

John writes (in part):

> My other concern which I have voiced before is that we are using "with"
> rather a lot. Mostly it deosn't matter but here we have several
> different uses close by
>
> with for the aspect
> with for the declaration list giving the entries etc
>
> and then glancing up the page we have
>
> with function
> with package
>
> and good old fashioned
>
> with System
>
> I can cope with these exisiting ones because they are disjoint. But
> the "with" aspect occuring together with the "with" introducing the
> entries for me is a with too far (maybe I should say a with too
> close).
>
> For me the confusion goes away if we use pragmas in contexts such as
> this.

Randy:

That fixes nothing. We're not defining any new pragmas for these sorts of
things, so sooner or later you'll have to use an aspect in these contexts. If
there is something wrong with the aspect syntax, we need to make it right, and
right away while we still can.

I wonder if the problem is overuse of the keyword "with". That has been
bothering me for a while; it is especially bad for extensions where "with" for
the extension and "with" for the aspects are in close proximity.

I wonder if we should consider a different keyword. "use" comes to mind,
especially as that is what is used in the existing attribute clauses. How does
this look:

   protected type Queue
        (Capacity : Count_Type := Default_Capacity;
         Ceiling: System.Any_Priority := Default_Ceiling)
           use Priority => Ceiling is
        new Queue_Interfaces.Queue with

I'll note that the keyword really ought to be "using", and the layout is
backwards:

           using Ceiling for Priority is

but that seems too radical, having a new keyword (and difficult to parse, given
that the aspect name goes last in this syntax).

Equally radical would be to actually have a keyword "aspects":

           aspects Priority => Ceiling is

or

           with aspects Priority => Ceiling is [although this latter seems to be reintroducing the with problem.]

or

           using aspects Priority => Ceiling is [nah, too wordy.]

"properties" is another possible keyword:

   protected type Queue
        (Capacity : Count_Type := Default_Capacity;
         Ceiling: System.Any_Priority := Default_Ceiling)
           properties Priority => Ceiling is
        new Queue_Interfaces.Queue with

Any other ideas? Whatever is chosen has to work for subprograms as well.

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

From: Robert Dewar
Sent: Tuesday, February  1, 2010  9:39 PM

>     protected type Queue
>        (Ceiling: System.Any_Priority := Default_Ceiling)
>           with Priority =>  Ceiling is
>        new Queue_Interfaces.Queue with

>     protected type Queue
>          (Capacity : Count_Type := Default_Capacity;
>           Ceiling: System.Any_Priority := Default_Ceiling)
>             properties Priority =>  Ceiling is
>          new Queue_Interfaces.Queue with
>
> Any other ideas? Whatever is chosen has to work for subprograms as well.

I like the use of WITH, but I think it is much better with a different
layout:

>>     protected type Queue
>>        (Ceiling: System.Any_Priority := Default_Ceiling) with
>>           Priority =>  Ceiling is
>>        new Queue_Interfaces.Queue with

I don't like the with at the start of the line.

Also this is somewhat of a worst case, and I don't think it is helpful to argue
from worst cases.

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

From: Tucker Taft
Sent: Wednesday, February  2, 2010  8:55 AM

> ... I like the use of WITH, but I think it is much better with a
> different
> layout:
>
>>> protected type Queue
>>> (Ceiling: System.Any_Priority := Default_Ceiling) with Priority =>
>>> Ceiling is new Queue_Interfaces.Queue with
>
> I don't like the with at the start of the line.

Well I am just the opposite.  I find the "dangling" with very confusing, as it
is just where I often the see the "with" used for type extension.  I much
prefer:

    protected type Queue
       (...)
          with Priority => Ceiling,
               Cool => Beans is
       new Queue_Interfaces.Queue with
         ...
    end Queue;

> Also this is somewhat of a worst case, and I don't think it is helpful
> to argue from worst cases.

I suppose, but this is a "normal" case for any task or protected type extension.
There isn't anything especially bad about Queue.

Note that record and private type extension also will end up with two "with"s if
they have aspects.

I happen to like "with" (as must be apparent), but I could live with(?) other
keywords if they sounded reasonable. If we look at the simpler cases, such as:

     procedure P(...)
        with Pre => X < Y;

the problem with "use" is that it is legal following a procedure declaration,
meaning that if you leave out the ";" by mistake, you could end up with
something like this:

     procedure P(...)  -- forgot the ";"
     use Pre;
     ...

vs.
     procedure P(...)
       use Pre => X < Y;

It also doesn't read quite as well.

Other possibilities:

     procedure P(...)
        and Pre => X < Y,
            Post => P'Result > Y;

     procedure P(...)
        while Pre => X < Y,
              Post => P'Result > Y;

     procedure P(...)
        when Pre => X < Y,
             Post => P'Result > Y;

     procedure P(...)
        for Pre => X < Y,
            Post => P'Result > Y;

Of the above, I suppose "and" and "for" aren't too hideous, but "with" still
seems more natural.  And of course "and" is already used in type extension, and
"for" is legal just like "use" in a declare part, so a missing ";" will produce
the same confusion.

If I had to choose, "with" and "and" would be my two choices, in that order.

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

From: Robert Dewar
Sent: Wednesday, February  2, 2010  9:12 AM

A very minor issue here is that the new release of GNAT fully supports aspects
using the WITH syntax, that means we will in practice likely continue to support
it if it is changed (under the language extension flag).

I don't think that should be decisive, but it does mean that we need a strong
case and a strong consensus to make the change.

I must say, never mind this issue, that I don't like USE as a replacement,
because USE does appear in declarations freely right now.

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

From: Dan Eilers
Sent: Wednesday, February  2, 2010  10:23 AM

> Other possibilities:
>  ...
>
>      procedure P(...)
>         for Pre => X < Y,
>             Post => P'Result > Y;

I don't know if this possibility has been considered:

       procedure P(...)
          for Pre use X < Y,
          for Post use P'Result > Y;

It would be the closest to the existing attribute definition syntax.

I agree with John that the "with" syntax for aspects, is unnecessarily confusing
with the "with" for type extension.  And it seems unnecessarily different from
attribute definition clauses.

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

From: Jean-Pierre Rosen
Sent: Wednesday, February  2, 2010  12:36 PM

>> Other possibilities:
>>  ...
>>
>>      procedure P(...)
>>         for Pre => X < Y,
>>             Post => P'Result > Y;
>
> I don't know if this possibility has been considered:
>
>        procedure P(...)
>           for Pre use X < Y,
>           for Post use P'Result > Y;
>
> It would be the closest to the existing attribute definition syntax.
>
Hmm... since this is mostly aesthetical, I'd like some kind of separator before the specification of aspects.

"with" is not bad, although I share the concern it might be confusing.
But I can live with it.
"and" reads natural, but is not in its normal usage. Oh well, you have it for
interface inheritance too. So we would have: type D and <aspects> is new T and
I1; not much better...

"select" could be used...

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

From: Randy Brukardt
Sent: Wednesday, February  2, 2010  7:28 PM

> I don't know if this possibility has been considered:
>
>        procedure P(...)
>           for Pre use X < Y,
>           for Post use P'Result > Y;
>
> It would be the closest to the existing attribute definition syntax.

This doesn't seem to address Robert's concern about similarity to existing constructs in lists of declarations.

He thinks "use" isn't acceptable (by itself) because use clauses might appear; there isn't much difference between:

    procedure P (A : Natural)
       use Pre => A > 10;

and

    procedure P (A : Natural);
    use Pack;

The difference here to the reader is really just a semicolon (until the => is
encountered, but that's pretty late).

A similar problem would occur with your proposal:

        procedure P(A : Natural)
           for Pre use A > 10;

and

        procedure P (A : Natural);
        for P'Address use Foo;

Here the difference is a semicolon and an attribute reference. A bit better, but
not much.

I'd also think that there would be confusion as to the proper syntax. I'd expect
people to often write:

    Obj : Small_Int
        for Obj'Size use 8;

by accident. There is some value to it being different.

> I agree with John that the "with" syntax for aspects, is unnecessarily
> confusing with the "with" for type extension.
> And it seems unnecessarily different from attribute definition
> clauses.

I'm fairly convinced that if we do change this, we need to do so by using a
totally new keyword. Most of the existing ones have been used enough.

Well, we could use "some" for this, it's wildly underused:

           procedure P(A : Natural)
              some Pre => A > 10;

(OK, I'm kidding.) "accept", "do", and "select" are all in this category, too,
but none make much sense.

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

From: Jean-Pierre Rosen
Sent: Thursday, February  3, 2010  3:25 AM

> (OK, I'm kidding.) "accept", "do", and "select" are all in this
> category, too, but none make much sense.

and don't forget "until". Doesn't make sense either.

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

From: Tucker Taft
Sent: Sunday, February 13, 2010  4:35 PM

Here is a relatively minor update to AI-183 on aspect specifications.  We now
allow "identifiers specific to an aspect" in an aspect specification (how's that
for a mouthful?), with the intent of allowing being able to specify a Convention
with an aspect specification. We also allow aspect specifications on renaming
declarations, but indicate there are no language-defined aspects that can be
specified on a renaming.

We also specify that if a boolean aspect is inherited by a derived type as True,
it can't be overridden with a specification of False.

[This is version /08 of the AI. - Editor]

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

From: Jean-Pierre Rosen
Sent: Monday, February 14, 2010  2:19 AM

> We also allow aspect specifications on renaming declarations, but
> indicate there are no language-defined aspects that can be specified
> on a renaming.

but the !proposal section still says:

Aspect specification are not permitted on renaming declarations, as that would
seem to break the underlying model of renaming (that properties are the same as
the renamed entity).

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

From: Tucker Taft
Sent: Monday, February 14, 2010  8:51 AM

Oops, sorry about that.  Once I get embroiled in wording, I always forget to go
back and read the summary/proposal!

[Corrected in version /08.]

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

From: Randy Brukardt
Sent: Monday, February 14, 2010  10:37 PM

The following paragraph is under Legality Rules:

The aspect_definition associated with a given aspect_mark may be omitted only
when the aspect_mark identifies an aspect of a boolean type, in which case it is
equivalent to the aspect_definition being specified as True.

but this doesn't seem to have much to do with Legality; it seems more like
Static Semantics to me. (I ask because I was looking for this rule when working
on AI05-0229-1 on Friday, and failed to find it then -- never thought to look in
Legality Rules.)

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

From: Tucker Taft
Sent: Monday, February 14, 2010  11:03 PM

Agreed, that does seem more like a Static Semantics rule.

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

From: Bob Duff
Sent: Tuesday, March 15, 2011  7:15 PM

Minor comment on AI05-0183-1, Aspect Specifications:

Since implementation-defined aspects are allowed, this AI should allow arbitrary
aspect_definitions for impl-def aspects.

This comes from a discussion within AdaCore, where we want an aspect to be a
subtype_indication, for ex:

    with Impl_Def_Aspect => String (1..N)

We could invent pragmas and new syntax and -allow-extensions command-line
switches for this, but it seems cleaner to let this be under the new aspect
idea.

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

From: Robert Dewar
Sent: Tuesday, March 15, 2011  7:34 PM

I definitely agree, I see no point in putting constraints on implementation
defined things

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

From: Tucker Taft
Sent: Tuesday, March 15, 2011  7:58 PM

It depends whether you want these things to be "ignorable"
as implementation-defined pragmas are.  If so, then willy-nilly syntax is a pain
for other compilers to ignore.

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

From: Bob Duff
Sent: Tuesday, March 15, 2011  8:19 PM

Yeah, that's true, I understand that point of view, but I really don't think
there's a lot of value in ignorable pragmas, nor aspects.  Some value, but not a
lot.

In fact, the particular aspect we were discussing in AdaCore is purely for
optimization, so it could be safely ignored by other compilers.  For that
purpose, how about we add subtype_indication to the aspect syntax?

But in general, implementors are going to add whatever non-standard features
their customers want, so ARG might as well allow such things in the cleanest
way.  I'm hugely in favor of portability, but once one chooses to be
nonportable, one has crossed a line. Pragma Restrictions(No_Impl_Aspects) is our
friend, here.

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

From: Tucker Taft
Sent: Tuesday, March 15, 2011  8:34 PM

I pretty regularly compile code from other compilers, and I definitely
appreciate the ability to ignore pragmas, so I see definite value in it.  Adding
a subtype indication seems reasonable, though I haven't really thought about the
parsing implications.

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

From: Robert Dewar
Sent: Wednesday, March 16, 2011  7:10 AM

> Yeah, that's true, I understand that point of view, but I really don't
> think there's a lot of value in ignorable pragmas, nor aspects.  Some
> value, but not a lot.

And we have not agreed to make unrecognizable aspects officially ignorable. In
practice real life compilers will easily be able to handle this situation anyway
(ignoring an aspect you do not understand by scanning to a comma or semicolon is
perfectly reasonable).

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

From: Robert Dewar
Sent: Wednesday, March 16, 2011  7:36 AM

> I pretty regularly compile code from other compilers, and I definitely
> appreciate the ability to ignore pragmas, so I see definite value in
> it.  Adding a subtype indication seems reasonable, though I haven't
> really thought about the parsing implications.

Well let's consider whether unrecognized aspects are supposed to be ignored, or
like unrecognized rep clauses must be illegal.

In GNAT we have a switch to ignore all rep clauses, and we find this very useful
in some situations, I suppose we have to consider which aspects this should
ignore (some aspects are not ignorable, like categorization stuff, so we need a
list anyway).

As I said earlier, in real life in a compiler, ignoring my skipping to the next
comma or semicolon works just fine.

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

From: Randy Brukardt
Sent: Wednesday, March 16, 2011  5:16 PM

> Yeah, that's true, I understand that point of view, but I really don't
> think there's a lot of value in ignorable pragmas, nor aspects.  Some
> value, but not a lot.

So far as I can tell, we haven't made any attempt to allow aspects to be
ignorable. (At least I can't find any in AI05-0183-1.) So I don't think this is
relevant.

> In fact, the particular aspect we were discussing in AdaCore is purely
> for optimization, so it could be safely ignored by other compilers.
> For that purpose, how about we add subtype_indication to the aspect
> syntax?

I know that would make the our grammar severely ambiguous, and our parser
generator would surely choke. Subtype indications are not expressions in
Janus/Ada, and have no associated nodes, so even getting rid of the ambiguity
somehow would not be much help.

I'd be more sympathetic to allowing anything, because that would turn it into an
error handling problem (presuming we're not ignoring anything). Certain
implementation-defined aspects might cause bizarre syntax errors rather than any
understandable error message, but they'd meet the letter of the standard (by
being rejected). If they became common enough in ported code, we'd have to
figure out a way to make the error messages better.

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

From: Randy Brukardt
Sent: Wednesday, March 16, 2011  6:32 PM

> And we have not agreed to make unrecognizable aspects officially
> ignorable. In practice real life compilers will easily be able to
> handle this situation anyway (ignoring an aspect you do not understand
> by scanning to a comma or semicolon is perfectly reasonable).

By "real-life compilers" I presume you mean GNAT, because it is not at all
obvious to me that "scanning to a comma" is a practical implementation for a
table-driven parser. The issue being of course that the parser state after such
scanning is not going to be the same as the state before such scanning (since
you are skipping over several non-terminals/reductions as well); I can imagine
some sort of hack to deal with that, but it seems likely to be fragile.

For Janus/Ada, where the first compiler pass is an almost pure parser with
almost no semantic information, this situation is worse because we'd have no
obvious way to determine what is and is not a valid aspect. At best, putting
some sort of list into the front-end would duplicate information (which would
*always* be out of sync, if our experience with pragmas/attributes is any
guide). That's unpleasant. The parser also does not use feedback to the scanner
because it would be too fragile (parser state numbers change every time the
parser generator is rerun; only reduction numbers are stable and reductions are
the wrong time to be changing the scanner behavior); the scanner is essentially
self-contained. Changing that also is unpleasant.

Anyway, my primary point is just because it might be easy to do something in a
particular technology does not mean that it is easy to do in any technology.

Aside: The reason that Janus/Ada uses a pure parser pass is completely
historical. On the Z80 CP/M systems where we started out, the machines had a
maximum of 60K (more typically 56K) of memory. Our original parser where ported
from our UW compiler construction project took some 40K of memory, leaving
nothing for the actual compiler. (The parameters of that parser were determined
by the class.) We experimented with various changes: dumping the original
table-driven scanner and compressing the parse tables saved more than half of
the space. We also created an experimental recursive descent parser, but it
turned out to be much larger than the parse tables on the Z80 machine -- so we
stuck with the parse tables. But the parser and tables still took about 20K of
memory, or more than a third of the total available memory. By splitting the
parser into a separate pass, we managed to eliminate 12K or so of memory usage,
which of course allowed more code for implementing semantic features.

When the compiler was posted to MS-DOS, we considered eliminating the separate
pass. But the second pass was still the one that was always bumping into limits
and running out of memory, so we keep the bifurcation.

By the time that we moved to 32-bit machines, we'd taken advantage of the extra
compiler pass to eliminate a handful of otherwise messy situations, such as the
need to declare labels long before they are seen in the source. So eliminating
the extra pass isn't practical anymore.

Aside-Aside: It is interesting that Ada 83 pragmas had a similar "anything goes"
syntax rule to the one suggested here. Early versions of Janus/Ada handled this
by completely handling pragmas within the scanner. Not only did the scanner
parse the pragmas, but it also handled all of the interpretation. If the later
compiler passed needed to know about a pragma, it was handled by passing them a
special token in the parse stream. This only worked because all of the pragmas
we supported were context-free (and used pragma-specific identifiers).

Ada 95 blew that scheme up by declaring pragmas that needed semantic context
(definitely not available in the scanner!). But it also defined the allowed
syntax, so we gave pragmas a first-class syntax and let the later compiler
passes do the processing in the normal way. Mixing the two schemes doesn't
really work for pragmas, and I doubt it would work that well for aspects,
either, should we want to make them ignorable.

****************************************************************                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                    implementing semantic features.

From: Tucker Taft
Sent: Wednesday, March 16, 2011  10:04 PM

Here is an update to aspect specifications, which now allows for operational
aspects to be inherited, though only if specified.  It also allows for
operational aspects to be on things other than types.  It also states that an
operational aspect that applies to a partial view also applies to the full view.

[This is version /09 of the AI - Editor.]

****************************************************************                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                    implementing semantic features.

From: Randy Brukardt
Sent: Thursday, March 17, 2011  11:32 AM

I was think about the issue with giving the value of Priority for a main
subprogram this morning, and a modest suggestion has come out of it.

To remind everyone, the problem is that we don't allow aspect_specifications
on subprogram bodies. Therefore, you have to give a separate specification
in order use the aspect form to specify Priority; this led to leaving the
pragma in the core rather than making it obsolescent.

It strikes me that this problem occurs for pretty much any aspect that can
be specified on a subprogram, not just the real-time ones. That includes Inline,
No_Return, Pre, and Post. Specifying any of these requires giving a separate
specification.

In the case of subprogram library units (including main subprograms), it is
unusual to give a separate specification.

I am thinking that we ought to allow aspect_specifications to be given on
bodies, so long as there is no specification. Formally, this would look like:

Replace 6.3(2/2) by:

subprogram_body ::=
    [overriding_indicator]
    subprogram_specification
       [aspect_specification] is
       declarative_part
    begin
        handled_sequence_of_statements
    end [designator];

Add to the end of 6.3(4) [Legality Rules]:

If a subprogram_body is a completion, no aspect_specification shall be given.


The legality rule ensures that each subprogram has precisely one
aspect_specification, so we don't have to define conformance for
aspect_specifications.

Then, a main subprogram can look like:

    procedure Do_It
        with Priority => 8,
             CPU      => 1,
             Post     => Goodness = True is
    begin

        Get_Sweetness_and_Light;
    end Do_It;

Thoughts??

****************************************************************                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                    implementing semantic features.

From: Tucker Taft
Sent: Thursday, March 17, 2011  11:45 AM

Makes sense to me.

****************************************************************                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                    implementing semantic features.

From: Randy Brukardt
Sent: Thursday, March 24, 2011  12:56 AM

In the latest version of AI05-0183-1, Tucker changed 13.1(11/2):

  Operational and representation aspects of a generic formal parameter
  are the same as those of the actual. [Operational and
  r]{R}epresentation aspects are the same for all views of a type. {If
  an operational aspect is specified for a partial view of a type, then
  it applies to the full view as well.} A type-related representation
  item is not allowed for a descendant of a generic formal untagged
  type.

This wording seems to leave the value of operational aspects defined on
full views undefined for the partial view. That would cause issues for
stream attributes of a non-limited partial view where the attribute is
specified for the full view:

   package Fooey is
      type Priv is private;
   private
      type Priv is ...
         with Read => My_Read;
      procedure Read (A : not null access Streams.Root_Stream_Type;
                      B : out Priv);
   end Fooey;

   with Fooey;
   procedure Main is
      P : Fooey.Priv;
   begin
      Fooey.Priv'Read (Some_Stream, P); -- ???
   end Main;

The original wording made it clear that the Read aspect has the same value
for all views of the type. Thus, the attribute clearly calls the body of Read,
even though that attribute definition is not visible.

However, with the new wording, the value of the Read aspect is unspecified for
the partial view. You might think that it has the default value of the aspect
-- indeed, I can't find any reason to think anything else, other than that it is
completely undefined - there is no mention of partial views when defining stream
attributes 13.13.2 - in large part because 13.1(11/2) said that it isn't necessary.
The only thing that doesn't make sense is to assume it is the specified aspect --
since the wording does not say anything about the partial view when the full view
is defined. This seems especially likely because the wording is different than
the representation aspect case; one has to presume that is on purpose.

I'm not sure why Tucker made this change, but I think it is a mistake to abandon
the principle that a type-related aspect is the same for all views (and it definitely
is a mistake in this case!). [I can't think of any reason that this would cause any
problems with Type_Invariants -- they surely need to be the same for all views; you
might not be able to *see* it, but I hope it still gets checked.] If there is a
problem with visibility, it ought to be checked with Legality Rules, not some hack
about the values.

We either need to completely revert the change, or make it clear that type-related
aspects have the same value for all views (letting the new wording only apply for
other kinds of aspects, should they ever exist), or Tucker has to be a lot clearer
about what he is trying to accomplish.

****************************************************************                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                    implementing semantic features.

From: Randy Brukardt
Sent: Thursday, March 24, 2011  1:33 AM

It also conflicts with the wording already in AI05-0183-1 which defines aspects:

  Other aspect_specifications are associated with the entity, and apply
  to all views of the entity, unless otherwise specified in this
  International Standard.

Unless the intent is to change this for all type-related operational aspects --
which is going too far IMHO.

****************************************************************                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                    implementing semantic features.

From: Tucker Taft
Sent: Thursday, March 24, 2011  8:15 AM

I'm not sure what we mean by the "value" of an aspect like this.
These are dispatching routines, so there are really two things.
One is the relevant declaration, and the other is the body actually invoked.
For a non-limited type, there is the implicit declaration of the visible 'Read
operation, and then possibly an overriding of the associated body in the private
part.  For a limited type, there is generally no implicit declaration (unless it
is defined on the parent type), and so the partial view really doesn't have the
aspect at all.

Clearly the body you end up calling is a run-time thing, and run-time things are
always based on the full view of a type.  But the relevant declaration is what
we worry about at compile-time, and in that case, they can be quite different
between the full view and the partial view for operational aspects.

On the other hand, for representational aspects, if you ask for the 'Size of the
partial view, you will always get the same value as you get for the full view.
So for representational aspects, it seems that the full view and the partial
view are more in alignment.

We could revert the wording to the prior definition, but I think we need to
acknowledge that sometimes the partial view doesn't have the aspect at all.
Perhaps we could say that if the aspect is defined for the partial view, it has
the same run-time effect as that of the full view.  But it might not have the
aspect at all, from a *static* semantics point of view.  I think it should go
without saying that from a *dynamic* semantics point of view, all that matters
is the full type.

****************************************************************                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                    implementing semantic features.

From: Randy Brukardt
Sent: Thursday, March 24, 2011  7:43 PM

> I'm not sure what we mean by the "value" of an aspect like this.

Ah-ha, the crux of the problem.

> These are dispatching routines, so there are really two things.
> One is the relevant declaration, and the other is the body actually
> invoked.  For a non-limited type, there is the implicit declaration of
> the visible 'Read operation, and then possibly an overriding of the
> associated body in the private part.  For a limited type, there is
> generally no implicit declaration (unless it is defined on the parent
> type), and so the partial view really doesn't have the aspect at all.
>
> Clearly the body you end up calling is a run-time thing, and run-time
> things are always based on the full view of a type.
> But the relevant declaration is what we worry about at compile-time,
> and in that case, they can be quite different between the full view
> and the partial view for operational aspects.

No, this is not the view of operational aspects that I have, no wonder you (or
I) are confused. We do not care "where these are declared", because they are
language-defined and always exist.

My understanding of the model of (existing Ada 2005) aspects is that the aspects
always exist for every relevant entity. Every object has a Size aspect
(attribute), whether or not it is specified. Similarly, every type has a Read
aspect (attribute), whether or not it is specified. Since these things are
attributes, the language defines their profile; the specified subprogram is
irrelevant when it comes to calling one of them. For instance, you cannot use
named notation in calling one of these (the parameters have no names), not
matter what the actual is.

In order to deal with the possibility that there is no useful value in some
cases, we have the concept of availability. If the stream attribute is not
available, then a call is illegal.

That means that the "value" of an aspect is its runtime value. And it always
exists. If you want to prevent accessing it in some cases, you need separate
legality rules to do so. (And I think only stream attributes have such rules.)
In some cases, the "value" is view-specific, and in other cases it is
entity-specific -- but in all cases there is a value.


I have always expected that this model carried over to the new aspects. That was
the point of the big blow up about "view-specific" vs. "entity-specific"
aspects. It's also why we've tried to define default values for aspects (like
"Optional" for Is_Synchronized), so we don't have to worry about the cases where
they are not specified at all. Generally, we've worked hard to avoid having
things depend on whether or not something is specified, so that the default
implementation-defined value works the same as a specified value.

We do have cases where there is just no possible value to talk about
(Default_Value comes to mind), and this is clearly new. But even that can be
modeled properly: such an aspect is <empty> when it is not specified (which is
different than unspecified!), and has a defined value in other cases.

> On the other hand, for representational aspects, if you ask for the
> 'Size of the partial view, you will always get the same value as you
> get for the full view.  So for representational aspects, it seems that
> the full view and the partial view are more in alignment.
>
> We could revert the wording to the prior definition, but I think we
> need to acknowledge that sometimes the partial view doesn't have the
> aspect at all.  Perhaps we could say that if the aspect is defined for
> the partial view, it has the same run-time effect as that of the full
> view.  But it might not have the aspect at all, from a *static*
> semantics point of view.  I think it should go without saying that
> from a
> *dynamic* semantics point of view, all that matters is the full type.

I don't believe there is any case where some view of an entity does not have an
aspect; every entity has every aspect that is associated with that class of
entity. If the aspect is view-specific, then some view might not be able to see
that the aspect has a specified value. But if the aspect is entity-specific (and
we agreed that type-related aspects are in this category), you have to add
separate (Legality) rules for a particular aspect to handle that (as was done
for stream attributes).


If you really want to pursue a model where the aspect itself does not exist in
some cases, then I think you would need to invent a new kind of aspect rather
than reuse an existing one. ("Conditional aspects"?) But I don't think that
there is much point; the current model seems to work fine.

****************************************************************                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                    implementing semantic features.

From: Tucker Taft
Sent: Thursday, March 24, 2011  8:03 PM

OK, I'm convinced.  But I still think we need to acknowledge that something
about visibility or availability or whatever of an aspect specification might
affect whether certain uses are permitted. But if the use is permitted, then I
agree it shouldn't matter whether you are talking about the partial view or the
full view.

****************************************************************                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                    implementing semantic features.

From: Randy Brukardt
Sent: Thursday, March 24, 2011  8:37 PM

Right. One possibility would be to expand the concept of "availability" to other
aspects. But that has lots of other stuff tied up in it, so I suspect it is a
bad idea.

Probably a better idea is to formally define when an aspect is considered to
have been specified (since that depends on visibility). If that's done, then the
wording I've used ("If aspect Blah is specified, then ...") will work properly
in the case of visibility. If you don't like "specified", pick another word. (I
usually use "Muggywomp" as a placeholder for such cases; Steve uses "Frobisher".
"If aspect Blah is Muggywomped, then ..." Perfect! :-)

****************************************************************                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                    implementing semantic features.

From: Tucker Taft
Sent: Thursday, March 31, 2011  10:53 PM

Here is an update to the aspect_specification AI which has some additional stuff
about freezing as it relates to static expressions.  I also allowed
aspect_specifications on subprogram bodies, and added an implementation
permission which basically "anything goes" for the syntax and semantics of
aspect_definitions for implementation-defined aspects.

[Editor's note: The is version /10 of the AI.]

****************************************************************                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                    implementing semantic features.

From: Randy Brukardt
Sent: Friday, April  1, 2011  1:32 AM

Perfect!

April Fool! :-)

(1) I didn't see a Legality Rule to prevent the specification of aspects on a
    subprogram_body unless there is no separate subprogram_specification. I
    don't think we want (heck, I *know* we don't want) hidden aspects (only
    known to the body). A hidden Pre'Class aspect would blow up everything.
    There is an "out" to allow deviations from the normal rules - so a
    particular aspect could allow hidden versions if it wanted them, so I think
    a blanket rule banning them is fine (and preferred).

(2) You didn't back out the botched changes to operational aspects that we
    discussed last week on the ARG list. I thought that we were going to define
    some sort of rule that defined when an aspect can be considered "specified"
    based on visibility, and eliminate most [not all] of the (other??) 13.1
    changes. Particularly 13.1(15). Aspects always exist for types!

(3) [and least] I'm dubious about the "at least in this version" part of the
    AARM note of the Implementation Permission. That seems to say "If we don't
    like what you guys are doing with this toy (the permission), we'll take it
    away at our next chance!! Nah-nah!!". I can't imagine that a future ARG
    would make some AdaCore thing illegal, but it isn't so clear about some
    second-tier vendor in Wisconsin. That note seems to discourage using the
    permission, which seems wrong to me -- if we don't think it is good idea, we
    shouldn't do it at all. So I suggest that we just drop that part.


You can just send me any needed wording changes; I don't want to get the whole
AI again!

****************************************************************                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                    implementing semantic features.

From: Robert Dewar
Sent: Friday, April  1, 2011  7:08 AM

> (1) I didn't see a Legality Rule to prevent the specification of
> aspects on a subprogram_body unless there is no separate
> subprogram_specification. I don't think we want (heck, I *know* we
> don't want) hidden aspects (only known to the body). A hidden Pre'Class aspect
> would blow up everything.
> There is an "out" to allow deviations from the normal rules - so a
> particular aspect could allow hidden versions if it wanted them, so I
> think a blanket rule banning them is fine (and preferred).

This limitation should not affect implementation defined aspects

> (3) [and least] I'm dubious about the "at least in this version" part
> of the AARM note of the Implementation Permission. That seems to say
> "If we don't like what you guys are doing with this toy (the
> permission), we'll take it away at our next chance!! Nah-nah!!". I
> can't imagine that a future ARG would make some AdaCore thing illegal,
> but it isn't so clear about some second-tier vendor in Wisconsin.

Yes it is, even if the ARG were to make such a (peculiar and
ill-advised) decision, the WG9 would never stand for it. In practice gratuitous
non upwards-compatible changes will never get through (that's why the whole
Annex J thing is unnecessary, none of these features will ever be actually
removed).

> That note seems to discourage using the permission, which seems wrong
> to me -- if we don't think it is good idea, we shouldn't do it at all.
> So I suggest that we just drop that part.

I agree with this recommendation

****************************************************************                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                    implementing semantic features.

From: Randy Brukardt
Sent: Friday, April  1, 2011  1:34 PM

> This limitation should not affect implementation defined aspects

I disagree. The default ought to be "no hidden aspects", as those bring up all
kinds of problems. Besides, this is similar to the way that we handled aspects
in renames and aspects for generic formal parameters (and for similar reasons);
they're not allowed by default.

In all of these cases, an implementation can define an aspect that is allowed in
these contexts. But they have to do so explicitly, which demonstrates that the
implementer has thought about the ramifications of allowing that and presumably
applied appropriate rules. We're not going to provide any such rules, so it is
important that the implementer provide them somehow.

It would be bad to allow "hidden aspects" without any framework for what they
mean.

Since the new Implementation Permission allows an implementation-defined aspect
to work in any way that it wants (including syntax), this doesn't constrain
implementation-defined aspects at all, just makes it clear that you are on your
own if you want to use those.

****************************************************************                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                    implementing semantic features.

From: Robert Dewar
Sent: Friday, April  1, 2011  2:19 PM

> In all of these cases, an implementation can define an aspect that is
> allowed in these contexts. But they have to do so explicitly, which
> demonstrates that the implementer has thought about the ramifications
> of allowing that and presumably applied appropriate rules. We're not
> going to provide any such rules, so it is important that the
> implementer provide them somehow.

We agree then, that's all I am asking for, I think your viewpoint is entirely
reasonable.

> It would be bad to allow "hidden aspects" without any framework for
> what they mean.
>
> Since the new Implementation Permission allows an
> implementation-defined aspect to work in any way that it wants
> (including syntax), this doesn't constrain implementation-defined
> aspects at all, just makes it clear that you are on your own if you want to
> use those.

OK, that's fine, especially since the syntax already shows how these aspects
would be spelled if they are added (it's a static semantic rule, not a syntax
rule that forbids them if a separate spec is present).

****************************************************************                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                    implementing semantic features.

From: Bob Duff
Sent: Friday, April  1, 2011  5:10 PM

> Here is an update to the aspect_specification AI ...

> !standard 3.2.1(3)                                 11-03-30  AI05-0183-1/10

>     AARM Discussion: The intent is to allow implementations to support
>     aspects which are defined, for example, by a subtype_indication

"which" --> "that"

****************************************************************                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                    implementing semantic features.

From: Bob Duff
Sent: Friday, April  1, 2011  5:29 PM

> April Fool! :-)

There's a lot of that going around today...

> (3) [and least] I'm dubious about the "at least in this version" part
> of the AARM note of the Implementation Permission. That seems to say
> "If we don't like what you guys are doing with this toy (the
> permission), we'll take it away at our next chance!! Nah-nah!!". I
> can't imagine that a future ARG would make some AdaCore thing illegal,
> but it isn't so clear about some second-tier vendor in Wisconsin. That
> note seems to discourage using the permission, which seems wrong to me
> -- if we don't think it is good idea, we shouldn't do it at all. So I
> suggest that we just drop that part.

I agree with the above paragraph 100%.  If we give this permission now, we mean
it forever and ever, for all Ada implementations.

(And we SHOULD give that permission:  Implementation defined things are
implementation defined!  It almost goes without saying.)

I also suggest you delete the last sentence of the !discussion:

    ...It is possible that a future standard might specify some limitations,
    but it seems premature to do so at this stage.

If we're worried that people will worry that people will go hog-wild with
aspects, then we should mention the No_Impl_Aspects restriction, which is in
some other AI, which should assuage such worries.

****************************************************************                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                    implementing semantic features.

From: Tucker Taft
Sent: Friday, April  1, 2011  10:25 PM

I get the message.  What I was really trying to say was that we were too lazy to
define an extensible syntax at this point, so we are just saying "anything
goes." I thought in some later standard, based on experience, we might come up
with a more "standard" extensible syntax.  But that is probably silly, and I
certainly failed miserably in trying to communicate what I meant.

****************************************************************                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                    implementing semantic features.

From: Randy Brukardt
Sent: Saturday, April  2, 2011  1:14 AM

Since I haven't heard from Tucker, and the deadline is long past, I finished up
the open issues here myself.

I wrote:
> (1) I didn't see a Legality Rule to prevent the specification of
> aspects on a subprogram_body unless there is no separate
> subprogram_specification. I don't think we want (heck, I
> *know* we don't want) hidden aspects (only known to the body). A
> hidden Pre'Class aspect would blow up everything.
> There is an "out" to allow deviations from the normal rules - so a
> particular aspect could allow hidden versions if it wanted them, so I
> think a blanket rule banning them is fine (and preferred).

I added the following to the Static Semantics:

  An aspect shall not be specified in an aspect_specification given on a
  subprogram_body that is a completion of another declaration.

    AARM Reason: Most aspects (for example, preconditions) are intended to be
    available to callers, and specifying them on a body that has a separate
    declaration hides them from callers. Specific aspects (both language-defined
    and implementation-defined) may allow this, but they have to do so
    explicitly (by appealing the following rule or the Implementation
    Permission), and provide any needed rules about visibility.

    [Note: We write this in terms of specifying an aspect, rather than simply
    saying that an aspect_specification is not allowed, so that specific
    aspects can allow this.]

The next rule is: "Alternative legality and semantics rules may apply for
particular aspects, as specified elsewhere in this International Standard." This
would make more sense as a Legality Rule, but since it is closely related to the
formal_parameter and renames rule, I put it next to it.

> (2) You didn't back out the botched changes to operational aspects
> that we discussed last week on the ARG list. I thought that we were
> going to define some sort of rule that defined when an aspect can be
> considered "specified"
> based on visibility, and eliminate most [not all] of the
> (other??) 13.1 changes. Particularly 13.1(15). Aspects always exist
> for types!

I meant 13.1(11/2) above. We remove the changes to that paragraph, then add a
rule to explain visibility of aspect specifications. This is not my best work,
but this is what I came up with:

Add to the Static Semantics:

If a Legality Rule or Static Semantics rule only applies when a particular
aspect has been specified, the aspect is considered to have been specified only
when the aspect_specification or attribute_definition_clause is visible (see
8.3) at the point of the application of the rule.

AARM Reason: Some rules only apply when an aspect has been specified (for
instance, an indexable type is one that has aspect Variable_Indexing specified).
In order to prevent privacy breaking, this can only be true when the
specification of the aspect is visible. In particular, if the Variable_Indexing
aspect is specified on the full view of a private type, the private type is not
considered an indexable type.

[This is referring to 8.3(23.1/3), which defines the visibility of an
aspect_specification or attribute_definition_clause. We don't need to define
this for pragmas; these all control run-time effects.

I defined this in this way so that I didn't need to introduce a new term and
then find and change all of the associated uses. But perhaps a new term would be
better given that "specified" already has a meaning for aspects (see 13.1).]

****************************************************************                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                    implementing semantic features.

From: John Barnes
Sent: Thursday, April  7, 2011  4:22 AM

The AARM note in 13.3.1 says

      AARM NOTE: The aspect_specification is an optional element
        in most kinds of declarations. Here is a list of all kinds of
        declarations and an indication of whether or not they allow aspect clauses,
        and in some cases a short discussion of why (* = allowed, NO = not allowed)

     ...

        renaming_declaration*  -- There are no
          -- language-defined aspects specifiable on renames.
     ...

      generic_formal_parameter_declaration*
        -- There are no language-defined aspects that
        -- may be specified on generic formals, but implementations
        -- might support some. The implementation would have to
        -- define the matching rule.
      extended_return_statement  --  NO
     End of AARM Note.

Should not the chatter about generic formals and renaming be identical? And
perhaps gathered together at the end of the note.

I don't know whther the !discussion is up for chnage as well but it ought to
be mentioned there as well. And maybe the business about subprogram bodies.

****************************************************************                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                    implementing semantic features.

From: Tucker Taft
Sent: Monday, May 2, 2011  9:44 PM

[Appropriate part of a large message - Editor.]

AI05-0183-1/14  Aspect specifications
    [Changes from phone meeting: removed Address aspect as a special case.
     Changes from Bob's editorial review.]
    Approve ___X___ Disapprove ______ Abstain _______
   Comments:  This paragraph could use a bit of editorial improvement,
    by substituting "identify" or "define" or almost anything instead
    of "specify," especially in the third sentence:
     All specifiable operational and representation attributes may be
     specified with an aspect_specification instead of an
     attribute_definition_clause (see 13.3). The attribute_designator is
     used for the aspect_mark. In addition, certain other operational and
     representation aspects not associated with specifiable attributes may
     be specified, as specified elsewhere in this International Standard.
     In the case of aspects specifiable with pragmas, the pragma identifier
     is used for the aspect_mark, unless otherwise specified in this International
     Standard.

    The department of redundancy department loves this sentence (one of the
    "attributes" needs to go) in 13.13.2:
      The {type-related} operational attributes Write, Read, Output, and
      Input attributes convert values to a stream of elements and
      reconstruct values from a stream.

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

From: Randy Brukardt
Sent: Monday, May 2, 2011  10:32 PM

[Appropriate part of a larger message - Editor.]

> AI05-0183-1/14  Aspect specifications
>     [Changes from phone meeting: removed Address aspect as a special case.
>      Changes from Bob's editorial review.]
>     Approve ___X___ Disapprove ______ Abstain _______
>    Comments:  This paragraph could use a bit of editorial improvement,
>     by substituting "identify" or "define" or almost anything instead
>     of "specify," especially in the third sentence:
>      All specifiable operational and representation attributes may be
>      specified with an aspect_specification instead of an
>      attribute_definition_clause (see 13.3). The attribute_designator is
>      used for the aspect_mark. In addition, certain other operational and
>      representation aspects not associated with specifiable attributes may
>      be specified, as specified elsewhere in this International Standard.
>      In the case of aspects specifiable with pragmas, the pragma identifier
>      is used for the aspect_mark, unless otherwise specified in this International
>      Standard.

Unfortunately, "specify" here is a technical term, so I don't think we can change it
to something else. 13.3 uses "specifiable attribute" and "attribute_definition_clause
that specifies", and those are the terms that we are trying to (re)define here.
"unless otherwise specified" is pretty standard boilerplate (I found at least 8 other
references to it in the current RM).

So there is only one use of "specify" in the whole paragraph that we could even consider
changing, the one in the third sentence.

"In addition, certain other operational and representation aspects not associated with
specifiable attributes may be *specified*, as specified elsewhere in this International
Standard."

But it is odd to use another term here, as this is an "aspect_specification", not an
"aspect_definition" or an "aspect_identification".

So I don't think there is much that we can do with this one, unless someone has a
substitute for "unless otherwise specified".

>     The department of redundancy department loves this sentence (one of the
>     "attributes" needs to go) in 13.13.2:
>       The {type-related} operational attributes Write, Read, Output, and
>       Input attributes convert values to a stream of elements and
>       reconstruct values from a stream.

The last one is deleted text picked up by cut-and-paste from the HTML RM.

****************************************************************                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                    implementing semantic features.

From: Erhard Ploedereder
Sent: Sunday, May 15, 2011 at 11:31 AM

[The appropriate part of a longer message - Editor.]

AI05-0183-1/14  Aspect specifications
   [Changes from phone meeting: removed Address aspect as a special case.
    Changes from Bob's editorial review.]
   Approve ______ Disapprove ___X___ Abstain _______

======================

Editorials:

> Modify 13.1(8.1/1) as follows:

the para. lacks a "}"

> Other aspect_specifications are associated with the entity, and apply
> to all views of the entity, unless otherwise specified in this
> International Standard.

Change to: "All other ..."

> There are no language-defined aspects that may be specified on a
> renaming_declaration nor on a formal_type_declaration.

"nor" -"or" by my English teacher, since it is not the "specified"
that is negated. "may be specified neither on .. nor on..." would be the correct
use of "nor".


Technical concerns:

> In the case of aspects specifiable with pragmas, the pragma identifier
> is used for the aspect_mark, unless otherwise specified in this International
>   Standard.

Is it really intended that implementation-defined pragmas are unconditionally
restricted to abide by this rule? (Probably not.)


> Alternative legality and semantics rules may apply for particular
> aspects, as specified elsewhere in this International Standard.

"Additional" I'll buy any day, but "Alternative" rules in unspecified places are
a completely bogus way of describing a language.

****************************************************************                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                    implementing semantic features.

From: Randy Brukardt
Sent: Tuesday, May 17, 2011 at  2:08 AM

...
> AI05-0183-1/14  Aspect specifications
>    [Changes from phone meeting: removed Address aspect as a special case.
>     Changes from Bob's editorial review.]
>    Approve ______ Disapprove ___X___ Abstain _______
>
> ======================
>
> Editorials:
>
> > Modify 13.1(8.1/1) as follows:
>
> the para. lacks a "}"

Got it.

> > Other aspect_specifications are associated with the entity, and
> > apply to all views of the entity, unless otherwise specified in this
> > International Standard.
>
> Change to: "All other ..."

OK.

> > There are no language-defined aspects that may be specified on a
> > renaming_declaration nor on a formal_type_declaration.
>
> "nor" -"or" by my English teacher, since it is not the "specified"
> that is negated. "may be specified neither on .. nor on..."
> would be the correct use of "nor".

I think you are right.

>
> Technical concerns:
>
> > In the case of aspects specifiable with pragmas, the pragma
> > identifier is used for the aspect_mark, unless otherwise specified in this International
> >   Standard.
>
> Is it really intended that implementation-defined pragmas are
> unconditionally restricted to abide by this rule? (Probably not.)

I don't think anything mentioned in the Standard could really affect
implementation-defined anythings, especially in a case like this.

But I don't see a better way to say this, short of dropping the "in this
International Standard" part. And I believe we originally had the wording that
way and others complained. So I won't make a change here until/unless a better
alternative emerges.

> > Alternative legality and semantics rules may apply for particular
> > aspects, as specified elsewhere in this International Standard.
>
> "Additional" I'll buy any day, but "Alternative" rules in unspecified
> places are a completely bogus way of describing a language.

Maybe, but otherwise we would not be able to define "default" rules for
processing aspects (which is what these are). But the default rules need to be
able to be overridden in various places. For example, the rules about boolean
aspects are explictly overridden for Default_Value when it happens to be
boolean. The alternatives are not good: either duplicating rules everywhere (I
hope not), or defining many additional classes of aspects and then repeating all
of the rules for each. (That potentially would include repeating the rules of
13.1, since those too are overridden sometimes with "alternative" rules.)

If you have a proposal for dealing with this that does not require "alternative"
rules, please make it, but in the absence of some sort of concrete proposal I
don't think that I can do anything with this comment.

****************************************************************                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                    implementing semantic features.

From: Robert Dewar
Sent: Saturday, September 20, 2011 at 12:28 PM

impl defined syntax for aspects
is quite fun, here is a fun aspect for a function

   with C_Implementation =>
      int a (int b)
        {return (b + b);};

My understanding is that this is conforming :-)

****************************************************************                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                    implementing semantic features.

From: Randy Brukardt
Sent: Saturday, September 20, 2011 at 12:28 PM

I would agree.

It's impossible to decide what would be going too far, so we pretty much have to
allow anything.

While the above might be dubious, if the language in question was not much like
Ada (such as a formal specification language or perhaps a theorem proving
language like Prolog), it might even make sense by bringing to Ada capabilities
that would be hard otherwise. Indeed, this might provide a way to get SQL really
into Ada.

Aside: Janus/Ada includes a bunch of pragmas for creating Windows resource
objects within the Ada program -- that's valuable as it provides the best way to
get Ada symbols into the resource data. One could imagine having modeled those
as aspects instead, attaching them to the associated objects.

Anyway, my point from all of these ramblings is simply that this capability will
open up all kinds of possibilities for the clever compiler-writer, and could
allow Ada mechanisms to support things that would otherwise be inconceivable.

****************************************************************                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                                                                                
                                                                                                                                                                                                    implementing semantic features.

Questions? Ask the ACAA Technical Agent