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

[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: 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: 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: 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.

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