Version 1.5 of ai05s/ai05-0248-1.txt

• The accessibility level of the operand type shall not be statically deeper than that of the target type. In addition to the places where Legality Rules normally apply (see 12.3), this rule applies also in the private part of an instance of a generic unit.

• The accessibility level of the operand type shall not be statically deeper than that of the target type, unless the target type is an anonymous access type of a stand-alone object. If the target type is that of such a stand-alone object, the accessibility level of the operand type shall not be statically deeper than that of the declaration of the stand-alone object. In addition to the places where Legality Rules normally apply (see 12.3), this rule applies also in the private part of an instance of a generic unit.

• For an access-to-object type, a check is made that the accessibility level of the operand type is not deeper than that of the target type.

• For an access-to-object type, a check is made that the accessibility level of the operand type is not deeper than that of the target type, unless the target type is an anonymous access type of a stand-alone object. If the target type is that of such a stand-alone object, a check is made that the accessibility level of the operand type is not deeper than that of the declaration of the stand-alone object; if the check suceeds, the accessibility level of the target type becomes that of the operand type.

[Editor's note: These mails are organized by section of change, rather
than by the date.]

From: John Barnes
Sent: Tuesday, September 21, 2010  1:41 PM

I found a few typos in my review. I also added a note about 4.9(37.a/3)
which seems to be out of place.

So here it is again attached as a text file since I noticed that copying it
into the email produced lots of white space.

====

Review of RM 2012

Introduction 57.13/3   I expect that I have to write this.

1.1.4 (12/3)   this has "a iterator specification" rather than "an iterator
	       specification"

Maybe old version of AI got in somehow.

In any event, further to recent email discussion, I assume this will all stay as
it originally was.

1.1.4 (21.d3)  Reads as if punctuation is wrong. In any event this should go
	       with changes to use => in quantified expressions.

2.2(7.1/3)  Should say "One or more".  It's OK in the AI.

2.3(8.d/3)  rem{o}ved  and why the original Ada 2005. Surely there is only one.
	    Delete original.

2.9(3.f/2)  this should be 3.f/3 and in red.  Also please edit as below

3.f/2     {AI05-0176-1} {incompatibilities with Ada 2005} The following word
          is not reserved in Ada 2005, but [are]{is} reserved in Ada 2012: some. Use{s}
          of this word as an identifier will need to be changed, but we do not
          expect them to be common.

4.5.2(39.m/3)  line 3 change "made" to "make"

4.5.5(35.e/3)  line 3 change "made" to "make"   (cut and paste error?)


4.5.7(5.l/3)  discussion about compilers might usefully point out that
	      conditional expressions don't have end if and end case which might
	      impact on error recovery. Also edit as below, change a to an

5.l/3     Implementation Note: {AI05-0147-1} Implementers are cautioned to
          consider error detection when implementing the syntax for
          conditional_expressions. An if_expression and a{n} if_statement are
          very similar syntactically, (as are a case_expression and a
          case_statement) and simple mistakes can appear to change one into
          the other, potentially causing errors to be moved far away from
          their actual location.

4.5.7(12.a/3) edit as below, add s to expression

12.a/3     Ramification: If the type of the conditional_expression cannot be
          determined by one of these rules, the Name Resolution has failed for
          that expression, even if the dependent_expression{s} would resolve
          individually.

4.5.7(16/3) edit as below, insert "the" on line 6 the AI needs changing too.

16/3  {AI05-0147-1} For the execution of an if_expression, the condition
specified after if, and any conditions specified after elsif, are evaluated in
succession (treating a final else as elsif True then), until one evaluates to
True or all conditions are evaluated and yield False. If a condition evaluates
to True, the associated dependent_expression is evaluated, converted to the
type of the if_expression, and {the} resulting value is the value of the
if_expression. Otherwise, the value of the if_expression is True.


4.5.9  Change this to use => rather than vertical bar. This simplifies things a bit.

Also we seem to be running ahead of ourselves. We don't have iterator
specification defined yet.

1/3   {AI05-0176-1} quantified_expression ::= for quantifier
       loop_parameter_specification [|]{=>} predicate
        | for quantifier iterator_specification [|]{=>} predicate

delete (3.a/3)   comment about the vertical bar can go
change examples 11/3 and 13/3 to use =>

4.8(2.a/3)  I would delete "the most" as below

2.a/3     Reason: Such an uninitialized allocator would necessarily raise
          Constraint_Error, as the default value is null. Also note that the
          syntax does not allow a null_exclusion in an initialized allocator,
          so it makes [the most] sense to make the uninitialized case illegal as
          well.

4.8(5.3/3)  seems to disagree with AI-157. too many sentences deleted

also why was last sentence of 5.e/3 deleted?


4.9(33 etc)  I don't see why we really need all this statically unevaluated
	     stuff (nasty term). We don't get exceptions at compile time. I
	     don't believe we discussed this much in a meeting. If we did I was
	     asleep. And I don't think the AI has been reviewed yet.  On second
	     thoughts it's OK.

4.9(37.a/3)

This seems to be partly in the wrong place. Consider

36/3    * {AI05-0147-1} {AI05-0188-1} a condition or dependent_expression of
      an if_expression where the condition corresponding to at least one
      preceding dependent_expression of the if_expression is static and equals
      True; or

36.a/3     Reason: We need this bullet so that only a single
          dependent_expression is evaluated in a static if_expression if there
	  is more than one condition that evaluates to True. The part about
	  conditions makes

36.b/3         (if N = 0 then Min elsif 10_000/N > Min then 10_000/N else Min)

36.c/3     legal if N and Min are static and N = 0.

37/3    * {AI05-0188-1} a dependent_expression of a case_expression whose
      expression is static and not covered by the corresponding
      discrete_choice_list.

37.a/3     Discussion: {AI05-0147-1} {AI05-0188-1} We need the "of the
          if_expression" here so there is no confusion for nested
          if_expressions; this rule only applies to the conditions and
          dependent_expressions of a single if_expression. Similar reasoning
          applies to the "of a case_expression" of the last bullet.

This says "of the if expression" and so seems to be referring to 36/3 not 37/3.

==

Annex G looks fine. All corrections have been made OK. There were no real
changes thank goodness.

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

From: Randy Brukardt
Sent: Thursday, March 31, 2011  11:46 PM

John Barnes wrote in his editorial review way back in September:

>Review of RM 2012
>
>Introduction 57.13/3   I expect that I have to write this.

You did. :-)

>1.1.4 (12/3)   this has "a iterator specification" rather than "an iterator specification"
>
>Maybe old version of AI got in somehow.
>
>In any event, further to recent email discussion, I assume this will
>all stay as it originally was.
>
>1.1.4 (21.d3)  Reads as if punctuation is wrong. In any event this
>should go with changes to use => in quantified expressions.

All of this 1.1.4 stuff is OBE.

> 2.2(7.1/3)  Should say "One or more".  It's OK in the AI.

Must have keyed this one by hand. Fixed.

> 2.3(8.d/3)  rem{o}ved  and why the original Ada 2005. Surely there is only
> one. Delete original.

This is documenting a "correction" (a Binding Interpretation) which applies to
Ada 2005 compilers as well as Ada 2012. In theory, all Ada compilers will make
the change. (So far as I know, no compiler ever was released implementing the
original rule, so the incompatibility is not very likely :-).

I used "original" this way in a number of AARM notes. Since they are AARM notes,
I can just change them - won't take long. But I'd like an alternative wording.
"Initial Ada 2005"? "Uncorrected Ada 2005"? "Unmodified Ada 2005"? "2007 version
of the Ada 2005"? ;-) "Ada 2005 as defined by directly by Amendment 1"?

But I want some indication that we're talking about the original, unsullied
version of Ada 2005. I don't think writing out the entire explanation is helpful
(because this is common):

"... This change can only affect programs written for an early Ada 2005
implementation (recall that as a correction, Ada 2005 compilers can and ought to
apply this change), so there should be few such programs. "

1.1.2(39.dd/3) explains the meaning of "Correction:"; it too uses "original Ada
2005 definition". There are similar paragraphs for the other "from Ada 2005"
sections as well.

If you have a suggestion for a better presentation, I'll be happy to apply it.

>2.9(3.f/2)  this should be 3.f/3 and in red.  Also please edit as below

>3.f/2     {AI05-0176-1} {incompatibilities with Ada 2005} The following word
>          is not reserved in Ada 2005, but [are]{is} reserved in Ada 2012: some. Use{s}
>          of this word as an identifier will need to be changed, but we do not
>          expect them to be common.

OK, although 2 out of 3 already were detected.

> 4.5.2(39.m/3)  line 3 change "made" to "make"

> 4.5.5(35.e/3)  line 3 change "made" to "make"   (cut and paste error?)

Obviously, I saved time when inserting errors by cutting and pasting them.
:-) Fixed.

> 4.5.7(5.l/3)  discussion about compilers might usefully point out that
> conditional expressions
> don't have end if and end case which might impact on error recovery.
> Also edit as below, change a to an
>
>5.l/3     Implementation Note: {AI05-0147-1} Implementers are cautioned to
>          consider error detection when implementing the syntax for
>          conditional_expressions. An if_expression and a{n} if_statement are
>          very similar syntactically, (as are a case_expression and a
>          case_statement) and simple mistakes can appear to change one into
>          the other, potentially causing errors to be moved far away from
>          their actual location.

This was already done (including adding an extra sentence), probably in response
to your editorial review of the AI.

>4.5.7(12.a/3) edit as below, add s to expression
>
>12.a/3     Ramification: If the type of the conditional_expression cannot be
>          determined by one of these rules, the Name Resolution has failed for
>          that expression, even if the dependent_expression{s} would resolve
>          individually.

OK.

> 4.5.7(16/3) edit as below, insert "the" on line 6 the AI needs
> changing too.
>
> 16/3  {AI05-0147-1} For the execution of an if_expression, the
> condition specified after if, and any conditions specified after
> elsif, are evaluated in
> succession (treating a final else as elsif True then), until one evaluates to
> True or all conditions are evaluated and yield False. If a condition evaluates
> to True, the associated dependent_expression is evaluated, converted to the
> type of the if_expression, and {the} resulting value is the value of
> the if_expression. Otherwise, the value of the if_expression is True.

Previously fixed.

> 4.5.9  Change this to use => rather than vertical bar. This simplifies
> things a bit.
>
> Also we seem to be running ahead of ourselves. We don't have iterator
> specification defined yet.
>
> 1/3   {AI05-0176-1} quantified_expression ::= for quantifier
>       loop_parameter_specification [|]{=>} predicate
>        | for quantifier iterator_specification [|]{=>} predicate
>
>delete (3.a/3)   comment about the vertical bar can go
>change examples 11/3 and 13/3 to use =>

This was done as part of an AI update long ago.

> 4.8(2.a/3)  I would delete "the most" as below
>
>2.a/3     Reason: Such an uninitialized allocator would necessarily raise
>          Constraint_Error, as the default value is null. Also note that the
>          syntax does not allow a null_exclusion in an initialized allocator,
>          so it makes [the most] sense to make the uninitialized case illegal as
>          well.

OK.

>4.8(5.3/3)  seems to disagree with AI-157. too many sentences deleted

There are two AIs reflected in this paragraph, AI05-0052-1 and AI05-0157-1.
AI05-0157-1 deletes the last sentence. AI05-0052 moves the penultimate sentence
to its own paragraph (4.8(5.5/3)). So I think this is correct.

>also why was last sentence of 5.e/3 deleted?

It was 4.8(5.e/2); it was replaced by this longer explanation from AI05-0157-1.
Typically, deleted text goes after the inserted text that replaces it. I do
realize it looks weird, but I don't think that there is much that can be done.

>4.9(33 etc)  I don't see why we really need all this statically
>unevaluated stuff (nasty term). We don't get exceptions at compile
>time. I don't believe
>we discussed this much in a meeting. If we did I was asleep. And I don't think
>the AI has been reviewed yet.  On second thoughts it's OK.

Nice to know that you have strong convictions. :-)

The term is new, of course, but the concept exists all the way back to Ada 95.
The right-hand side of a short circuit is not evaluated at compile-time if the
left operand determines the value. The important part of that is that a static
expression is illegal if it fails a compile-time check. If we didn't have
"statically unevaluated", "A /= 0 and then 100 / A > 10" would be illegal if A
is statically 0. Which would defeat the purpose of having written the
short-circuit in the first place.

The term is needed to extend this idea to conditional expressions. We don't want
(if A /= 0 then 100 / A else 0) to be illegal if A is statically 0 - this would
defeat the purpose of the conditional itself.

Nobody was all that excited about this term, but it was the best we came up
with. If you can come up with a better term, please do!

>4.9(37.a/3)
>
>This seems to be partly in the wrong place. Consider
>
>36/3    * {AI05-0147-1} {AI05-0188-1} a condition or dependent_expression of
>      an if_expression where the condition corresponding to at least one
>      preceding dependent_expression of the if_expression is static and equals
>      True; or
>
>36.a/3     Reason: We need this bullet so that only a single
>          dependent_expression is evaluated in a static if_expression
>          if there is more
>          than one condition that evaluates to True. The part about
>          conditions makes
>
>36.b/3         (if N = 0 then Min elsif 10_000/N > Min then 10_000/N else Min)
>
>36.c/3     legal if N and Min are static and N = 0.
>
>37/3    * {AI05-0188-1} a dependent_expression of a case_expression whose
>      expression is static and not covered by the corresponding
>      discrete_choice_list.
>
>37.a/3     Discussion: {AI05-0147-1} {AI05-0188-1} We need the "of the
>          if_expression" here so there is no confusion for nested
>          if_expressions; this rule only applies to the conditions and
>          dependent_expressions of a single if_expression. Similar reasoning
>          applies to the "of a case_expression" of the last bullet.
>
>This says "of the if expression" and so seems to be referring to 36/3
>not 37/3.

Yup. It was already moved.

>==
>
>Annex G looks fine. All corrections have been made OK. There were no
>real changes thank goodness.

Great.

I think this is the point where you announce that you need a gin. I feel the
same way, although in my case it will be a Capital Blonde Dopplebock (just
picked that up shopping on Tuesday - it's probably Capital's best beer, although
rather expensive).

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

From: Bob Duff
Sent: Friday, April  1, 2011  7:47 AM

> >Review of RM 2012

Question for John:  Did you actually read the entire document?
Did you print it out, or read it online?
How long did it take?

> I used "original" this way in a number of AARM notes. Since they are
> AARM notes, I can just change them - won't take long. But I'd like an
> alternative wording. "Initial Ada 2005"? "Uncorrected Ada 2005"? "Unmodified Ada 2005"?
> "2007 version of the Ada 2005"? ;-) "Ada 2005 as defined by directly
> by Amendment 1"?

"original Ada 2005" expresses perfectly what you mean.

> >3.f/2     {AI05-0176-1} {incompatibilities with Ada 2005} The following word
> >          is not reserved in Ada 2005, but [are]{is} reserved in Ada 2012: some. Use{s}
> >          of this word as an identifier will need to be changed, but we do not
> >          expect them to be common.

There are some some in the AdaCore test suite.

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

From: John Barnes
Sent: Friday, April  1, 2011  11:58 AM

> Question for John:  Did you actually read the entire document?
> Did you print it out, or read it online?
> How long did it take?

I read the bits I was told to read. I read it online.

How long?  Too long!!   I cannot remember. Most time was taken over puzzling
cases where more than one AI affected a paragraph.

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

From: Randy Brukardt
Sent: Friday, April  1, 2011  11:19 PM

> > >3.f/2     {AI05-0176-1} {incompatibilities with Ada 2005}
> > >          The following word
> > >          is not reserved in Ada 2005, but [are]{is}
> > >          reserved in Ada 2012: some. Use{s}
> > >          of this word as an identifier will need to be
> > >          changed, but we do not expect them to be common.
>
> There are some some in the AdaCore test suite.

The above is essentially the boilerplate used to justify new reserved words.
I don't actually believe it.

Besides the somes in the AdaCore test suite, there are a lot of somes in the
source to the Janus/Ada compiler. These were the reasons that we tried to use an
unreserved keyword. As usual, the US was in favor, the rest of the world wasn't.

I suspect this will bite a lot of code, but I can hardly write the truth here:

...Use{s} of this word as an identifier will need to be changed; there probably
will be a lot of them in some code (there is in mine!). We tried to avoid this
incompatibility, but the idea of unreserved keywords makes our European
reviewers uncomfortable and they have the majority of votes at WG 9, so we had
to live with this incompatibility. If this bothers you, please complain to the
members of your national body (especially if you are European); maybe we'll have
enough votes next time.

:-) :-)

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

From: Tullio Vardanega
Sent: Saturday, October  9, 2010  2:12 PM

  9.3(7/2, 8)
the style used elsewhere for lists takes lowercase initials; cf. for example
note 12 below on the same page

9.5.1(30)
the Count attribute is referred to without being first defined (in fact, its
first occurrence is at 8.5.4(11)); it should probably need a forward reference
to 9.9(5)

9.6.1(6/2)
function UTC_Time_Offset (Date
should be
function UTC_Time_Offset(Date
i.e. no space before open bracket

9.6.1(12/2)
procedure Difference (Left
should be
procedure Difference(Left
i.e. no space before open bracket

9.6.1(13/2)
the declaration of all functions at this clause should be have one space less
before the first open bracket

9.6.1(15/2)
the declaration of all subprograms in package Ada.Calendar.Formatting should be
have one space less before the first open bracket

9.6.1(41/2)
function UTC_Time_Offset (Date
should be
function UTC_Time_Offset(Date

9.6.1(43/2)
procedure Difference (
should be
procedure Difference(
and the subsequent three lines retracted by one space

all subsequent subprograms until 87/2 should be fixed the same way

9.7.4(8)
the asynchronous_select is complete.
should probably be
the asynchronous_select is completed.

9.11
when trying to put together the example I have noticed that type Month_Name
referred to at 3.8(27) is never defined anywhere in the RM

in the same example, it should be good that type Person_Name_Array was
explicitly defined

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

From: Randy Brukardt
Sent: Tuesday, April 19, 2011 12:04 AM

>   9.3(7/2, 8)
> the style used elsewhere for lists takes lowercase initials; cf. for
> example note 12 below on the same page

There is no consistent style for bulleted lists in the Ada Standard. Case in
point: 9.3, where your can find three styles for a bulleted list (para 2-3.1
uses capitals and periods; para 7-8 uses capitals, semicolons, "and"; para 15-18
uses lower case and semicolons, no "or" or "and"). Looking at 9.4, we see para
11.6-7 using lower case, semicolons, and "or"; para 11.11-12 using lower case,
semicolons, no "or" or "and"; para 17-18 using capitals and semicolons, no "or"
or "and". See any commonality there? :-)

Given the intent to not mess with "old bugs", we're not going to try to make
these consistent now at this late date.

> 9.5.1(30)
> the Count attribute is referred to without being first defined (in
> fact, its first occurrence is at 8.5.4(11)); it should probably need a
> forward reference to 9.9(5)

You mean 9.5.2(30). Both of these references are Notes, so I don't feel terribly
compelled to put in a forward reference; and again this is ancient.

> 9.6.1(6/2)
> function UTC_Time_Offset (Date
> should be
> function UTC_Time_Offset(Date
> i.e. no space before open bracket

Huh? The format the Standard always has a space between the subprogram name and
the parameter list.

Calendar and other ancient packages occasionally violate the style, but not so
with new packages.

...
> 9.7.4(8)
> the asynchronous_select is complete.
> should probably be
> the asynchronous_select is completed.

I'm not sure. I think it is referring to the term "complete" as defined in
7.6.1(1). "Completed" seems to me to imply some action occurring, whereas this
case is just stating a fact. So I think this is insufficiently broken to bother
fixing.

> 9.11
> when trying to put together the example I have noticed that type
> Month_Name referred to at 3.8(27) is never defined anywhere in the RM
>
> in the same example, it should be good that type Person_Name_Array was
> explicitly defined

Month_Name would have to declared in 3.5.1's examples, and it is a bit long for
there.

Person_Name_Array would probably have to go into 9.11, but it's primary purpose
would be to highlight a flaw in Ada (the fact that you can't put types into
protected types, and thus structuring protected types is a real pain). Not sure
that is a good idea.

I'm sympathetic, especially for the latter (as this was a new example added at
the last minute to Ada 2005). But I worry that some would see it as cluttering
the example.

Does anyone else have an opinion on this one??

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

From: John Barnes
Sent: Tuesday, April 19, 2011 11:18 AM

> Person_Name_Array would probably have to go into 9.11, but it's
> primary purpose would be to highlight a flaw in Ada (the fact that you
> can't put types into protected types, and thus structuring protected
> types is a real pain). Not sure that is a good idea.

It would be a very good idea and help to highlight a real pain that needs to be
sorted out. Maybe I jest. More important in my view than half the stuff actually
put into Ada 2012.  Grumble grumble.

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

From: Erhard Ploedereder
Sent: Saturday, October  9, 2010 10:41 AM

My review assignment...

==========================================

10.2.1. 11/3 and 17/3  see separate mail entitled "[ARG] technical issue of
prelaborated and pure limited views" on these two paragraphs.

===========================================

11.1 2/3  Formating: the aspect clause should not start a new line.

===========================================

11.4.1 10.1/3 penultimate sentence:
> For an occurrence originally raised for some other reason, the message
> is an unspecified string.

lazy wording "for some other reason". In "if things-go-bump then raise fright;
end if;" things-go-bump is the reason for the exception, not the raise
statement.

According to 11 2/3(2.sentence) only implicit raises are left. If indeed
9.5.2(24) is an extra case, 11 2/3 needs fixing, too, but presumably it is but a
propagation and hence not an extra case. Footnote: I would prefer
implementation-defined string. Oh well.

Rewrite:
-----
For an occurrence originally raised by a language-defined check, the message is
an unspecified string.

===========================

12.1 3/3  Formating: the aspect clause should not start a new line.

==============================

12.4 2/3  Formating: the aspect clause should not start a new line.

==============================

OLD BUG:
12.4. 5/2 Delete the spurious second period at the end of the para.

==============================

12.5 2/3  Formating: the aspect clause should not start a new line.

=============================

Before 12.5.3. Strange "NewPage" mistake in formatting.

============================

12.6 2/3  Formating: the aspect clause should not start a new line.

============================

12.6. 10/3 is desperately in need of grammatical (and possibly
conceptual) simplification. Also "this default_name" in the 2. sentence has no
binding in the text at all.  The lead-in sentence talks about box not
default_name.

> If a generic unit has a subprogram_default specified by a box, and the
> corresponding actual parameter is omitted, then it is equivalent to an
> explicit actual parameter that is a usage name identical to the
> defining name of the formal. If a subtype_mark in the profile of the
> formal_subprogram_declaration denotes a formal private or formal
> derived type and the actual type for this formal type is a class-wide
> type T'Class, then for the purposes of resolving this default_name at
> the point of the instantiation, for each primitive subprogram of T
> that has a matching defining name, that is directly visible at the
> point of the instantiation, and that has at least one controlling
> formal parameter, a corresponding subprogram with the same defining
> name is directly visible, but with T systematically replaced by
> T'Class in the types of its profile. The body of such a subprogram is
> as defined in 12.5.1 for primitive subprograms of a formal type when
> the actual type is class-wide.

I tried to rewrite, but discovered that I did not understand the fine points of
the rule of the second sentence in the first place, which makes it hard to
propose better wording.

=================================

12.7 2/3  Formating: the aspect clause should not start a new line.

=================================

12.7. 4.1/3 and 4.2/2  It is rather unfortunate that the paragraph number of the
old 4.1/2 changed to 4.2/3. I suggest interchanging 4.1/2 and 4.2/3 to preserve
the numbering. The logic could be that the rules are stated in the order of the
productions.

=================================

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

From: Randy Brukardt
Sent: Friday, April 29, 2011 12:55 AM

> My review assignment...
> Erhard
>
> ==========================================
>
> 10.2.1. 11/3 and 17/3  see separate mail entitled "[ARG] technical
> issue of prelaborated and pure limited views"
> on these two paragraphs.

That begat its own AI, which eventually became AI05-0243-1. Hopefully we got
that right.

> ===========================================
>
> 11.1 2/3  Formating: the aspect clause should not start a new line.

Actually, that is the intended formatting for aspect clauses. At least, so says
Tucker, and we've informally agreed that is what we want to do. (We've never
discussed this at a meeting, though, only during one of the informal phone
calls.)

It's pretty much the only thing that would work for the syntax, because we can't
just add these to the end of the productions, most of them are way too long.

> ===========================================
>
> 11.4.1 10.1/3 penultimate sentence:
> > For an occurrence originally raised for some other reason, the
> > message is an unspecified string.
>
> lazy wording "for some other reason". In "if things-go-bump then raise
> fright; end if;"
> things-go-bump is the reason for the exception, not the raise
> statement.

Ugh, I suppose you are right.

> According to 11 2/3(2.sentence) only implicit raises are left. If
> indeed 9.5.2(24) is an extra case, 11 2/3 needs fixing, too, but
> presumably it is but a propagation and hence not an extra case.
> Footnote: I would prefer implementation-defined string. Oh well.

I don't quite buy this; anything that creates an occurrence has an
Exception_Message; it doesn't have to come from a raise of an exception. In
particular, it is possible to stream an occurrence, and I don't think the
language intended to require that the message is preserved unchanged. (Some
implementations truncate occurrences when they are copied or streamed; Janus/Ada
does that as the stack information could take up a huge amount of space
otherwise. Also, most exception messages are pointers (if static) until an
occurrence is copied; at that point the string has to be copied into the
occurrence [because we can't stream or do I/O on a pointer] and that truncates
it).

> Rewrite:
> -----
> For an occurrence originally raised by a language-defined check, the
> message is an unspecified string.

What about "new" occurrences from other source, at least WRT the current
program? The Ada 2005 wording definitely left that unspecified -- maybe it was
unintentional, but I don't want to change it without a full discussion (too late
for that now, I think). And the Adam question (in AI05-0043-1) seems legitimate;
9.5.2(24.b) says that this is a new occurrence; it is *not* considered
propagation. (Of course, AARM notes can be wrong, but it shows an intent.)

Indeed, I can't find anything that clearly says that propagation is required to
preserve the information in an occurrence. It seems like that should be said
somewhere. And I know that a reraise doesn't preserve an occurrence (at least in
Janus/Ada, it preserves parts of it, but it changes to reflect the reraise
location so that can be traced if necessary).

All-in-all, I don't think this is well-specified, and it hardly is worth
specifying much (do implementers really make these things useless because they
can?? I think it is more likely that they have a good reason for whatever they
do).

So, I'm making a minor tweak to this wording:

"For an occurrence originally raised in some other manner (including by the
failure of a language-defined check), the message is an unspecified string."

This isn't ideal, but this isn't worth a lot of effort, either.

> ===========================
>
> 12.1 3/3  Formating: the aspect clause should not start a new line.

Previously discussed.

> ==============================
>
> 12.4 2/3  Formating: the aspect clause should not start a new line.

Ibid.

> ==============================
>
> OLD BUG:
> 12.4. 5/2 Delete the spurious second period at the end of the para.

Got it.

> ==============================
>
> 12.5 2/3  Formating: the aspect clause should not start a new line.

As previous.

> =============================
>
> Before 12.5.3. Strange "NewPage" mistake in formatting.

The "NewPage"s were inserted to make the Ada 2005 RM look good. They'll need to
be moved for Ada 2012 when it is finished, but that is a last minute job --
there's not much point in messing with them now.

There's not a NewPage there, though, and I don't see anything weird in the
current RM draft. So I can't do anything here.

> ============================
>
> 12.6 2/3  Formating: the aspect clause should not start a new line.

Getting tired of seeing this one. :-)

> ============================
>
> 12.6. 10/3 is desperately in need of grammatical (and possibly
> conceptual) simplification. Also "this default_name" in the 2.
> sentence has no binding in the text at all.  The lead-in sentence
> talks about box not default_name.
>
> > If a generic unit has a subprogram_default specified by a box, and
> > the corresponding actual parameter is omitted, then it is equivalent
> > to an explicit actual parameter that is a usage name identical to
> > the defining name of the formal. If a subtype_mark in the profile of
> > the formal_subprogram_declaration denotes a formal private or formal
> > derived type and the actual type for this formal type is a
> > class-wide type T'Class, then for the purposes of resolving this
> > default_name at the point of the instantiation, for each primitive
> > subprogram of T that has a matching defining name, that is directly
> > visible at the point of the instantiation, and that has at least one
> > controlling formal parameter, a corresponding subprogram with the
> > same defining name is directly visible, but with T systematically
> > replaced by T'Class in the types of its profile. The body of such a
> > subprogram is as defined in 12.5.1 for primitive subprograms of a
> > formal type when the actual type is class-wide.
>
> I tried to rewrite, but discovered that I did not understand the fine
> points of the rule of the second sentence in the first place, which
> makes it hard to propose better wording.

Luckily, AI05-0131-1 undid these changes completely and put them into a separate
paragraph. Of course, it is twice as long and probably not much of an
improvement. :-) In any case, it absolves me of doing anything with this
comment.

> =================================
>
> 12.7 2/3  Formating: the aspect clause should not start a new line.

Grumble.

> =================================
>
> 12.7. 4.1/3 and 4.2/2  It is rather unfortunate that the paragraph
> number of the old 4.1/2 changed to 4.2/3. I suggest interchanging
> 4.1/2 and 4.2/3 to preserve the numbering. The logic could be that the
> rules are stated in the order of the productions.

This happens more often than you would think. I've been trying to ensure that
all renumbered paragraphs have /3 numbers even if they aren't themselves
changed. Beyond that, I don't think I want to go there -- this stuff is hard
enough to understand without reordering it to keep paragraph numbers the same.

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

From: Bob Duff
Sent: Thursday, September 30, 2010 11:52 AM

>...Reviews will need to be completed well before the next ARG meeting
>(by October 15th) ...

Review of new RM/AARM Chapter 13.

Thanks, Randy, for all your hard work on the new RM!

My main comment is that it's a shame that Chap 13, "Representation Issues", has
grown way beyond the low-level stuff it used to be about.  I wonder if it might
be worthwhile to move stuff like Pre/Postconditions earlier in the RM.  The
downside is that those rely on "aspect clauses", so there would be a forward
reference.

One possible solution would be to move aspect clauses earlier, too.
We can say their primary purpose is stuff like pre/post (and oh, by the way,
they can be used for Size clauses, too, but we don't mention that until chap
13).

Another solution would be to leave aspect clauses in chap 13, but move pre/post
(etc.) earlier.  An intro paragraph that hints at the syntax could alleviate the
forward reference problem:

    This section defines precondition and postcondition aspects
    for subprograms.  For example, a procedure can have
    "with Pre => _some_condition_" to place a requirement
    on callers.  Similarly, a procedure can indicate that
    it ensures some condition by having "with Post =>
    _some_condition_".

Not quite the normal RM style, but maybe for once we could place clarity above
the hobgoblin of little minds.  ;-)

----------------

Another point applies to the entire AARM.  I think there are way too many
"Wording Changes from..." paragraphs.

Reminder of history: Some reviewers of Ada 9X viewed the design team as a bunch
of loose cannons, making gratuitous changes all over.  (Maybe they were right,
maybe they were wrong, maybe some of both -- it's not my intent to re-debate
that!) The main purpose of the "Wording Changes from Ada 83" sections was to
(defensively) clarify that certain changes to the wording were not in fact
changes to the language, and therefore did not require implementation effort,
nor effort on the part of programmers to change their ways.

A secondary intent was to give rationale (e.g.: we're defining a new word
"elementary type", because we have a lot of new rules that involve those, and we
don't want to say "scalar or access" all over -- and it simplifies some existing
rule).

There was never any intent to document every wording change.
Only the potetially controversial ones, and ones that needed clarification.

In particular, if an entire feature is new, we don't need blather on about how
we added some definitions to support that feature's wording.

My point is: I suggest removing "Wording Changes from Ada 2005"
if they don't substantially add to understanding.  Note that the AI references
are always there for language lawyers who want to research the gory details of
such changes.

Examples of paragraphs that could be profitably removed:

    13.1(28.r/3-28.t/3)
    13.3(21.c.1/3)
    13.9.1(14.e/3)
    13.11(43.h/3-43.j/3)
    [Got tired of listing them.  Most of the ones in this
     chapter seem devoid of useful information.  And they
     have more than their fair share of typos...]

----------------

13.1(8/3): "Unless otherwise specified": I thought we had decided that the
aspect and pragma names always match (so it's "Pack", not "packing".

13.1(8.e.1/3): I suggest this para be deleted.  It's not really informative,
especially if pragma names match aspect names (as they should).

13.2(5): "A pragma Pack specifies the packing aspect of representation; the type
(or the extension part) is said to be packed." "A type (or extension part) with
the Pack aspect specified is said to be packed."

13.3(11.1/3): This is already covered by 13.3(13/3).

13.3(13/3): "and appropriate for the entity and its use"
adds nothing of value.

13.3(13.a): Same here.

13.3.1(6/3): "} )" --> "})".

13.3.1(11/3): "[ are" --> "[are".
"point" --> "place" (we don't normally talk about "points" in this sense, I
think). This notion of being resolved at a place (or point) seems overly
implementation oriented.  Seems like we should instead say something like "The
visibility of defining names in an aspect_definion is is as if it occured at the
end...".

13.3.1(12/3): Two occurrences of "visible" that I think should be "directly
visible". Not sure why "sub" is in parens in "(sub)type" (last word).

13.3.2(6/3): Doesn't fit in with 13.3.1(8/3), which is expecting us to define
the type of the aspect, not again define the expected type for the expression.

13.3.2(8/3): "independent of context" doesn't sound right.
"independently"?  Anyway, shouldn't we be talking about the "single type" notion
in 8.6(27/2)?

13.9.1(14.e/3):

    `Rosen trick"

has mismatched quotes.  Also "squirreling" --> "squirreling away"
Index entry for "squirrel away" should be updated.
I'd delete this entire para, though.

13.11(21.h/3): "which" --> "that"

13.11(43.i/3): "specify the" --> "specify that the".

13.11(43.j/3): "an allocators" singular or plural

13.11.2(19.b/3): "It hard" --> "It is hard"

13.12.1(2/2): Index entry refers to "_Pragmas_"; should be "_Attributes_".  (By
the way, this is the first time I EVER recall making use of those in-line index
"{...}" thingies!  Maybe they should be removed, even from the AARM.)

13.13.2(52/3): "]" appears at start of line.  Maybe you could fix all these by
doing a global search and making sure stray blanks don't sneak into the
@redundant command or whatever it is.

13.13.2(56.d/3): "which" --> "that"

13.14(15.e/3): One does not "go" through hoops; one "jumps" through them.

Whew!  That was a lot of work.

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

From: Randy Brukardt
Sent: Thursday, April  7, 2011  1:13 AM

Replies to the general part of this.

> Review of new RM/AARM Chapter 13.
>
> Thanks, Randy, for all your hard work on the new RM!

Buttering me up before lowering the hammer... ;-)

> My main comment is that it's a shame that Chap 13, "Representation
> Issues", has grown way beyond the low-level stuff it used to be about.

Blame that on the Ada 95 people who put the stream stuff into it. Those are not
that low-level, and they drove the creation of the idea of "aspects", and that
led to everything else.

> I wonder if it might be
> worthwhile to move stuff like Pre/Postconditions earlier in the RM.
> The downside is that those rely on "aspect clauses", so there would be
> a forward reference.

And aspects themselves...

> One possible solution would be to move aspect clauses earlier, too.
> We can say their primary purpose is stuff like pre/post (and oh, by
> the way, they can be used for Size clauses, too, but we don't mention
> that until chap 13).

The concept of aspects is introduced in 13.1; that would still be a major
forward reference. And all of their general semantics is also there. And moving
that too would be even more nasty.

> Another solution would be to leave aspect clauses in chap 13, but move
> pre/post (etc.) earlier.  An intro paragraph that hints at the syntax
> could alleviate the forward reference
> problem:
>
>     This section defines precondition and postcondition aspects
>     for subprograms.  For example, a procedure can have
>     "with Pre => _some_condition_" to place a requirement
>     on callers.  Similarly, a procedure can indicate that
>     it ensures some condition by having "with Post =>
>     _some_condition_".
>
> Not quite the normal RM style, but maybe for once we could place
> clarity above the hobgoblin of little minds.  ;-)

But all of the semantics of aspects is not there either. This isn't just about
aspect_specification syntax!!

I think you are right in that an overall revision of the standard would surely
move aspects much earlier and generalize the concept further. But we're *not*
doing such a revision.

So I don't think this is even a good idea. Maybe we'll be forced to do a full
revision for Ada 2020; then such reorganization would be a good idea. I'll put
it on the list of things to talk about tomorrow.

> ----------------
>
> Another point applies to the entire AARM.  I think there are way too
> many "Wording Changes from..." paragraphs.
>
> Reminder of history: Some reviewers of Ada 9X viewed the design team
> as a bunch of loose cannons, making gratuitous changes all over.
> (Maybe they were right, maybe they were wrong, maybe some of both --
> it's not my intent to re-debate
> that!) The main purpose of the "Wording Changes from Ada 83"
> sections was to (defensively) clarify that certain changes to the
> wording were not in fact changes to the language, and therefore did
> not require implementation effort, nor effort on the part of
> programmers to change their ways.
>
> A secondary intent was to give rationale (e.g.: we're defining a new
> word "elementary type", because we have a lot of new rules that
> involve those, and we don't want to say "scalar or access" all over --
> and it simplifies some existing rule).
>
> There was never any intent to document every wording change.
> Only the potetially controversial ones, and ones that needed
> clarification.

Right.

> In particular, if an entire feature is new, we don't need blather on
> about how we added some definitions to support that feature's wording.

Right, but we do need to document that it is an extension somewhere else. I've
repeatedly been asked why certain things are not documented as extensions, and
the answer is always that it is documented somewhere else -- and we don't want
to mark the same thing as an extension in dozens of places.

> My point is: I suggest removing "Wording Changes from Ada 2005"
> if they don't substantially add to understanding.  Note that the AI
> references are always there for language lawyers who want to research
> the gory details of such changes.

There is also another purpose to these: they tell the difference between Binding
Intepretations and Amendment class AIs. If I don't mention an AI either way,
then you can only tell by looking in the AI (which is tough for most people -
that don't have all of the AIs easily at hand - if you are not on line or not
using the HTML version).

This was added by popular request, and I had to add a lot of Wording Change
sections that I otherwise wouldn't have bothered with.

> Examples of paragraphs that could be profitably removed:
>
>     13.1(28.r/3-28.t/3)

Nope: We need the "correction" tags.

>     13.3(21.c.1/3)

I think this is a critical change; it's missing from earlier versions of the
standard.

>     13.9.1(14.e/3)

"Correction" tag again.

>     13.11(43.h/3-43.j/3)
>     [Got tired of listing them.  Most of the ones in this
>      chapter seem devoid of useful information.  And they
>      have more than their fair share of typos...]

The typos are because I have to write them without any help from anyone else.
And my view of English tends to be different than the textbooks would suggest.
;-)

-------------------

I'll do the specific part some day soon.

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

From: Randy Brukardt
Sent: Thursday, April 28, 2011 11:55 PM

The remainder of Bob's editorial review:
...
> 13.1(8/3): "Unless otherwise specified": I thought we had decided that
> the aspect and pragma names always match (so it's "Pack", not
> "packing".

We did decide that for existing language-defined aspects (long after this
wording was created), but of course there is no such requirement for future
aspects nor implementation-defined ones. It's close, but I think I'm going to
err on the side of making less work for myself and not change it.

> 13.1(8.e.1/3): I suggest this para be deleted.  It's not really
> informative, especially if pragma names match aspect names (as they
> should).

This is explaining why we require the pragma names to match aspect names.
Perhaps I didn't do a good job, but it seems worthwhile to mention it. The first
sentence is certainly true and important (if we didn't have this rule, we'd have
to give an aspect name explicitly for each pragma), and we don't want anonymous
aspects. The second sentence doesn't say much, so I got rid of it. The third
sentence really ought to talk about the aspecting naming for attributes.

> 13.2(5): "A pragma Pack specifies the packing aspect of
> representation; the type (or the extension part) is said to be
> packed."
> "A type (or extension part) with the Pack aspect specified is said to
> be packed."

This is rewritten by AI05-0229-1.

> 13.3(11.1/3): This is already covered by 13.3(13/3).

No it's not: this is a Legality Rule (it is illegal to take 'Address of such a
prefix). We don't want "erroneous execution" if we can help it. Similarly, this
raises Program_Error when it is used. (13/3 is only about specification of an
Address, not about use.)

> 13.3(13/3): "and appropriate for the entity and its use"
> adds nothing of value.
>
> 13.3(13.a): Same here.

Strongly disagree with this, and in any case you are directly contradicting the
approved AI. "Valid" has a technical meaning in Ada, and it is hard to imagine
an invalid address under that meaning. What this is really talking about is how
the address is used, not anything about its "validity". The only way to get the
intended meaning out of the original wording is to apply Robert's Rule, but it
is always better to fix the wording.

> 13.3.1(6/3): "} )" --> "})".

I think there is an automatic space after those index entries (there is no space
in the source); in any event, these don't appear in the RM, so they're
irrelevant.

> 13.3.1(11/3): "[ are" --> "[are".
> "point" --> "place" (we don't normally talk about "points" in this
> sense, I think).
> This notion of being resolved at a place (or point) seems overly
> implementation oriented.  Seems like we should instead say something
> like "The visibility of defining names in an aspect_definion is is as
> if it occured at the end...".

I think we changed this wording sometime since your review; it doesn't mention
point or place now.

> 13.3.1(12/3): Two occurrences of "visible" that I think should be
> "directly visible".
> Not sure why "sub" is in parens in "(sub)type" (last word).

I think you are right; I made all of these changes in AI05-0183-1.

> 13.3.2(6/3): Doesn't fit in with 13.3.1(8/3), which is expecting us to
> define the type of the aspect, not again define the expected type for
> the expression.

I agree, but I don't know how to define the type of the aspect to be "any
boolean type". So I think we have to repeat this here, either that or declare
that the aspect is Boolean and forget allowing other boolean types.

Other ideas welcome.

> 13.3.2(8/3): "independent of context" doesn't sound right.
> "independently"?  Anyway, shouldn't we be talking about the "single
> type" notion in 8.6(27/2)?

It currently says "independently". "Single types" are used to put requirements
on expected types (see 3.10.2(2/2) and 4.3.1(8/2)), but when there is an
expected type, we have already said what happens. I'm a bit dubious that there
is any case that needs to be resolved "independently of context", there would be
problems with the semantics of other parts of the language if there was any
expressions that don't have an expected type. So I think this is somebody doing
a CYA that isn't really needed. (But I'm not willing to change it without
additional guidance.)

> 13.9.1(14.e/3):
>
>     `Rosen trick"
>
> has mismatched quotes.  Also "squirreling" --> "squirreling away"
> Index entry for "squirrel away" should be updated.
> I'd delete this entire para, though.

Besides needing to carry the "Correction" tag to show that this is a BI (and
thus applies to Ada 2005 compilers), this is really a language extension. It
isn't classified as that, since the programs in question are legal but
erroneous.

> 13.11(21.h/3): "which" --> "that"

OK.

> 13.11(43.i/3): "specify the" --> "specify that the".

OK.

> 13.11(43.j/3): "an allocators" singular or plural

OK.

> 13.11.2(19.b/3): "It hard" --> "It is hard"

OK.

> 13.12.1(2/2): Index entry refers to "_Pragmas_"; should be
> "_Attributes_".  (By the way, this is the first time I EVER recall
> making use of those in-line index "{...}" thingies!
> Maybe they should be removed, even from the AARM.)

I do catch an indexing error occasionally by having them there, but they're much
more likely to make it hard to read changed text. So I won't miss them (but the
index quality will drop a bit).

> 13.13.2(52/3): "]" appears at start of line.  Maybe you could fix all
> these by doing a global search and making sure stray blanks don't
> sneak into the @redundant command or whatever it is.

Sometimes people bracket the redundant text like a change, including the spaces
needed for that text. It would be quite a bit of work to find those, and I'm
mainly concerned about the format of the RM (the AARM is a poor stepchild here).

> 13.13.2(56.d/3): "which" --> "that"

OK.

> 13.14(15.e/3): One does not "go" through hoops; one "jumps"
> through them.

OK.

> Whew!  That was a lot of work.

Same here! But somehow you managed to not make a single change that required me
to put anything into the Editorial Review AI. So it could have been a lot worse.
:-)

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

From: Edmond Schonberg
Sent: Thursday, October 14, 2010  3:52 PM

Most of the rivets on this boilerplate are perfectly in place.  Three nits:

A.1. (35/3)  The line containing soft_hyphen in the declaration for type Character
will have to be split

A.3.5 (28-50) : the end of each description for the classification functions is
inconsistent: sometimes ", otherwise return False.", at other times ". Otherwise
returns False."  In functions in Character.Conversion, only the True condition is given,
so maybe the "otherwise" can be omitted.

A.4.11 (47/3) : end of sentence:  "Wide_String of 16-bit containing.."  insert
"values" after "bit".

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

From: Randy Brukardt
Sent: Wednesday, April  6, 2011  10:33 PM

> Most of the rivets on this boilerplate are perfectly in
> place.  Three nits:
>
> A.1. (35/3)  The line containing soft_hyphen in the
> declaration for type Character will have to be split

Yes, I've added that to the AI.

> A.3.5 (28-50) : the end of each description for the
> classification functions is inconsistent: sometimes ",
> otherwise return False.", at other times ". Otherwise returns
> False."  In functions in Character.Conversion, only the True
> condition is given, so maybe the "otherwise" can be omitted.

This appears to have been addressed in the AI's editorial review. There
is still a minor difference: some of the longer ones are "; otherwise" rather
than ", otherwise", as there are already commas in the preceding text. I think
that's acceptable (and I don't want to mess around changing dozens of commas to
semicolons).

The old routines in Character.Conversions are wrong about this, they should
include ", otherwise returns False" as well. But we are not changing old text
unless we have some reason to change it otherwise. (Well, AdaCore *could* up my
grant by $5K, then I'd be happy to do it. :-)

> A.4.11 (47/3) : end of sentence:  "Wide_String of 16-bit
> containing.."  insert  "values" after "bit".

The original AI is correct on this, so looks like a mistake I somehow made in the
draft Standard. I'll just patch it up there.

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

From: John Barnes
Sent: Tuesday, April 19, 2011  5:14 AM

I am puzzled over some of the new string functions in AI-1. The Hashing ones all
with Ada.Containers. That;s OK because the type Hash is (sadly) declared
therein. But the string ones puzzle me.

Consider

The library function Strings.Equal_Case_Insensitive has the following
declaration:

function Ada.Strings.Equal_Case_Insensitive
  (Left, Right : String) return Boolean;
pragma Pure (Equal_Case_Insensitive);

Compares strings Left and Right, converted to lower case, for equality.

The library function Strings.Fixed.Equal_Case_Insensitive has the
following declaration:

with Ada.Containers, Ada.Strings.Equal_Case_Insensitive;
function Ada.Strings.Fixed.Equal_Case_Insensitive
   (Left, Right : String) return Boolean
   renames Ada.Strings.Equal_Case_Insensitive;
pragma Pure(Equal_Case_Insensitive);

The generic library function Strings.Bounded.Equal_Case_Insensitive has
the following declaration:

with Ada.Containers;
generic
   with package Bounded is
          new Ada.Strings.Bounded.Generic_Bounded_Length (<>);
function Ada.Strings.Bounded.Equal_Case_Insensitive
  (Left, Right : Bounded.Bounded_String) return Boolean;
pragma Preelaborate(Equal_Case_Insensitive);

Equivalent to Strings.Equal_Case_Insensitive (Bounded.To_String (Key));

Why does Fixed.Equal_Case_Insenstive have a with for  Ada.Containers? It's only
a renaming of the plain one which doesn't.

And what is the Bounded one to do with Key?

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

From: Randy Brukardt
Sent: Thursday, April 28, 2011  9:50 PM

Looks like sloppy cutting-and-pasting to me. But it's weird that nobody ever
read those very closely. I put fixes into the editorial review AI.

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

From: Gary Dismukes
Sent: Saturday, October 16, 2010  1:00 AM

Here are my review comments on sections 16-17, 18.7-18.10, and 19.

Have a good weekend. :-)

Section 16 (Directories)
----------

16(20.1/3): It would be nice to have better formatting for the enumeration type,
rather than having one literal pushed to the next line.  Perhaps the literals
could be put on a separate line or given in a column:

type Name_Case_Kind is
       (Unknown, Case_Sensitive, Case_Insensitive, Case_Preserving);

or

type Name_Case_Kind is (Unknown,
                        Case_Sensitive,
                        Case_Insensitive,
                        Case_Preserving);


16(82.2/3): The fourth sentence ("If file names that differ only...") seems a
little awkward wrt to wording about what's returned.  Specifically, I think that
the "otherwise" part should say something like "and Case_Insensitive {is
returned} otherwise").

Also, in that same sentence, in the phrase "then Case_Preserving is returned if
the name has the case of the file name used when a file is created", it's not
clear to me what the referent of "the name" is.  Presumably it's not referring
to the parameter Name.  I guess it's referring to some arbitrary name, but it
reads confusingly to me, though I think I understand what's intended.  Not sure
what to suggest for better wording though.


Section 16.1 (Directories.Hierarchical_File_Names)
------------

16.1(16/3): Change "useable" to "usable" (the more common spelling).

16.1(30/3): In the first sentence, "in" is improperly written in boldface.
Also, I suggest this change to the beginning of the second sentence:

  "That is{, it returns} a root directory name...".


Section 17 (Environment_Variables)
----------

Note: This section was assigned to me, though it hasn't changed as far as I can
tell.  While looking at it, I happened to notice the following minor formatting
nit:

17(8/2): Formatting: If the spec of Iterate won't fit on one line, it would at
least be nicer to move the "(" down to the next line. To me it looks ugly
hanging at the end of a line by itself.


Section 18 (Containers)
----------

This wasn't assigned to me, but I noticed an AARM typo:

In the AARM, 18(4.j/3) has a typo: "predicable" should be "predictable".


Section 18.7 (Sets)
------------

18.7(36.2/3): The wording of the Assign semantics for Sets is the same as for
other container Assign routines, but for Sets it doesn't sound right.  What does
"each element of Source is assigned to the corresponding element of Target" mean
in the case of a set?  The Target set might not have any "corresponding"
elements.  Also, if there's an element that is in the Target but not in the
Source, it sounds like that element would remain as is, but that surely is not
intended (one interpretation would be that the assign is like a union operator,
but that can't be right).

Perhaps it could say something like "Assign first clears Target, and then for
each element of Source, an equivalent element is inserted in Target."

18.7(96.1/3): Replace "to" with "of" in the phrase "tamper with elements of any
Set parameter [to] {of} the operation".


Section 18.8 (Containers.Hashed_Sets)
------------

18.8(75.1/3): In the semantics of Assign, it says "Reserve_Capacity is called
with the length of source...", but it doesn't say what set is passed to
Reserve_Capacity.  Obviously it should be Target, but that should be stated.

18.8(88.e/3): Remove extra 'that' ('...that that...')

The "Wording Changes from Ada 2005" section doesn't cover the changes due to
AI05-0001 (or is that OK because the "Incompatibilities with Ada 2005" section
covers it?).


Section 18.9 (Containers.Ordered_Sets)
------------

In the vicinity of 18.9(81.1/3) (spec for Copy), the semantic specification of
the new procedure Assign is missing.

18.8(116.e/3): Remove extra 'that' ('...that that...')

The "Wording Changes from Ada 2005" section doesn't cover the changes due to
AI05-0001 (or is that OK because the "Incompatibilities with Ada 2005" section
covers it?).


Section 18.10 (Containers.Multiway_Trees)
-------------

18.10(66/3): "Count (Empty_Tree)" should be "Node_Count (Empty_Tree)".

18.10(70/3): "Tree.Count-1" should be "Tree.Node_Count-1" (two places).
Also, I notice that the usual style is to use normal function call notation,
rather than prefix-call form (as in para. 66/3), so maybe this should be written
as "Node_Count (Tree) - 1"?

General editorial: There are a bunch of places in this section where calls are
written as Count rather than Node_Count, as well as Subtree_Count rather than
Subtree_Node_Count.  Those should be searched for and fixed.
  (e.g., paragraphs 90/3, 115/3)

18.10(74/3): "... that is, it calls the Splice_Subtree or Splice_Children
procedures {with T as a parameter}; ...".  (For consistency with other sentences
in the bulleted list.)

18.10(82/3): "... Left_Position is different [than] {from} the ..."
(The phrase "different from" is generally preferred to "different than".)

18.10(82/3): For added clarity I suggest the following addition to this
sentence: "If the result {of the element comparison} is False, the function
returns False."

18.10(92/3): Add a comma in "otherwise{,} Depth ...".
NOTE: In this section, there are several other cases of a leading "otherwise"
that should be followed by a comma (e.g., pp. 92/3, 104/3, 108/3, 117/3, 119/3,
167/3, ...).

18.10(94/3): "... designates the root node of [the] {some} tree; ..."

18.10(109/3): This sentence says that "the actual Element parameter of
Process.all shall be unconstrained".  I would have expected that sort of "shall"
paragraph to be in an "Implementation Requirements" paragraph, though I see that
this wording is used for other containers since Ada 2005, so there's precedent.
Anyway, I note that there's an AARM paragraph, such as the one for Vectors
(18.2(142.a/2)), that explains it, and I think it would be good to include that
paragraph here as well.

18.10(131/3): "... if the cursor designates [the] {a} root node ..."

18.10(153/3): Add a comma: "If Parent already has child nodes{,} then ..."

18.10(155/3): In the phrase "...; else the subtree rooted by ...", I suggest
replacing "else" with "otherwise,", for consistency with wording in other rules.
(It's also seems odd to start a sentence with "else", even if it does follow a
';'.  Another choice would be to change the semicolon to a comma.)

18.10(164/3): Add comma: "If Target_Parent already has child elements{,} then.."

18.10(165/3): Add comma: "If Target_Parent already has child elements{,} then.."

18.10(165/3): Add "the": "..., and {the} overall count of Source is decremented"

18.10(167/3): Add comma: "If Target_Parent already has child elements{,} then.."

18.10(195/3): The "in out" in the third sentence should be in boldface.


Section 19 (Locales)
----------

A.19(1/3): Add a hyphen: "... internationalization{-}related characteristics."

A.19(5/3): I wonder if the constant should be named "Language_Undetermined"
rather than "Language_Unknown", since the code "und" is short for undetermined.
Otherwise, it looks like a typo (I initially thought that "und" might be a typo
for "unk", until I googled ISO 639-3:-).

A.19(11/3): Add a comma: "... from the environment{,} then Language returns..."

A.19(12/3): Add a comma: "... from the environment{,} then Country returns..."


---(end of Draft 10 comments)---


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

From: Randy Brukardt
Sent: Wednesday, April  6, 2011  8:43 PM

> Here are my review comments on sections 16-17, 18.7-18.10, and 19.
...
> Section 16 (Directories)
> ----------
>
> 16(20.1/3): It would be nice to have better formatting for the
> enumeration type, rather than having one literal pushed to the next
> line.  Perhaps the literals could be put on a separate line or given
> in a column:
>
> type Name_Case_Kind is
>        (Unknown, Case_Sensitive, Case_Insensitive, Case_Preserving);
>
> or
>
> type Name_Case_Kind is (Unknown,
>                         Case_Sensitive,
>                         Case_Insensitive,
>                         Case_Preserving);

OK. I used the first, presuming it fits in the printed Standard.

> 16(82.2/3): The fourth sentence ("If file names that differ
> only...") seems a little awkward wrt to wording about what's returned.
> Specifically, I think that the "otherwise" part should say something
> like "and Case_Insensitive {is returned} otherwise").

OK.

> Also, in that same sentence, in the phrase "then
> Case_Preserving is returned if the name has the case of the
> file name used when a file is created", it's not clear to me
> what the referent of "the name" is.  Presumably it's not
> referring to the parameter Name.  I guess it's referring to
> some arbitrary name, but it reads confusingly to me, though I
> think I understand what's intended.  Not sure what to suggest
> for better wording though.

"the name has" -> "names have" to make it clear that it is talking about
names in general and not any specific name.

> Section 16.1 (Directories.Hierarchical_File_Names)
> ------------
>
> 16.1(16/3): Change "useable" to "usable" (the more common spelling).

This is just an RM-only typo, not some intentional funny spelling.

> 16.1(30/3): In the first sentence, "in" is improperly written
> in boldface.
> Also, I suggest this change to the beginning of the second sentence:
>
>   "That is{, it returns} a root directory name...".

OK. The first is a RM-only typo.

> Section 17 (Environment_Variables)
> ----------
>
> Note: This section was assigned to me, though it hasn't
> changed as far as I can tell.  While looking at it, I
> happened to notice the following minor formatting nit:
>
> 17(8/2): Formatting: If the spec of Iterate won't fit on one
> line, it would at least be nicer to move the "(" down to the
> next line.
> To me it looks ugly hanging at the end of a line by itself.

Also A.17(22/2). Ugh, but you are right that the Standard generally doesn't
format routines this way. Fixed.


> Section 18 (Containers)
> ----------
>
> This wasn't assigned to me, but I noticed an AARM typo:
>
> In the AARM, 18(4.j/3) has a typo: "predicable" should be
> "predictable".

Humm, this gave me a number of ideas what the original word might mean. That
told me it was time to go home for tonight. ;-)


> Section 18.7 (Sets)
> ------------
>
> 18.7(36.2/3): The wording of the Assign semantics for Sets is
> the same as for other container Assign routines, but for Sets
> it doesn't sound right.  What does "each element of Source is
> assigned to the corresponding element of Target" mean in the
> case of a set?  The Target set might not have any
> "corresponding" elements.  Also, if there's an element that
> is in the Target but not in the Source, it sounds like that
> element would remain as is, but that surely is not intended
> (one interpretation would be that the assign is like a union
> operator, but that can't be right).
>
> Perhaps it could say something like "Assign first clears
> Target, and then for each element of Source, an equivalent
> element is inserted in Target."

This problem has nothing to do with sets; it exists for almost all of the
containers. What is the "corresponding" element of an empty list or map? It
doesn't make much sense even for a vector: one might imagine that the
"corresponding" element is the one with the same index, but those aren't
accessible unless the length is changed.

Part of the problem is the "Set" as a container name brings with it baggage
which is not relevant to the containers. If you wanted to truly describe
these as sets, virtually all of the wording would need to be different than
the similar map container -- which would emphasize the minor differences
rather than the strong similarities.

If we're going to change any of them to use some other wording, then I think
we need to do that to all of them (all six containers use variations of this
wording). But I don't know how to do that for most of the containers (the
Tree version has far worse hand-waving than the Set - but you didn't
complain about that for some reason). But doing so seems to describe an
operation very different than ":=", while this operation is supposed to be
identical to ":=" other than for the bounded forms.

So I would rather find a way to describe this similarly to ":="; and what we
have seems to be the best way to do that.

I'll put this on the open item discussion list because I don't see a clear
response.

> 18.7(96.1/3): Replace "to" with "of" in the phrase "tamper
> with elements of any Set parameter [to] {of} the operation".

OK. Note that this wording exists in all of the base containers, so I
changed it in 6 places.

> Section 18.8 (Containers.Hashed_Sets)
> ------------
>
> 18.8(75.1/3): In the semantics of Assign, it says
> "Reserve_Capacity is called with the length of source...",
> but it doesn't say what set is passed to Reserve_Capacity.
> Obviously it should be Target, but that should be stated.

This also exists in all of the containers that have Reserve_Capacity. Didn't
anyone review this stuff?? (The answer is clearly no, unfortunately.)

I changed all of these to be much closer to the similar wording in Move:

"Reserve_Capacity (Target, Length (Source)) is called."

> 18.8(88.e/3): Remove extra 'that' ('...that that...')

OK. As a new AARM note, this just gets changed without marking.

> The "Wording Changes from Ada 2005" section doesn't cover the
> changes due to AI05-0001 (or is that OK because the
> "Incompatibilities with Ada 2005" section covers it?).

Yes, of course. "Wording Changes" sections are solely to talk about things
not covered in other "from Ada 2005" sections. And Bob would prefer fewer
"Wording Changes" sections, not more. If the wording changes are really
obvious, I'll not put one of these in at all. Their primary purpose is to
show the difference between "Binding Interpretations" and "Amendments"
anyway.

> Section 18.9 (Containers.Ordered_Sets)
> ------------
>
> In the vicinity of 18.9(81.1/3) (spec for Copy), the semantic
> specification of the new procedure Assign is missing.

As with all routines that are not changed from the "base" definition in
A.18.7, Assign is not mentioned here intentionally. There is nothing to say.

...

> Section 18.10 (Containers.Multiway_Trees)
> -------------
>
> 18.10(66/3): "Count (Empty_Tree)" should be "Node_Count (Empty_Tree)".

Ugh. The fairly last-minute change from Count to Node_Count was not made
consistently, because it is not possible to reliably search for Count (you
get hits from text and from Count_Type that should not be changed).

> 18.10(70/3): "Tree.Count-1" should be "Tree.Node_Count-1"
> (two places).
> Also, I notice that the usual style is to use normal function
> call notation, rather than prefix-call form (as in para.
> 66/3), so maybe this should be written as "Node_Count (Tree) - 1"?

OK. But I note that there are lots of places where we use the prefix-call
form (not so much in this clause). I'll change this clause, but I'm not
going to try to scrub the rest of A.18 for such uses.

> General editorial: There are a bunch of places in this
> section where calls are written as Count rather than
> Node_Count, as well as Subtree_Count rather than
> Subtree_Node_Count.  Those should be searched for and fixed.
>   (e.g., paragraphs 90/3, 115/3)

As noted above, searching for Count is not reliable. I've already done it at
least twice in the past (when it was changed, and when John reviewed it),
and obviously that is not working. There are more than 70 occurrences of
"Count" in this clause and the related ones! I'll fix what you mentioned
above (I can't find any others followed by "(") and the Subtype_Count cases,
but I don't see any reason to repeat failed tasks ("Count" proper). Please
tell me where you see problems in the future -- searching has proven over
and over to be unreliable. (It also doesn't help much because I still have
to record the paragraph number of the changes and make them in three or four
different places - searching and find only one occurrence makes things
worse, not better.)

> 18.10(74/3): "... that is, it calls the Splice_Subtree or
> Splice_Children procedures {with T as a parameter}; ...".
> (For consistency with other sentences in the bulleted list.)

OK.

> 18.10(82/3): "... Left_Position is different [than] {from} the ..."
> (The phrase "different from" is generally preferred to
> "different than".)

If you say so.

> 18.10(82/3): For added clarity I suggest the following
> addition to this
> sentence: "If the result {of the element comparison} is
> False, the function returns False."

OK on both.

> 18.10(92/3): Add a comma in "otherwise{,} Depth ...".

OK.

> NOTE: In this section, there are several other cases of a
> leading "otherwise"
> that should be followed by a comma (e.g., pp. 92/3, 104/3,
> 108/3, 117/3, 119/3, 167/3, ...).

Actually, most of these are copies of wording found elsewhere in the
containers section. (There are five copies of "Otherwise Replace_Element",
for instance). It's relatively easy to fix the ones in this clause, but the
others would be a major pain.
I don't think it makes sense to spend the effort to fix the others, and I
don't like the idea of making the wording in this clause different than the
rest of the standard.

What we could do is give you an action item to find all of the commas you
want fixed (in the *entire* standard), listing them all by paragraph number,
and then (presuming the rest of the ARG agrees) just fixing them without any
formal marked change. That's been done in other cases (capitalization of Id
foremost among them). But I need a list of changes in case anyone asks, and
I personally am not going to generate that...

I'll put this on the open issue list for future discussion.

> 18.10(94/3): "... designates the root node of [the] {some} tree; ..."

OK.

> 18.10(109/3): This sentence says that "the actual Element
> parameter of Process.all shall be unconstrained".  I would
> have expected that sort of "shall" paragraph to be in an
> "Implementation Requirements" paragraph, though I see that
> this wording is used for other containers since Ada 2005, so
> there's precedent.  Anyway, I note that there's an AARM
> paragraph, such as the one for Vectors (18.2(142.a/2)), that
> explains it, and I think it would be good to include that
> paragraph here as well.

OK, as an AARM change it will not appear in an AI.

> 18.10(131/3): "... if the cursor designates [the] {a} root node ..."

OK.

> 18.10(153/3): Add a comma: "If Parent already has child
> nodes{,} then ..."

OK. There are a number of these scattered about; you noticed some of them,
but I found some additional ones (some talk about "child elements" instead).
I presume that they all need to be changed the same way whether or not you
previously noted them.

> 18.10(155/3): In the phrase "...; else the subtree rooted by
> ...", I suggest replacing "else" with "otherwise,", for
> consistency with wording in other rules.
> (It's also seems odd to start a sentence with "else", even if
> it does follow a ';'.  Another choice would be to change the
> semicolon to a comma.)

OK.

...
> 18.10(165/3): Add "the": "..., and {the} overall count of
> Source is decremented"

OK.

> 18.10(195/3): The "in out" in the third sentence should be in
> boldface.

This is correct in the !corrigendum text, so it is just a formatting bug in
the RM - as such it won't appear in the AI.

> Section 19 (Locales)
> ----------
>
> A.19(1/3): Add a hyphen: "... internationalization{-}related
> characteristics."

OK.

> A.19(5/3): I wonder if the constant should be named
> "Language_Undetermined"
> rather than "Language_Unknown", since the code "und" is short
> for undetermined.
> Otherwise, it looks like a typo (I initially thought that
> "und" might be a typo for "unk", until I googled ISO 639-3:-).

I'm not qualified to answer this one (at the very least, Brad ought to
comment); I put it on the open issues list for tomorrow's call. I do think
if we change one, we need to change both "Language_Unknown" and
"Country_Unknown". Too confusing otherwise.

> A.19(11/3): Add a comma: "... from the environment{,} then
> Language returns..."
>
> A.19(12/3): Add a comma: "... from the environment{,} then
> Country returns..."

OK for both.

> ---(end of Draft 10 comments)---

Thank goodness; it's taken me parts of three days to deal with these...

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

From: Matthew Heaney
Sent: Monday, April 11, 2011  9:31 PM

I'm reading AI05-0136.  The first line of my copy says:

10-06-02    AI05-0136-1/07

Issue 1/3:

The description of:

    procedure Splice_Subtree (Container: in out Tree;
                              Parent   : in     Cursor;
                              Before   : in     Cursor;
                              Position : in     Cursor);


says:

(quote)

If Position equals No_Element or designates a root node, Constraint_Error is
propagated.

(end quote)

I think this might be incorrect.  I think the exception behavior should match
the description of:

    procedure Splice_Subtree (Target   : in out Tree;
                              Parent   : in     Cursor;
                              Before   : in     Cursor;
                              Source   : in out Tree;
                              Position : in out Cursor);


which states that:

(quote)

If Position equals No_Element, Constraint_Error is propagated. If Position does
not designate a node in Source or designates a root node, then Program_Error is
propagated.

(end quote)

The case I'm talking about is when Position designates the root node of the
tree.  In one case you get Constraint_Error, but in another you get
Program_Error.

Everywhere else in the API, if you attempt to manipulate the root, you get PE.
I think the case cited above that raises CE might be a bug in the spec, and PE
should be raised.

Issue 2/3:

Also, the description of:

    procedure Splice_Subtree (Container: in out Tree;
                              Parent   : in     Cursor;
                              Before   : in     Cursor;
                              Position : in     Cursor);


says:

(quote)

If Position equals Before, there is no effect.

(end quote)

This is true, but it's not the whole story, since if
Next_Sibling(Position) = Before, there would be no effect either.

You do make this distinction in the description of the two-container version of
Splice_Subtree (as an AARM Ramification), so it appears that it was accidentally
omitted from the single-container version.  (Unless the omission was
deliberate.)

Issue 3/3:

The description of:

    procedure Insert_Child (Container : in out Tree;
                            Parent    : in     Cursor;
                            Before    : in     Cursor;
                            New_Item  : in     Element_Type;
                            Position  :    out Cursor;
                            Count     : in     Count_Type := 1);

states that:

(quote)

Position designates the first newly-inserted node.

(end quote)

The issue here is what value does Position have when Count is 0.  I think it
should have the value No_Element, which is what we decided in York about the
behavior of Delete for the doubly-linked list.

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

From: Randy Brukardt
Sent: Saturday, April 30, 2011  1:02 AM

...
> Issue 1/3:
>
> The description of:
>
>     procedure Splice_Subtree (Container: in out Tree;
>                               Parent   : in     Cursor;
>                               Before   : in     Cursor;
>                               Position : in     Cursor);
>
>
> says:
>
> (quote)
>
> If Position equals No_Element or designates a root node,
> Constraint_Error is propagated.
>
> (end quote)
>
> I think this might be incorrect.  I think the exception behavior
> should match the description of:
...
> The case I'm talking about is when Position designates the root node
> of the tree.  In one case you get Constraint_Error, but in another you
> get Program_Error.
>
> Everywhere else in the API, if you attempt to manipulate the root, you
> get PE.  I think the case cited above that raises CE might be a bug in
> the spec, and PE should be raised.

I agree, just looks like an oversight to me.

> Issue 2/3:
>
> Also, the description of:
>
>     procedure Splice_Subtree (Container: in out Tree;
>                               Parent   : in     Cursor;
>                               Before   : in     Cursor;
>                               Position : in     Cursor);
>
>
> says:
>
> (quote)
>
> If Position equals Before, there is no effect.
>
> (end quote)
>
> This is true, but it's not the whole story, since if
> Next_Sibling(Position) = Before, there would be no effect either.

We don't need to save that normatively; we do need to say the above normatively.

> You do make this distinction in the description of the two-container
> version of Splice_Subtree (as an AARM Ramification), so it appears
> that it was accidentally omitted from the single-container version.
> (Unless the omission was
> deliberate.)

I think it was deliberate; we didn't repeat the AARM notes in general (too much
clutter), and the single container version is just a restricted version of the
other one.

We need to mention the case when Position = Before, since it isn't possible to
insert a node before itself (and someone is sure to ask what it means if we
don't spell it out). OTOH, we don't need to mention the other case since it
falls out "naturally": inserting a node into the position it already has is
harmless.

Note that there is some missing wording in the Source/Target version of
Splice_Subtree; specifically part of the Position = Before wording. So we need
to modify this wording:

"If Source denotes the same object as Target, then{: if Position equals Before
there is no effect; if Position designates an ancestor of Parent or is equal to
Parent, Constraint_Error is propagated; [else]{otherwise}, ..." [The last is
from Gary's editorial review; the colon is needed to avoid ambiguity in the
following.]

> Issue 3/3:
>
> The description of:
>
>     procedure Insert_Child (Container : in out Tree;
>                             Parent    : in     Cursor;
>                             Before    : in     Cursor;
>                             New_Item  : in     Element_Type;
>                             Position  :    out Cursor;
>                             Count     : in     Count_Type := 1);
>
> states that:
>
> (quote)
>
> Position designates the first newly-inserted node.
>
> (end quote)
>
> The issue here is what value does Position have when Count is 0.  I
> think it should have the value No_Element, which is what we decided in
> York about the behavior of Delete for the doubly-linked list.

I don't see what Delete has to do with anything; it always sets the Position to
No_Element (the Count is irrelevant).

And there is no answer to this question in the linked list Inserts that have out
Position parameters, either (the wording for these Tree routines was lifted
directly from the linked list wording). (There is an answer for the vector, at
least, and neither Maps nor Sets have these Count parameters.)

My preference for the semantics of this is to raise Constraint_Error. It doesn't
make sense to ask to insert no elements and at the same time expect to get a
cursor back of the inserted element. (As you would say, any other result would
violate the postcondition of the routine that Position points at the first
inserted element - that seems bad.)

(I'm surprised that any of these Count parameters allow zero, but it is too late
to change that.)

So I added "; if Count is zero, Constraint_Error is propagated." to each of
these. (We could also define a Positive_Count_Type subtype, but that seems to be
overkill for this very isolated case, and it would be [slightly] incompatible
for the existing List routines.)

[Editor's Note: Later discussion cast doubt on this solution; it has been put
into a separate AI.]

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

From: Matthew Heaney
Sent: Tuesday, April 12, 2011  9:42 PM

I see that Iterate_Children (and also Reverse_Iterate_Children) is declared this
way:

    procedure Iterate_Children
      (Container : in Tree;
       Parent    : in Cursor;
       Process   : not null access procedure (Position : in Cursor));

The Container parameter does not seem to serve any obvious purpose.
Is the Container parameter there by mistake?  Is this is a bug in the spec?

It seems odd that Iterate_Subtree does not accept a Container parameter, yet
Iterate_Chlidren does.

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

From: Randy Brukardt
Sent: Friday, April 29, 2011  1:51 AM

I suppose it is a mistake, probably the regular Iterate was copied to create
this one. (I think this was added fairly late during the design.) I've removed
it and the associated wording.

Humm, Find_in_Subtree and Ancestor_Find seem to have the same problem. (Your
question about Ancestor_Find couldn't have happened if that routine didn't have
a Container parameter.)

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

From: Matthew Heaney
Sent: Friday, April 29, 2011  1:22 PM

Right, I meant to post about those too, but wasn't sure this was the proper
forum (I can use Ada-Comment if you prefer).

So did the wording in the AI for Iterate_Children, Find_In_Subtree,
Ancestor_Find, etc, get changed, to remove the Container parameter?

BTW, Is this the link for the document I should work from:

http://ada-auth.org/standards/ada12.html

instead of using the AI itself?

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

From: Randy Brukardt
Sent: Friday, April 29, 2011  1:42 PM

> Right, I meant to post about those too, but wasn't sure this was the
> proper forum (I can use Ada-Comment if you prefer).

Either is fine.

> So did the wording in the AI for Iterate_Children, Find_In_Subtree,
> Ancestor_Find, etc, get changed, to remove the Container parameter?

Yes. (Pending ARG approval, of course, but I'd be surprised if anyone
objects.)

> BTW, Is this the link for the document I should work from:
>
> http://ada-auth.org/standards/ada12.html
>
> instead of using the AI itself?

Yes, this is the most recent state of the Standard. Note that it would best to
work from Draft 12, but it isn't available yet (I've still got 20 AIs to add to
it). If an AI isn't in the Standard, then you should look at it, but I believe
that all of the old containers AIs are in Draft 11 (some corrections are new,
those are in AI05-0248-1 if you need to see them).

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

From: Matthew Heaney
Sent: Wednesday, April 13, 2011  2:17 PM

The description of

    function Ancestor_Find (Container : Tree;
                            Item      : Element_Type;
                            Position  : Cursor)
       return Cursor;

says:

(quote)

If Position equals No_Element, then Constraint_Error is propagated; if Position
does not designate an element in Container (including if it designates the root
node), then Program_Error is propagated.

(end quote)


That parenthetical bit about raising Program_Error if Position designates the
root node seems wrong.  Shouldn't the function return No_Element in that case?

We search for Item starting from the Position, up to each successive ancestor
node, stopping when we reach the root node.  If we reach the root node, then the
search terminates by returning No_Element.

But if Position happens to have the root node as its initial value, then this is
just the limiting case of the search.  Raising PE seems wrong in this case.

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

From: Randy Brukardt
Sent: Friday, April 29, 2011  1:37 AM

I wouldn't call it "wrong", but unnecessary would probably be true. The intent
was that we raise Program_Error if we pass a cursor that designates the root
node if we are going to operate on the contained element. This routine is a bit
weird that way; I suspect that I assumed that there had to be at least one
element searched. But as you point out, that doesn't seem necessary.

So I changed the first sentence (but *not* in AI05-0136-1, that's closed; it's
done in AI05-0248-1) to the other normal wording: "If Position equals
No_Element, then Constraint_Error is propagated; if Position does not designate
a node in Container, then Program_Error is propagated." I also changed the
starting point from "element" to "node" (since there might not be an element).


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

From: Steve Baird
Sent: Monday, April 18, 2011  6:29 PM

> AI05-0248-1 Propose a rewording of the Assign routines for the
> containers (there are 6) that does not use "Corresponding Elements".
> (This probably will be placed in a new AI.)

Here's another attempt,
   -- Steve


!wording

In A.18.2(147.2/3) [describing Vector procedure Assign], replace

   Each element of Source is assigned to the corresponding element
   of Target.

with

   The elements of Source are then copied to Target as for an
   assignment_statement assigning Source to Target (this includes
   setting Target's length to be that of Source).

====

In A.18.3(86.2/3 [describing Doubly_Linked_Lists procedure Assign], replace

    Otherwise, it clears Target, and each element of Source is assigned
    to the corresponding element of Target.

with

    Otherwise, the elements of Source are copied to Target as for an
    assignment_statement assigning Source to Target.

====

In A.18.4(41.2/3) [describing Maps procedure Assign], replace

    Otherwise, each key/element pair of Source is assigned to the
    corresponding key/element pair of Target.

with

    Otherwise, the key/element pairs of Source are copied to Target as
    for an assignment_statement assigning Source to Target.

====

In A.18.7(36.2/3) [describing Sets procedure Assign], replace

    Otherwise, each element of Source is assigned to the
    corresponding element of Target.

with

    Otherwise, the elements of Source are copied to Target as
    for an assignment_statement assigning Source to Target.

====

In A.18.10(111/3) [describing Multiway_Trees procedure Assign], replace

    Otherwise, it calls Clear (Target), and then each element of Source
    is assigned to a corresponding element in Target.

with

    Otherwise, the elements of Source are copied to Target as
    for an assignment_statement assigning Source to Target.


====

Note: the existing wording for the Honey_Pot generic (A.18.18) needs no changes.

Question: In the vector case, do we want the parenthetical "this includes ..."
verbiage? It didn't seem necessary to add analogous text in the other cases.

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


From: Jean-Pierre Rosen
Sent: Tuesday, September 21, 2010  5:07 AM

> Here are the assignments:
>             Jean-Pierre Rosen       A.5-A.15; A.18.17-A.18.26

Here is my homework:

A.18.17(7/3) made me look at A.18.10(109/3) which says: "if element_type is ...
definite", which is a bit strange since Element_Type is necessarily definite.

A.18.18(45/3): shouldn't the Container parameter to Update_Element be "in out"?
although it can be implemented as "in" because of hidden pointers, other
containers have it as "in out" (and it is logically "in out").

A.18.18(48/3) says "If Target denotes the same object as Source, the operation
has no effect", while A.18.18(52/3) says "If Target denotes the same object as
Source, then Move has no effect". They should use the same formula (no personal
preference). A.18.10 seems to have the same kind of inconsistency.

A.18.18(58.a/3) alludes to a documentation requirement, but there is no such
thing.

A.18.19(12/3) says: "(note that distinct elaborations of a type declaration
result in distinct types)". This has nothing to do in normative text.

A.18.20(11/3): otherwise, the operation propagate[d]{s} Capacity_Error (or
better: "otherwise, Capacity_Error is propagated", but same change needed to
12/3 and 13/3)

A.18.20(16/3): same remark as A.18.19(12/3)

A.18.21(17/3): same remark as A.18.19(12/3)

A.18.22(14/3): same remark as A.18.19(12/3)

A.18.23(17/3): same remark as A.18.19(12/3)

A.18.24(14/3): same remark as A.18.19(12/3)

A.18.25(16/3): same remark as A.18.19(12/3)

A.18.26(9.3/3) says that "The generic formal Before compares the elements having
the given indices", but does not explicitely say that it returns True if Left is
to be sorted before Right.

A.18.26: there is no implementation advice pertaining to
Containers.Generic_Sort. Shouldn't it also be O(N**2)? And shouldn't it say that
the number of calls to Swap should be minimized ?

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

From: Randy Brukardt
Sent: Tuesday, April  5, 2011  12:32 AM

> Here is my homework:
>
> A.18.17(7/3) made me look at A.18.10(109/3) which says: "if
> element_type is ... definite", which is a bit strange since
> Element_Type is necessarily definite.

Right, but that is consistent with the other containers. A.18.2(142/2),
A.18.3(86/2), A.18.4(41/2), and many more say the same thing. I suspect that it
is foreshadowing for the rule here.

So I'm not going to make a change.

> A.18.18(45/3): shouldn't the Container parameter to Update_Element be
> "in out"?  although it can be implemented as "in" because of hidden
> pointers, other containers have it as "in out" (and it is logically
> "in out").

Yes, that's clearly a bug. Operations that modify a container always have an "in
out" container parameter, whether it needs that mode or not.

> A.18.18(48/3) says "If Target denotes the same object as Source, the
> operation has no effect", while A.18.18(52/3) says "If Target denotes
> the same object as Source, then Move has no effect". They should use
> the same formula (no personal preference). A.18.10 seems to have the
> same kind of inconsistency.

Sure wish you had noticed that a long time ago. All of the newly added Assign
routines have this wording. And all of the Move routines have this wording as
well. So I have to redo all of one of them (I chose Move, since we had already
decided to remove other examples of "Move" in them). Grumble.

> A.18.18(58.a/3) alludes to a documentation requirement, but there is
> no such thing.

Implementation Advice always requires documenting when you don't follow it. (See
Annex M.3.) So there is a documentation requirement.

> A.18.19(12/3) says: "(note that distinct elaborations of a type
> declaration result in distinct types)". This has nothing to do in
> normative text.

You are quite right. Again, it's annoying that no one caught it sooner, given
that it appears in a half dozen or so places. Sigh.

> A.18.20(11/3): otherwise, the operation propagate[d]{s} Capacity_Error
> (or better: "otherwise, Capacity_Error is propagated", but same change
> needed to 12/3 and 13/3)

It wouldn't be better that much better, as there are plenty of uses of
"propagates" throughout A.18. Admittedly, "propagated" is used much more, but it
doesn't seem worth trying to reword 20+ paragraphs to get rid of this use.

Also, this is a typo just in the draft RM; the AI and Amendment document are
correct.

...
> A.18.26(9.3/3) says that "The generic formal Before compares the
> elements having the given indices", but does not explicitely say that
> it returns True if Left is to be sorted before Right.

None of the sorting routines really say that, although the "<" ones say
something about "smallest first", which I suppose is slightly more information.

I added "; Before should return True if Left is to be sorted before Right." here
and in the Queue containers (which also use Before). Not at all sure that that
is appropriate wording, but I don't have any ideas.

> A.18.26: there is no implementation advice pertaining to
> Containers.Generic_Sort. Shouldn't it also be O(N**2)? And shouldn't
> it say that the number of calls to Swap should be minimized ?

I think so; I added similar sentences to A.18.26(10-11/2). (Neither can be
exactly the same, 10/2 talks about "the Container" and 11/2 talks about copying
rather than calls to Swap.)

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

From: Jean-Pierre Rosen
Sent: Tuesday, April  5, 2011  1:05 AM

> Sure wish you had noticed that a long time ago.
...
> You are quite right. Again, it's annoying that no one caught it
> sooner,
...
I guess it shows the value of having several reviews with different reviewers!

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

From: Randy Brukardt
Sent: Tuesday, April  5, 2011  2:03 AM

...
> I guess it shows the value of having several reviews with
> different reviewers!

Yup, which is why we're going to do at all again next month. Not that I'm
looking forward to dealing with more detailed reviews...

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

From: Bob Duff
Sent: Thursday, September 30, 2010 11:53 AM

> I'm starting to work on the review assignments for the upcoming
> RM/AARM review. This will be an overall review of the consolidated
> RM/AARM for problems. Reviews will need to be completed well before
> the next ARG meeting (by October 15th) so that any major problems
> uncovered can be put on the agenda for that meeting.

Review of new RM/AARM Annex B.

B.3(62.2/3): "which" --> "that"

Sorry -- I couldn't find any real problems with this Annex.  ;-)

General comment:  The changes are marked by color.  Maybe I missed it, but I
didn't see a description of which color means what.  Would be good to have that
in an early place. Seems like:

    pink -- corrigendum (i.e. "Ada 95 and a half")
    blue -- Ada 2005
    orange -- Ada 2012

When I print it out, pink and orange are nearly indistinguishable to my poor
eyesight (although I can see it on the screen). Could you pick a different color
for pink or orange?

Better yet: why do we need to keep all this detailed history?  The "/n"
paragraph numbers contain the info if it's really needed.  How about everything
in black, with Ada 2012 changes in blue or green?  (Pink and orange are pretty
garish, especially when it fills an entire page.)

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

From: Bill Thomas
Sent: Saturday, October 16, 2011  11:35 AM

My comments on A.18.27 -> A.18.32:

A.18.28, 3/3: This is the unbounded synchronized queue, so the Capacity discriminant
in the type isn't needed

A.18.30, 3/3: same comment, as this is the unbounded case for priority queues.

A.18.30, 16/3: I suggest moving this sentence to appear before the descriptions of
the Enqueue and Dequeue functions (i.e., right after 13/3)

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

From: Randy Brukardt
Sent: Wednesday, April  6, 2011  9:11 PM

...
> My comments on A.18.27 -> A.18.32:
>
> A.18.28, 3/3: This is the unbounded synchronized queue, so
> the Capacity discriminant in the type isn't needed

I don't see this in the current version; perhaps it was already fixed.

> A.18.30, 3/3: same comment, as this is the unbounded case for
> priority queues.

This only appears in the RM, not the Amendment, so I'll fix it but it won't appear
in the AI.

> A.18.30, 16/3: I suggest moving this sentence to appear
> before the descriptions of the Enqueue and Dequeue functions
> (i.e., right after 13/3)

Good idea, done.

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

From: Christoph Grein
Sent: Tuesday, April 5, 2011  4:49 AM

Generally the term "nonstandard" is used, also in the index. However at the
following places, "non-standard" is used:

3.5.2(9.n/2)
A.3.2(60.e/2)
D.1(29)

I think it should be replaced, especially so since "non-standard" is not in the index.

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

From: Alan Burns
Sent: Friday, October 8, 2010  9:03 AM

My reading of Annex C and D only generated two code layout typos

Code in D.2.1 (1.2/3 etc) has a slight alignment problem

D.13.1 4/2, last line of pragma Restrictions looks wrong, perhaps this line is too
long to fit, if so it would look better if the full column is moved to the left until
it does fit.

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

From: Randy Brukardt
Sent: Wednesday, April 6, 2011  9:59 PM

...
> My reading of Annex C and D only generated two code layout typos
>
> Code in D.2.1 (1.2/3 etc) has a slight alignment problem

Just in the standard draft, so I've fixed it there without mentioning it in any AI.

> D.13.1 4/2, last line of pragma Restrictions looks wrong, perhaps this
> line is too long to fit, if so it would look better if the full column
> is moved to the left until it does fit.

It looks like it should have fit, but obviously it didn't. I've just changed the
indentation a bit; I'm supposed to move this entire clause and when that is done
the correction will get made in the new version.

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

From: Brad Moore
Sent: Saturday, October 2, 2010  2:57 PM

>            Brad Moore              Annex E-F, Annex H through Q

My comments are:

10.2.1 defines "program" as a set of partitions
10.2.2 defined "partition" as a program or part of a program.

These definitions are a bit circular. Is that OK?
I think the intent is that a program must consist of at least one partition,
perhaps thats not clear here.

10.2.1(11.2/3)

• {AI05-0028-1} The partial view of a private type or private extension, a
protected type without entry_declarations, a generic formal private type, or a
generic formal derived type, has preelaborable initialization if and only if the
pragma Preelaborable_Initialization has been applied to {the partial
view}[them].

"them" is plural, yet the subject is singular.


E.2.2(14.1/3) “implementation  kind” => “implementation kind” (i.e., only one
space instead of two.)


E.2.2(14.1/3) Feels like there should be an explanation here. (Either an AARM
note, or a note) Why is "By_Any" only allowed for implementation_kind? I believe
this is discussed in the AI, but would not be obvious to readers of the RM.


E 2.2(20.b/2) “The wording was changed from “user-specified” to “available”
{Read and Write} attributes”

E 2.3(20.b/2) “The wording was changed from “user-specified” to “available”
{Read and Write} attributes”

E.3 (1.a) “The rules guarantee that remote call interface and shared library
[packages]{library units} ...”

E.4 (7/3) States that Remote Types and RCI library units define the remote
subprograms used for remote subprogram calls. Shared Passive library units also
define remote subprograms, and pure declared library units can also be used for
this purpose. Shouldn't these be mentioned here also?

I think this ties into
22.d/3{AI05-0101-1} Correction: Corrected the text to note that remote access
types can be defined in remote types units.

I think the intent may have been that E.4(7/3) was modified so that remote
access types can be defined in remote types units, but I don't think the wording
changes accomplishes that.


E.5(21.a) “[It is defined by tbe]{The} PCS implementation {defines} whether”


F.3.2(73) {Result: }”bbb$***123,456.78”


F.3.5(6.a/2) [(Shouldn't it have been “Widest_Text_IO.Editing”? :-)]


H.4(24) No_Unchecked_Deallocation, No_Unchecked_Conversion, are obsolescent (See
J.13) Should they still be mentioned here? Should the Restriction that replaced
these, No_Dependence, be mentioned here as well, or instead? I would think it
would be difficult for a compiler to support the No_Dependence for arbitrary
packages to be eliminated from the run time.


I note that AI05-189 No_Allocators_After_Elaboration will impact this section of
the RM, however I presume it is not showing up in the RM yet, because the AI
needs more work, and has not made its way to WG9 approval yet.


J.2 (5.e) “is not legal in Ada 83, nor will it be in Ada 95.” This should be
revised, it suggests Ada95 does not exist yet, and doesn't explain the situation
for Ada 2005, Ada 2012, or the future.


K(95/3) “{S'Class'Input first}[First] reads the external tag from Stream....”
This sentence is missing a subject.

“... and then dispatches to the subprogram denoted by the Input attribute of

the specific type identified by the internal tag[;]{and subsequently} returns
that result.”


K(168/2) “{S'Class'Output first}[First] writes the external tag....” This
sentence is missing a subject.

K(194) “{S'Class'Read dispatches}[Dispatches]”


K(273/2), K(277.4/2) Why was “image” changed from italicized to non-italicized
in K(273/2), but left as italicized in K(277.4/2)? Also, “that is, a sequence of
characters representing the value in display form.” was deleted from the first
paragraph, but left intact in the second paragraph? Why the inconsistency?


K(285) “S'Class'Write dispatches[Dispatches]”


L(39.a) We have wording changes from Ada 83, but nothing since, yet there have
been numerous other changes from Ada 95, Ada 2005, and Ada 2012. Should these be
mentioned here? Annex K for instance doesn't mention any wording changes.


M(1/2) “The Ada language allows for certain target machine dependences {to
exist} in a controlled manner.” Sentence doesn't read well without addition.

M.1  It seems surprising, (and questionable) that there have been no new
documentation requirements added to this section for Ada 2012. Are we confident
that none should have been added?

e.g. Barrier_Limit in Ada.Synchronous_Barriers is missing, though perhaps this
should not be mentioned here, but mentioned in M.2 instread (to be consistent
with where System.Multiprocessors.CPU_Range was added). In any case, it is
missing.


M.2 Similarly, I would have thought there might be more additions than
indicated.


M.3(12/2) Doesn't read well, then sentence appears to be missing a subject.


M.3 (84/2) (86/2) (87/2) (88/2) seems to be redundant with M.3(116/2), (118/2)


N (26) says “A program may contain just one partition.” Can it be zero
partitions? Wouldn't it be more accurate to say; “A program must contain at
least one partition.”?


P (6.1) parameter_specification, should be a space between [aliased]mode


P (7.1) Says package specifications can have aspect specifications. AI 183 says
this also, but gives no examples of use. Has this been specified well enough?
For example, what does precondition, postconditions mean for a package
specification. When are they executed? The rules appear to be covered by
13.3.1(13/3) "Other rules are not defined at this time."


Q.3(Language Defined Subprograms) I note that Language and Country from
Ada.Locales does not show up here. Also Number_Of_CPUs from
System.Multiprocessors is missing. Should there be a scrub through all the new
packages to verify that all the new subprograms have been added?

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

From: Randy Brukardt
Sent: Thursday, April  7, 2011 12:51 PM

...
> >            Brad Moore              Annex E-F, Annex H through Q
> My comments are:
>
> 10.2.1 defines "program" as a set of partitions
> 10.2.2 defined "partition" as a program or part of a program.
>
> These definitions are a bit circular. Is that OK?
> I think the intent is that a program must consist of at least one
> partition, perhaps thats not clear here.

This is probably not the best definition. But it is not something that was
changed in Ada 2012, it doesn't seem very important, and trying to redefine this
is more likely to introduce bugs than fix anything. So I'm inclined not to
change anything. You're welcome to bring it up at the phone meeting or by a
formal request on the ARG list if you think it is worth addressing.

> 10.2.1(11.2/3)
>
> • {AI05-0028-1} The partial view of a private type or private
> extension, a protected type without entry_declarations, a generic
> formal private type, or a generic formal derived type, has
> preelaborable initialization if and only if the pragma
> Preelaborable_Initialization has been applied to {the partial
> view}[them].
>
> "them" is plural, yet the subject is singular.

This change is clearly wrong, since "them" is saying that the pragma can be
applied to all four of the previous things. In any case, AI05-0229-1 totally
rewrites this part of the standard, so this is OBE.

> E.2.2(14.1/3) “implementation  kind” => “implementation kind”
> (i.e., only one space instead of two.)

That's "implementation_kind", that is, that is an underscore, not a space.
That's hard to see in RM versions that show insertions and deletions.

> E.2.2(14.1/3) Feels like there should be an explanation here.
> (Either an AARM note, or a note) Why is "By_Any" only allowed for
> implementation_kind? I believe this is discussed in the AI, but would
> not be obvious to readers of the RM.

This sentence should be changed by AI05-0215-1, of course (there is no pragma
Implemented anymore), but it doesn't seem to be. I've put it on my discussion
issues for tomorrow. Adding an AARM Reason seems reasonable, adding a user Note
is over the top.

> E 2.2(20.b/2) “The wording was changed from “user-specified”
> to “available” {Read and Write} attributes”
>
> E 2.3(20.b/2) “The wording was changed from “user-specified”
> to “available” {Read and Write} attributes”

As AARM notes, these don't show up in the Amendment document.

> E.3 (1.a) “The rules guarantee that remote call interface and shared
> library [packages]{library units} ...”

"library library"? :-)
Same note as above.

> E.4 (7/3) States that Remote Types and RCI library units define the
> remote subprograms used for remote subprogram calls. Shared Passive
> library units also define remote subprograms, and pure declared
> library units can also be used for this purpose. Shouldn't these be
> mentioned here also?

No, those aren't "remote access types" or "remote subprograms", those things
have formal definitions. An access type declared in a pure unit is surely not a
remote access type or remote subprogram (indeed, I think such packages are
supposed to be replicated, so there is nothing remote going on there).

> I think this ties into
> 22.d/3{AI05-0101-1} Correction: Corrected the text to note that remote
> access types can be defined in remote types units.
>
> I think the intent may have been that E.4(7/3) was modified so that
> remote access types can be defined in remote types units, but I don't
> think the wording changes accomplishes that.

The formal definition of a remote access type is an access type declared in a
remote types package. E.2.1(9/3)! Someone pointed out that this statement didn't
include the source of remote access types, which seemed wrong. But those don't
come from other kinds of packages.

> E.5(21.a) “[It is defined by tbe]{The} PCS implementation {defines}
> whether”

Ancient history and insufficiently broken.

> F.3.2(73) {Result: }”bbb$***123,456.78”

OK.

> F.3.5(6.a/2) [(Shouldn't it have been “Widest_Text_IO.Editing”? :-)]

Sorry, you don't get to remove the editor's jokes. If I tried to remove Bob's
jokes, I *know* I'd be in trouble.

> H.4(24) No_Unchecked_Deallocation, No_Unchecked_Conversion, are
> obsolescent (See J.13) Should they still be mentioned here? Should the
> Restriction that replaced these, No_Dependence, be mentioned here as
> well, or instead? I would think it would be difficult for a compiler
> to support the No_Dependence for arbitrary packages to be eliminated
> from the run time.

I think this should be wording in terms of particular No_Dependence restrictions
(as was done in Ravenscar). It certainly should not be talking about obsolescent
restrictions. But as this is a substansive change, I'll have to put it on our
discussion list.

> I note that AI05-189 No_Allocators_After_Elaboration will impact this
> section of the RM, however I presume it is not showing up in the RM
> yet, because the AI needs more work, and has not made its way to WG9
> approval yet.

There were a lot of such things. It was added to H.4(23.3/3); if something more
needs to be done, hopefully the next reviewer will catch it.

> J.2 (5.e) “is not legal in Ada 83, nor will it be in Ada 95.”
> This should be revised, it suggests Ada95 does not exist yet, and
> doesn't explain the situation for Ada 2005, Ada 2012, or the future.

There is no value to mentioning language versions here. Replace with:

is not legal in Ada (and never was legal). One has to write:

> K(95/3) “{S'Class'Input first}[First] reads the external tag from
> Stream....” This sentence is missing a subject.

Doesn't matter. These sentences are automatically generated from the text that
occurs elsewhere in the standard, and cannot be changed without changing the
normative text elsewhere. It's a stupid design, but we're stuck with it.

If you can justify changing the normative description of one of these
attributes, then it *might* be possible to change this description. Do that
wherever the attributes are defined. I'm not going to try, but you are welcome
to if you care enough.

> “... and then dispatches to the subprogram denoted by the Input
> attribute of
>
> the specific type identified by the internal tag[;]{and subsequently}
> returns that result.”
>
>
> K(168/2) “{S'Class'Output first}[First] writes the external tag....”
> This sentence is missing a subject.
>
> K(194) “{S'Class'Read dispatches}[Dispatches]”
>
>
> K(273/2), K(277.4/2) Why was “image” changed from italicized to
> non-italicized in K(273/2), but left as italicized in K(277.4/2)?
> Also, “that is, a sequence of characters representing the value in
> display form.” was deleted from the first paragraph, but left intact
> in the second paragraph? Why the inconsistency?
>
>
> K(285) “S'Class'Write dispatches[Dispatches]”

> L(39.a) We have wording changes from Ada 83, but nothing
> since, yet there have been numerous other changes from Ada
> 95, Ada 2005, and Ada 2012. Should these be mentioned here?
> Annex K for instance doesn't mention any wording changes.

No, these are automatically generated annexes and I have no idea what changes
have been made. And it makes no sense to spend a lot of time writing AARM notes
that are next to useless anyway.

> M(1/2) “The Ada language allows for certain target machine
> dependences {to exist} in a controlled manner.” Sentence
> doesn't read well without addition.

That's Ada 95 wording.

> M.1  It seems surprising, (and questionable) that there have
> been no new documentation requirements added to this section
> for Ada 2012. Are we confident that none should have been added?

This section is only for "Documentation Requirements" sections. I did a quick
check and did not find any added ones, but if there are any they should appear
here.

> e.g. Barrier_Limit in Ada.Synchronous_Barriers is missing,
> though perhaps this should not be mentioned here, but
> mentioned in M.2 instread (to be consistent with where
> System.Multiprocessors.CPU_Range was added). In any case, it
> is missing.

Definitely it belongs in M.2, it's an "implementation-defined" item, not a
direct "documentation requirement". I've added it.

> M.2 Similarly, I would have thought there might be more
> additions than indicated.

Please find them. There is no automated way to look for these (any form of
"implementation-defined" needs to be included), and I'm not about to read the
entire standard for that! Please take an action item to look for these, and
report any that are missing: by the section and paragraph where they are
defined. (As an automated annex, I don't care about it at all, the changes need
to be made elsewhere.)

> M.3(12/2) Doesn't read well, then sentence appears to be
> missing a subject.

"For" is excess here. I just deleted it as I don't have a way to properly make a
change here.

> M.3 (84/2) (86/2) (87/2) (88/2) seems to be redundant with
> M.3(116/2), (118/2)

They're in different annexes. In any case, this clause intends to document every
Implementation Advice section in the standard, so it seems likely that some
would be redundant.

> N (26) says “A program may contain just one partition.” Can
> it be zero partitions? Wouldn't it be more accurate to say;
> “A program must contain at least one partition.”?

Probably, but we previously decided not to mess with the glossary, and this
wording doesn't seem *wrong*.

> P (6.1) parameter_specification, should be a space between
> [aliased]mode

P is completely automatically generated, can't make any changes here without
changing the normative text. In any case, this doesn't appear in the current
draft (presumably someone else noticed a problem in 6.1).

> P (7.1) Says package specifications can have aspect
> specifications. AI 183 says this also, but gives no examples
> of use. Has this been specified well enough? For example,
> what does precondition, postconditions mean for a package
> specification. When are they executed? The rules appear to be
> covered by 13.3.1(13/3) "Other rules are not defined at this time."

This makes no sense. Aspects can only be specified on particular kinds of
entities. For instance Pre is only allowed on a subprogram, Pure only on a
package. In any case, AI05-0183-1 is *still* not finished, so it makes no sense
to depend solely on the RM draft.

> Q.3(Language Defined Subprograms) I note that Language and
> Country from Ada.Locales does not show up here. Also
> Number_Of_CPUs from System.Multiprocessors is missing. Should
> there be a scrub through all the new packages to verify that
> all the new subprograms have been added?

That's done automatically, it's hard to miss them. If anything is missed, it's a
markup error. Of course, those happen. So a scrub isn't a bad idea, I'm glad
that you volunteered. :-) You'll find it on your next action item list. I did
fix the ones you noted, of course.

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

From: Steve Baird
Sent: Tuesday, May 17, 2011  9:50 PM

Gary and I each independently noticed this one (see below) recently.

Do you think
   a) there is no problem here
   b) there is a minor problem which is not worth fixing at this point
   c) there is a problem which needs fixing
   d) there are two problems and their names are Gary and Steve ?

   -- Steve

P.S. After writing "stand-alone object of an anonymous access type"
      as often as I have recently, most anyone would start using the
      term "saooaaat".

====

The RM wording for type conversions is somewhat bogus.

There is a rule that "statically deeper" rules never apply to a saooaaat. But
we sort of want them to apply in a case like

      Ptr : access Integer;
    begin
      declare
         X : aliased Integer;
      begin
         Ptr := X'Access;

so we've got the rule in 4.6:

   The accessibility level of the operand type shall not be statically
   deeper than that of the target type, unless the target is a
   stand-alone object of an anonymous access type. If the target is such
   a stand-alone object, the accessibility level of the operand type
   shall not be statically deeper than that of the declaration of the
   stand-alone object.

This wording refers to "the target" as if we were already talking about a target and
had established that bit of context.

But this is the first we've heard of any target object. There is earlier talk about the
target type of the conversion, but that's different.

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

From: Gary Dismukes
Sent: Wednesday, May 18, 2011  12:54 PM

...
> P.S. After writing "stand-alone object of an anonymous access type"
>       as often as I have recently, most anyone would start using the
>       term "saooaaat".

Works for me.

...
> This wording refers to "the target" as if we were already talking 
> about a target and had established that bit of context.
> 
> But this is the first we've heard of any target object. There is 
> earlier talk about the target type of the conversion, but that's 
> different.

I think the "unless" part of the wording can only be applying to implicit
conversions to the anonymous type of a saooaaat, so I think it may just be a
matter of changing the wording to say something like:

  "unless the target type is an anonymous access type of a stand-alone
   object.  If the target type is that of such a stand-alone object, ..."

Does that seem like the right fix, or is there more to this than I'm seeing?

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

From: Steve Baird
Sent: Wednesday, May 18, 2011  1:42 PM

Looks good to me.

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

From: Randy Brukardt
Sent: Wednesday, May 18, 2011  10:13 PM

Me too, I've updated everything this way.

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

From: Randy Brukardt
Sent: Wednesday, May 18, 2011  10:31 PM

It should be noted that there is a matching dynamic check, and that too needs this
same wording change. Indeed, I initially fixed that and not the static rule you
asked about.

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