[Ada-Comment] First attempt for AI22-0097-1

[Christoph & Ursula Grein]

These are my findings in the clauses 1 to 3. They are debatable because 
the NOTEs do not use words like "should" etc. but might as well be 
considered usage advice because of words like "can", "recommend" or 
similar. Perhaps I've also missed some candidates.

I've used the RM version 2022 with differences to 2012 TC1 in case you 
want to undo those last changes.

I hope this approximates ;-) what you'd like so have... See attachment.

Christoph
Title: AI22-0097-1/01












Modify 1.1.4(19):
{Usage}
[NOTE 1  ]
The syntax rules describing 
structured constructs are presented in a form that corresponds to the 
recommended paragraphing. For example, an if_statement 
is defined as:

Modify 1.1.4(21):
[NOTE 2  ]
The line breaks and indentation 
in the syntax rules indicate the recommended line breaks and indentation 
in the corresponding constructs. The preferred places for other line 
breaks are after semicolons.

Modify 3.2.2(13/5):
{Usage}
A scalar_constraint 
can may be 
applied to a subtype of an appropriate scalar type (see 3.5, 
3.5.9, and J.3), 
even if the subtype is already constrained. On the other hand, a composite_constraint 
can may be 
applied to a composite subtype (or an access-to-composite subtype) only 
if the composite subtype is unconstrained (see 3.6.1 
and 3.7.1).

Modify 3.5.1(12):
{Usage}
[NOTE  ]
If an enumeration literal occurs 
in a context that does not otherwise suffice to determine the type of 
the literal, then qualification by the name of the enumeration type is 
one way to resolve the ambiguity (see 4.7).

Add after 3.5.2(5/3):
Usage
A conventional character set such as EBCDIC can be declared as 
a character type; the internal codes of the characters can be specified 
by an enumeration_representation_clause 
as explained in 13.4.

Delete 3.5.2(9/5):
NOTE 2   A conventional character set such as EBCDIC can be declared as 
a character type; the internal codes of the characters can be specified 
by an enumeration_representation_clause 
as explained in 13.4.

Add after 3.5.5(8):
Usage
For a subtype of a discrete type, the result delivered by the attribute 
Val can be outside might 
not belong to the subtype; similarly, the actual parameter of 
the attribute Pos can also be outside need 
not belong to the subtype. The following relations are satisfied 
(in the absence of an exception) by these attributes:

S'Val(S'Pos(X)) = X
S'Pos(S'Val(N)) = N

Delete 3.5.5(12/5):
NOTE 4   For a subtype of a discrete type, the result delivered by the attribute 
Val can be outside might 
not belong to the subtype; similarly, the actual parameter of 
the attribute Pos can also be outside need 
not belong to the subtype. The following relations are satisfied 
(in the absence of an exception) by these attributes:

Delete 3.5.5(13):
S'Val(S'Pos(X)) = X
S'Pos(S'Val(N)) = N

Add after 3.5.10(14):
Usage
S'Scale is not always the 
same as S'Aft for a decimal subtype; for example, if S'Delta = 1.0 then 
S'Aft is 1 while S'Scale is 0.

Delete 3.5.10(16):
NOTE 2   S'Scale is not always the 
same as S'Aft for a decimal subtype; for example, if S'Delta = 1.0 then 
S'Aft is 1 while S'Scale is 0.

Modify 3.7(28):
{Usage}
[NOTE 1  ]
If a discriminated type has 
default_expressions 
for its discriminants, then unconstrained variables of the type are permitted, 
and the values of the discriminants can be changed by an assignment to 
such a variable. If defaults are not provided for the discriminants, 
then all variables of the type are constrained, either by explicit constraint 
or by their initial value; the values of the discriminants of such a 
variable cannot be changed after initialization.

Add after 3.9.1(5):
Usage
When an extension is declared immediately within a body, primitive subprograms 
are inherited and are overridable, but new primitive subprograms cannot 
be added.

Delete 3.9.1(7/2):
NOTE 2 When an extension is declared immediately within a body, primitive subprograms 
are inherited and are overridable, but new primitive subprograms cannot 
be added.

Add after 3.10.2(32.6/5):
Usage
The Access attribute for subprograms 
and parameters of an anonymous access-to-subprogram type can 
be used may together be used to implement “downward closures” — that 
is, to pass a more-nested subprogram as a parameter to a less-nested 
subprogram, as can might 
be appropriate for an iterator abstraction or numerical integration. 
Downward closures can also be implemented using generic formal subprograms 
(see 12.6). Unlike for 
objects, there is no Note that Unchecked_Access 
attribute is not allowed 
for subprograms.

Using Note that using 
an access-to-class-wide tagged type with a dispatching operation is a 
potentially more structured alternative to using an access-to-subprogram 
type.

Delete 3.10.2(37/5):
NOTE 5 The Access attribute for subprograms 
and parameters of an anonymous access-to-subprogram type can 
be used may together be used to implement “downward closures” — that 
is, to pass a more-nested subprogram as a parameter to a less-nested 
subprogram, as can might 
be appropriate for an iterator abstraction or numerical integration. 
Downward closures can also be implemented using generic formal subprograms 
(see 12.6). Unlike for 
objects, there is no Note that Unchecked_Access 
attribute is not allowed 
for subprograms.

Delete 3.10.2(38/5):
NOTE 6 Using Note that using 
an access-to-class-wide tagged type with a dispatching operation is a 
potentially more structured alternative to using an access-to-subprogram 
type...