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

From: Stephen Leake
Sent: Tuesday, April 18, 2006  7:04 PM

I'm reading the Ada 2005 LRM "cover-to-cover" (to be sure I know about
all the new stuff), and noticed that paragraphs 3.1 7, 8 are
identical. I suspect 8 should be deleted.

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

From: Tucker Taft
Sent: Wednesday, April 19, 2006 12:57 PM

Good point!

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

From: Randy Brukardt
Sent: Wednesday, April 19, 2006  1:09 PM

Note that all of the paragraph numbers of that clause (after number 7) are
wrong (because of the extra junk paragraph). This bug is only in (draft 16
of the) RM/AARM, and not in the Amendment proper.

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

From: Randy Brukardt
Sent: Wednesday, December 20, 2006  8:35 PM

10.1.4(5.e/2) says that the "second" rule applies, but there is only one
(very long) sentence in 10.1.4(5). 10.1.4(5.e/2) should say that the
"consistency" rule applies so that there is no ambiguity.

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

From: Pascal Leroy
Sent: Wednesday, January 3, 2007   1:39 PM

I am looking at the example in 3.10.1(2.a-2.d), and specifically at the
first comment in 3.10.1(2.d).

I surely hope that this comment is incorrect, otherwise adding "with P" in
front of the body of P would change the semantics.  Surely we did not
design a language where withing yourself has any observable effect...

I actually think that this comment is just inconsistent with the rules:
even if you are in the scope of a nonlimited_with_clause for P,
3.10.1(2.4/2) doesn't apply because the completion of T is not declared in
a visible part.

I am not exactly sure how the example should be modified.  Perhaps it
should say "note that the second rule ensures that a
nonlimited_with_clause for P doesn't make Ptr.all'Size legal before the
completion of T".

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

From: Randy Brukardt
Sent: Wednesday, January 3, 2007  12:20 PM

> I actually think that this comment is just inconsistent with the rules:
> even if you are in the scope of a nonlimited_with_clause for P,
> 3.10.1(2.4/2) doesn't apply because the completion of T is not declared in
> a visible part.

Yes, that's obviously true.
 
> I am not exactly sure how the example should be modified.  Perhaps it
> should say "note that the second rule ensures that a
> nonlimited_with_clause for P doesn't make Ptr.all'Size legal before the
> completion of T".

I think the entire part after the comma should be dropped. I don't think anything useful
can be said for this example. The sentence is nonsense in any case, because we know
that "with P.C" is the same as "with P, P.C;". This is just the example of why
we need the "in whose visible part", and it hardly makes sense to mention the
other case (it would be a very different example).

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

From: Pascal Leroy
Sent: Thursday, January 4, 2007   9:44 AM

Another one to put in this AI: 4.1(7/2) has apparently been changed by the
Amendment (otherwise it wouldn't say /2, right?) but it has no
cross-reference to an AI.

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

From: Randy Brukardt
Sent: Thursday, January 4, 2007   12:27 PM

This is one of the changes from AI05-0004; the tools didn't support such
cross-references when those were put in. That needs to be done, and the version
really ought to be /3 on those (see AI95-0004 for a complete list).

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

From: Randy Brukardt
Sent: Friday, January 12, 2007   6:53 PM

The reason behind the first half of 10.2.1(15.3/2) is very obscure, the AARM Reason
note should explain:

Such an allocator would provide a backdoor way to get a global variable into a pure
unit, so it is prohibited. Most such allocators are illegal anyway, as their type is
required to have Storage_Size = 0. But access parameters and access discriminants
don't necessarily disallow allocators. However, a call is also illegal here
(by the preelaboration rules), so access parameters cannot cause trouble. So this
rule is really about prohibiting allocators in discriminant constraints:

    type Rec (Acc : access Integer) is record
        C : Character;
    end record;

    Not_Const : constant Rec (Acc => new Integer'(2)); -- Illegal.

The second half of the rule is needed because aggregates can specify the default
initialization of a private type or extension using <> or the ancestor subtype
of an extension aggregate. The subtype of a component could use an allocator to
initialize an access discriminant; the type still could have a
pragma Preelaborable_Initialization given. Ada 95 did not allow such private types
to have preelaborable initialization, so such a default initialization could not
have occurred. Thus this rule is not incompatible with Ada 95.

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

From: Randy Brukardt
Sent: Tuesday, January 16, 2007   5:53 PM

The rules 4.3(3/2), 4.3.1(8/2), 4.3.2(4/2), and 4.3.3(7/2) can be confusing.
These are the rules that determine how an aggregate is resolved.

Tucker says (privately) that these rules are "additive"; 4.3(3/2) says don't
look inside an aggregate until you have a single array, record, or record
extension type. 4.3.1(8/2) says that you don't start
considering the "record aggregate" possibility until you
have a single record or record extension type. And so on.

There should be AARM notes that explain this on 4.3(3/2) and 4.3.2(4/2). (There
are already notes on 4.3.1(8/2) and 4.3.3(7/2).

After 4.3(3/2), we should have something like:

AARM Ramification: There are additional rules for each kind of aggregate. These
aggregate rules are additive; a legal expression needs to satisfy all of the
applicable rules. That means the rule given here must be satisfied even when
it is syntactally possible to tell which specific kind of aggregate is being
used.

After 4.3.2(4/2), we should have something like:

AARM Ramification: This rule is additive with the rule given in 4.3. That means
that rule must be satisfied even though it is alway syntactally possible to
tell that something is an extension aggregate. Specifically, that means that
an extension aggregate is ambiguous if the context is overloaded on array and/or
record types, even though those are never legal contexts for an extension
aggregate. Thus, this rule acts more like a legality rule than a name resolution
rule.

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