Version 1.30 of ai12s/ai12-0005-1.txt
!standard 6.6 (6) 11-11-11 AI12-0005-1/00
!class confirmation 11-11-11
!status received 11-11-11
!priority Low
!difficulty Easy
!qualifier Omission
!subject Editorial comments on AARM 2012
!summary
This AI serves as a holder for editorial comments on AARM-only
annotations. This AI serves the same purpose as AI95-00114 did for Ada 2005
and AI05-0005-1 did for Ada 2012. Because the AARM has no official status
as far as ISO is concerned, these will be considered low priority.
If a change cross-references this AI, find it in the Appendix below.
!question
!response
!appendix
From: John Barnes
Sent: Tuesday, May 22, 2012 3:11 PM
...
Anyway, I just downloaded the latest version and hunting around for incomplete types
and generics, I came across 12.5(16.i/3). It refers to AI-215 instead of AI-213. Rats.
****************************************************************
From: Randy Brukardt
Sent: Monday, January 14, 2013 9:26 PM
AARM 3.9(12.d/2) uses "privateness", which is not a word. Use "privacy" instead.
****************************************************************
From: Randy Brukardt
Sent: Monday, January 14, 2013 9:26 PM
AARM 9.6.1(4.a/2) has two minor errors. First there is a word missing:
"... which are more than 12 hours {different }than UTC. ..."
Second, "southern" is misspelled (the last 'n') is missing.
****************************************************************
From: Randy Brukardt
Sent: Friday, April 19, 2013 1:21 AM
AARM 11.5(31.l/3) has a typo:
...inlining is never requir{ed}[ing],...
****************************************************************
From: Tucker Taft
Sent: Tuesday, February 26, 2013 5:10 PM
I agree with both of you. [Editor's Note: The majority of this thread can be
found in AC-00248.]
The wording as given is inadequate, but the intent is
as Randy stated: you may assume that if you evaluate an assertion expression
once and it is True, you don't need to evaluate it again if all you are doing in
the mean time is evaluating assertion expressions.
***************************************************************
From: Steve Baird
Sent: Tuesday, February 26, 2013 5:21 PM
I'm happy to leave it at that.
Let's either take no further action or, if anyone thinks it is worth the bother,
add a brief AARM note based on Tuck's words above.
*** Add an AARM note.
***************************************************************
From: John Barnes
Sent: Friday, June 7, 2013 9:13 AM
The package Ada.Dispatching was Pure in Ada 2005 but has been downgraded to
Preelaborable because of the addition of Yield. This is unlikely to be a
problem. (AI-166, D.2.1)
*** Incompatibility not mentioned in AARM
When an inherited subprogram is implemented by a protected function, the first
parameter has to be an in parameter, but not an access to variable type. Ada
2005 allowed access to variable parameters in this case; the parameter will
need to be changed to access to constant by the addition of the constant
keyword. (AI-291, 9.4)
*** this is a BI, but it doesn't say correction in AARM
***************************************************************
From: Randy Brukardt
Sent: Monday, June 15, 2013 9:43 PM
3.10.2(7.b/2) talks about anonymous access types used in stand-alone
type declarations and function results as having the level of the
declaration. But neither of these are true anymore (they also have
special rules). This note needs to be rewritten to talk only
about components.
***************************************************************
From: Randy Brukardt
Sent: Thursday, October 24, 2013 9:43 PM
The thread in AC-00254 makes it clear that the "resolution" rules
4.6(7) and 6.4.1(4) are not actually used for resolving overloading
and the like. They exist specifically to prevent the "name" from
being evaluated (which would happen by 4.4(10)) if they are part
of an expression. That's why they used the weird wording of
"interpreted as" rather than "shall be". This needs to be much
clearer in the AARM Notes.
AC-00254 has an example program that illustrates some of the
oddities that would occur if these rules were used as resolution
rules. Tested compilers do not do so, thus we add the notes to
ensure that future compiler authors are not confused.
***************************************************************
From: Steve Baird
Sent: Friday, November 15, 2013 4:57 PM
unhyphenated "class wide" in 6.5(5.d/3)
"if the result type is class wide, then there must be an expression ..."
***************************************************************
From: Randy Brukardt
Sent: Wednesday, December 11, 2013 9:43 PM
There is an unhyphenated "classwide" in 6.8(5.b/3). "...and the static
classwide accessibility check cannot fail..." There are also
occurrences in 3.7.2(3.b/3) [two occurrences], 7.6.1(9.b/3),
7.6.1(24.ee/3), and E.2.2(20.j/3).
***************************************************************
From: Adam Beneschan
Sent: Tuesday, February 4, 2014 10:03 AM
Is there a reason why the Shift_*** and Rotate_*** subprograms defined in
Interfaces (in B.2) aren't listed in Q.3, or was this an oversight?
They also don't have their own Index entries. (By contrast, the subprograms
in Interfaces.C, defined in B.3, are in both places.)
***************************************************************
From: Randy Brukardt
Sent: Wednesday, February 5, 2014 6:51 PM
I can't find any documentation of the reason, but I think I omitted them
because the contents of package Interfaces is formally implementation-defined.
(See B.2(1) and especially AARM B.2(1.a)).
As further evidence of this reasoning, note the difference between the handling
of these packages for restriction "No_Implementation_Identifiers". In
particular, all identifiers in Interfaces are considered implementation-defined
(13.12.1(2.11/3) and 13.12.1(2.15/3)), while only added identifiers in
Interfaces.C are considered implementation-defined (13.12.1(2.2/3) and
13.12.1(2.6/3)).
As such, they're not "language-defined" identifiers and thus they don't belong
in Annex Q. Note that you don't find Long_Integer or Short_Integer in Annex Q,
either. (Given the special handling for Long_Integer and Long_Float for the
purposes of restriction No_Implementation_Identifiers, perhaps they ought to
be there.)
They probably ought to be in the main index, but I probably forgot about them
simply because the usual command does all of that automatically (it adds a
subprogram to the Annex Q and main indexes with a single operation). Since I'm
not using the usual command, I ended up not using any command. I'll fix that
for future versions.
P.S. Note that the indexes are non-normative, so these are treated like
questions on the AARM; so this thread will be filed in AI12-0005-1 with other
AARM questions.
***************************************************************
From: Adam Beneschan
Sent: Wednesday, February 5, 2014 7:21 PM
> I can't find any documentation of the reason, but I think I omitted
> them because the contents of package Interfaces is formally
> implementation-defined. (See B.2(1) and especially AARM B.2(1.a)).
B.2(1.a) looks a lot like 13.7(2.a/2), and the identifiers in System do appear
in Annex Q.
But I'll allow there are other differences there. 13.7(2) says "The following
language-defined library package exists" about System, while B.2(2) doesn't use
the word "language-defined". Also, the description of
No_Implementation_Identifiers lists System in the same category as
Interfaces.C.
I guess it seems a bit odd to have an identifier that is
"implementation-defined" as opposed to language-defined, but that the language
requires implementations to define (since it's in the Implementation
Requirements section). Also, the language does seem to define what the
identifier is supposed to do. Perhaps these identifiers are is in some
in-between state between language-defined and implementation-defined---a
"Schrödinger's Identifier", maybe?
Anyway, I was just wondering if the omission was a typo. If there's a reason
behind it, that's OK with me (I don't normally look things up in Annex Q
anyway).
***************************************************************
From: Randy Brukardt
Sent: Wednesday, February 5, 2014 8:04 PM
...
> I guess it seems a bit odd to have an identifier that is
> "implementation-defined" as opposed to language-defined, but that the
> language requires implementations to define (since it's in the
> Implementation Requirements section). Also, the language does seem to
> define what the identifier is supposed to do. Perhaps these
> identifiers are is in some in-between state between language-defined
> and implementation-defined---a "Schrödinger's Identifier", maybe?
I think that's right. The problem here is while there is a requirement that
an implementation define a function Rotate_Left, the first argument to it has
a type that is clearly implementation-defined. (Most implementations will have
Unsigned_8, but other possibilities exist: our U2200 implementation had
Unsigned_9 but no Unsigned_8, for instance.) So it's in a weird limbo halfway
between language-defined and implementation-defined. Since 13.12.1 comes down
on the side of implementation-defined, the Annex Q indexes do the same.
> Anyway, I was just wondering if the omission was a typo. If there's a
> reason behind it, that's OK with me (I don't normally look things up
> in Annex Q anyway).
The omission from the main index was clearly an oversight (although "rotate"
and "shift" are indexed). The omission from Annex Q was on purpose, I think.
***************************************************************
Summary of private discussion between Steve Baird and Randy Brukardt,
Wednesday, February 26, 2014
Baird:
Given
X : constant Positive := 0;
is X a static constant?
Brukardt:
Yes, of course
X : constant Positive := 0;
is a static constant that's legal (and raises Constraint_Error at runtime).
It's weird but causes no problems, and any other answer would be incompatible
(see ACATS test B490001) and very bad for conditional compilation.
It causes no problems because no code/types/whatever that will ever execute
can depend on the value of X, and the value of the static expression is
well-defined (so we always know what to do at compile-time).
It's necessary so that conditional compilation works:
if Static > 0 then
declare
Bits : constant Positive := Static;
type Foo is range 0 .. (2**Bits)-1 with Size => Bits;
begin
...
We don't want the legality of Foo to depend on the *value* of Static (which
it would if Bits is not a static constant when Static = 0), else the entire
conditional compilation idea falls over.
[4.9(34) causes many other such problems -- 2**Bits shows one of them -- but
we certainly don't want to introduce any more. Recall the hoops we jumped
through to allow conditional expressions to work as expected.]
Cases like the above show that the compatibility issue is significant, thus no
change of any kind is best.
Maybe we want an AARM note, but no more.
Baird:
> It's weird but causes no problems, and any other answer would be
> incompatible (see B490001) and very bad for conditional compilation.
B490001's constant declaration would still be legal if we changed the
definition of "static constant" to include a requirement that the static value
belongs to the static subtype of the constant.
But your are still right that it could be incompatible.
This example is currently legal, but would become illegal:
X : constant Positive := 0;
function Foo return Natural is ... ;
begin
case Foo is
when X => ...;
when Positive => ...;
end case;
So I agree that we would need a good reason to make such a change.
Is there any problem with having a static constant whose elaboration raises
an exception? Does this cause problems with preelaborability, purity, the
DSA, etc. ?
Brukardt:
I was asking you that! I can't think of any, specifically because the static
value (presuming the expression is otherwise legal) is well-defined. In this
case, 0. So the compiler just uses that (which it has to be able to do), and
nothing that depends on that value can ever actually be executed, so there is
no real problem.
I suppose you might get funny errors in some cases:
X : constant Positive := 0;
B : constant Boolean 10/X; -- Illegal, divide-by-zero
which is of course weird because you divided by a Positive value to ensure that
you couldn't divide by zero.
But I don't see that as worse than any other conditional compilation related
errors.
Purity seems to be syntactic (constant vs. variable).
Preelaboration seems to be better with the current rule. If we changed it, then
preelaboratability could depend on an imported value:
X : constant Positive := Other_Pkg.Static;
Y : constant Positive := X + 1; -- Better be static.
If X is not a static constant when Other_Pkg.Static = 0, then Y is not allowed
in a preelaborable package. That seems like a maintenance hazard (someone
changes a value, a package far away becomes illegal for an obscure reason, and
the fix is definitely non-trivial).
Note that C.4(11) seems to cover this case, not requiring no code to be
executed if the declaration raises an exception during elaboration.
I'm not going to try to figure out DSA.
***************************************************************
From: Randy Brukardt
Sent: Friday, April 18, 2014 9:44 PM
13.14(10.m/3) has:
type Bar is access function Foo (A : in Natural) return Natural;
But the syntax of an access-to-subprogram does not have an identifier
where Foo is given; it should be deleted.
***************************************************************
!topic Ada.Direct_IO: Index after Create resp. Open
!reference Ada 2012 RM A.8.2(3/2,7)
!from Christoph Grein 2014-09-25
!discussion
Neither Create nor Open specify the value of Index, which will be used for Read
or Write, see A.8.5(3,6,11), for the very first access with the procedures
without the Positive_Count parameter (must be 1, of course).
Should this oversight be corrected?
[Editor's note: Most of this thread is filed in AC-00264.]
***************************************************************
From: Egil Harald Hoevik
Sent: Thursday, October 2, 2014 1:33 AM
I believe that's covered by A.8(3-4)
***************************************************************
From: Randy Brukardt
Sent: Thursday, October 2, 2014 1:51 PM
> I believe that's covered by A.8(3-4)
Thanks!
A.8(4) says "When a direct file is opened, the current index is set to one."
Hardly could be any clearer than that. Perhaps it isn't in the best possible
place, but it certainly is stated normatively.
[Editor's note: I added AARM notes to make this cross-reference more obvious.]
***************************************************************
From: Randy Brukardt
Sent: Friday, October 10, 2014 8:58 PM
13.11.3(9.c/3) does not mention aspect Default_Storage_Pool (see
13.11.3(5/3)).
***************************************************************
From: Randy Brukardt
Sent: Friday, February 13, 2015 8:12 PM
13.1.1(4.b/3) does not mention expression_function_declaration, it should be
added directly after null_procedure_declaration.
***************************************************************
From: Steve Baird
Sent: Tuesday, March 10, 2015 6:48 PM
There may be no problem here, but the wording seems unclear to me.
If you think it is clear enough, I'll probably shut up (I say "probably" just
to reserve the right to change my mind).
In 4.1.6, we've got a new note
The Constant_Indexing and Variable_Indexing aspects
cannot be redefined when inherited for a derived type,
but the functions that they denote can be modified by overriding
or overloading.
I don't think the 4.1.6 wording makes it sufficiently clear that the set of one
or more functions denoted by a C_I/V_I aspect is recalculated when we declare
an extension. For example, if an ancestor type has C_I specified which denotes
two functions, might a descendant of that type have three C_I functions with
one inherited, one overriding, and one non-overriding? Presumably yes.
If the descendant type overrides an inherited C_I function of the ancestor
type, which function body gets executed for an indexing call if the prefix
is not class-wide? Presumably the overrider's.
How does all this work in a case like
package Pkg1 is
type T1 is tagged null record with Constant_Indexing => Foo;
function Foo (X : T1; Y : Integer; Z : Integer := 123) return T1;
end Pkg1;
package Pkg2 is
type T2 is new Pkg1.T1 with record F2 : Integer := 0; end record;
overriding
function Foo (X : T2; Y : Integer; Z : Integer := 456) return T2;
end Pkg2;
Aaa : Pkg.T2;
Bbb : Pkg.T2 := Aaa (789);
? Presumably this is legal and the non-dispatching call returns a T2, not a T1
(and the actual parameter passed in for Z is 456, not 123).
It also seems a little odd that the equivalence rule which defines the dynamic
semantics of these guys (4.1.6 (17/3)) occurs in a "Name Resolution Rules"
section.
***************************************************************
From: Steve Baird
Sent: Wednesday, March 11, 2015 1:42 PM
> If you think it is clear enough, I'll probably shut up (I say
> "probably" just to reserve the right to change my mind).
After sleeping on it, I see that the crux of the matter is the name resolution
rule
When a generalized_indexing is interpreted as a constant (or
variable) indexing, it is equivalent to a call on a prefixed view of
one of the functions named by the Constant_Indexing (or
Variable_Indexing) aspect of the type of the
indexable_container_object_prefix with the given
actual_parameter_part, and with the indexable_container_object_prefix
as the prefix of the prefixed view.
and, specifically, the meaning in the case of a derived type which inherits the
aspect of the phrase
"the functions named by the Constant_Indexing (or
Variable_Indexing) aspect of the type"
.
I know what set we want that phrase to denote (it is the set of subprograms
where the equivalent prefixed call would work as defined in 4.1.3(9.2/3)).
My question is whether the current wording captures that intent.
I think maybe it does and there is no problem, but I raise the question.
***************************************************************
From: Randy Brukardt
Sent: Wednesday, March 11, 2015 2:38 PM
I agree ("maybe it does"). The wording says "named by" and not the more usual
"denoted by"; this means that it is the name of the function and not the
declaration that is denoted that matters. Thus one starts with the name each
time and then must figure out from that what is denoted. Obviously, that might
be different for a derived type vs. the original type.
What's not 100% clear to me is the implied (re-)resolution. Since one has a
name by the rule, and one needs a declaration in order to make a call, I don't
see how else one could arrive at a declaration. But it's not spelled out. Of
course, that's typical of name resolution rules; the actual name resolution
tends to be implicit in them.
Thus I conclude that there is no problem (although perhaps adding an additional
sentence to 4.1.6(17.c/3) would help future readers: "This equivalence is then
resolved in the normal way; the aspect specifies a name, it does not denote
declarations.")
***************************************************************
Editor's note (April 2, 2015): All of the items above this
marker are included in the Corrigendum version of the AARM.
****************************************************************
From: Tucker Taft
Sent: Sunday, April 26, 2015 5:54 PM
There is some lack of clarity in the RM relating to the use of a subtype with a
Static_Predicate that is declared in the scope of an "Ignore" Assertion_Policy.
For example, in AARM 5.4(13, 13.a) it says the following:
13 Otherwise (the value is not covered by any discrete_choice_list,
perhaps due to being outside the base range), Constraint_Error is raised.
13.a Ramification: In this case, the value is outside the base range of its
type, or is an invalid representation.
13.a is not correct in the presence of subtype predicates. An object can have
a "valid representation" and still have a value that does not satisfy its
Static_Predicate, and hence not be covered by any choice list. This is easy to
accomplish if "pragma Assertion_Policy(Static_Predicate => Ignore)" applies
when the subtype is declared. Hence 13.a should be refined to include the
case of a value that does not satisfy a Static_Predicate.
It should also be clarified that X'Valid being False does *not* mean that X has
an invalid representation. If X is in the appropriate range, but does not
satisfy the predicates of its nominal subtype, then X'Valid will return False,
but X is still "valid." This is confusing, and probably deserves a "user note"
somewhere.
More generally it might be appropriate to augment the AARM implementation notes
that say what happens with subtypes with Static_Predicates that are being
ignored. In particular, it should be clarified that, given an object X of such
a subtype S, Constraint_Error is a possible outcome in "case" statements with X
as the case expression (the situation described in 5.4(13,13.a) above),
membership test "X in S" might return False, X'Valid might return False, etc.
Be that as it may, this is *not* erroneous execution. The results are totally
predictable, repeatable, and portable (and potentially confusing ;-).
***************************************************************
From: Robert Dewar
Sent: Sunday, April 26, 2015 7:05 PM
the case statement should definitely raise CE in my view (P.S. that is the
current treatment in GNAT).
***************************************************************
From: Jeff Cousins
Sent: Monday, April 27, 2015 4:14 AM
5.4 13.a needs updating, but it's pretty clear from 5.4 13, 3.8.1 10.1/3,
11.4.2 10/3 and 4.9 26/3 that there should be a Constraint_Error.
***************************************************************
From: Randy Brukardt
Sent: Monday, April 27, 2015 10:36 AM
...
> 13.a is not correct in the presence of subtype predicates.
> An object can have a "valid representation" and still have a value
> that does not satisfy its Static_Predicate, and hence not be covered
> by any choice list. This is easy to accomplish if "pragma
> Assertion_Policy(Static_Predicate => Ignore)" applies when the subtype
> is declared. Hence 13.a should be refined to include the case of a
> value that does not satisfy a Static_Predicate.
This just looks like a case where the editor (me) and the AI author (Bob)
failed to notice that AARM note needs updating. Hardly a big deal.
> It should also be clarified that X'Valid being False does
> *not* mean that X has an invalid representation. If X is in the
> appropriate range, but does not satisfy the predicates of its nominal
> subtype, then X'Valid will return False, but X is still "valid." This
> is confusing, and probably deserves a "user note" somewhere.
In hindsight, this probably was a mistake; we should have left 'Valid to
validity and let people that wanted to get the predicates involved to use
memberships. But it is what it is; it's water over the bridge or under the dam
now. :-)
Perhaps a note is worthy. Are you drafting one?? (Or do I have to do
*everything*? :-)
> More generally it might be appropriate to augment the AARM
> implementation notes that say what happens with subtypes with
> Static_Predicates that are being ignored. In particular, it should be
> clarified that, given an object X of such a subtype S,
> Constraint_Error is a possible outcome in "case"
> statements with X as the case expression (the situation described in
> 5.4(13,13.a) above), membership test "X in S"
> might return False, X'Valid might return False, etc. Be that as it
> may, this is *not* erroneous execution. The results are totally
> predictable, repeatable, and portable (and potentially confusing ;-).
That seems unnecessary. This happened to be the absolute top priority on my
testing list (it has been for quite a while); that's partly because I had
sorted all of the items with the same priority in clause order, and something
in 3.2 doesn't have much chance of anything with the highest priority to occur
in front of it.
Anyway, I wrote those tests (two) tonight, so the ACATS now checks that
memberships, 'Valid, and for loops use the predicates even if disabled (and
that the checks are not actually made in subtype conversion contexts). So it's
hardly likely that any implementor will not be aware of those effects.
I just added an objective for 5.4(13) to check the Constraint_Error case (it
was previously marked as untestable, but clearly this case is testable).
Since it would be based on the test I wrote tonight, it probably will get
written in the coming weeks, so that shouldn't surprise anyone, either.
(Especially after we fix the AARM note.)
***************************************************************
From: Bob Duff
Sent: Friday, May 15, 2015 5:50 AM
> This just looks like a case where the editor (me) and the AI author
> (Bob) failed to notice that AARM note needs updating. Hardly a big deal.
I admit that when I wrote that AI, I wasn't thinking about Assertion_Policy.
So I'm not surprised there are bugs related to that.
***************************************************************
From: Randy Brukardt
Sent: Monday, May 18, 2015 8:25 PM
AARM 3.9(18.c/2), referring to Generic_Dispatching_Constructor, says:
Note that any tagged type will match T (see 12.5.1).
T is declared:
type T (<>) is abstract tagged limited private;
The issue here is that while the note for formally correct, it fails to note
that some instances would be illegal anyway.
Specifically, if the tagged type A is a tagged incomplete view (from an
incomplete type, formal incomplete type, or limited with), using it as the
actual in an instance of Generic_Dispatching_Constructor is illegal by rule
(an actual type for a formal private type is not one of the places listed
where the name of an incomplete view is allowed).
Similarly, if the tagged type A is a tagged partial view before its completion
(from a private type or private extension), using it as the actual in an
instance of Generic_Dispatching_Constructor is illegal because the type will
be frozen by the instantiation, but that would violate 13.14(17) [or, if you
prefer, 7.3(5), or even 3.11.1(8) -- this rule is repeated three times in the
RM!].
Thus I suggest a simple rewrite of the AARM annotation:
Note that {almost} any tagged type {can be used in an instance of
Generic_Dispatching_Constructor}[will match T (see 12.5.1)]. {Using a tagged
incomplete view or a tagged partial view before the completion of the type in
such an instance would be illegal; all other tagged types can be used in an
instance of Generic_Dispatching_Constructor.}
***************************************************************
From: Tucker Taft
Sent: Monday, May 18, 2015 10:05 PM
That's fine with me, though I don't think it is necessary. Incomplete types
are just that, incomplete, and are not really "types" in the normal sense.
Also, freezing is almost always treated as an orthogonal issue.
***************************************************************
From: Randy Brukardt
Sent: Monday, May 18, 2015 11:05 PM
Sure, if you're in language lawyer mode. (Although an incomplete type is
surely a (view of a) type; thinking it's not "really a type" caused all manner
of RM holes -- let's not go back there!) But I definitely don't like saying
"all" or "any" when we really mean "most". We have a strict no lying rule for
the AARM.
I realize that strictly speaking, the note *isn't* lying (the matching works,
other rules fail). But that seems like hair-splitting; only a language lawyer
will care precisely why something fails. Besides, I believe I wrote that note
(I wrote most of the Generic_Dispatching_Constructor proposals), and I think
I meant that you can instantiate the generic with any tagged type (assuming
you have an appropriate constructor function) -- which definitely is not true.
I did think about just sticking "complete" into the sentence (or maybe
channelling the old commercials with "virtually spotless" dishes and saying
"virtually all" :-), but I thought a more complete explanation would be more
useful. The private type case is not that obvious and bites people all the
time (that's why we've spent so much effort on work-arounds and alternative
rules), best to not sweep it under the rug as "just freezing, we don't need to
talk about that".
***************************************************************
From: Tucker Taft
Sent: Tuesday, May 19, 2015 7:05 AM
> ... But I definitely don't like
> saying "all" or "any" when we really mean "most". We have a strict no
> lying rule for the AARM. ...
Fair enough. Go for it.
***************************************************************
From: Jeff Cousins
Sent: Wednesday, May 27, 2015 6:33 AM
Randy's words seem an improvement.
***************************************************************
!topic Ruined paragraph
!reference 2012 RM3.10.2(20)
!from Christoph Grein 16-02-19
!discussion
This paragraph is a bullet with an incomplete sentence.
This is the previous version:
For determining whether one level is statically deeper than another when
within a generic package body, the generic package is presumed to be
instantiated at the same level as where it was declared; run-time checks
are needed in the case of more deeply nested instantiations.
This is the new content:
or generic function F
It looks like an error - there is no reason to insert "generic function" in
this paragraph - and also no /4 indication.
***************************************************************
From: Randy Brukardt
Sent: Monday, March 21, 2016 11:33 PM
There's a chunk of junk in the consolidated RM that gets its own paragraph
number (as would happen with any junk floating around); there's nothing wrong
with the actual text (it just moved down one paragraph).
Since the problem is only in the consolidated RM (and not in the Corrigendum
or Ada 2012 Standard, the official documents), we just mention it here and
fix it without further ado. [Unfortunately, Christoph then raised some further
ado - Editor.]
***************************************************************
!topic Ruined paragraph
!reference 2012 RM3.10.2(20)
!from Christoph Grein 16-03-24
!discussion
I resend this since I've never received a reply from the list, so I suspect
the mail was lost somehow.
The error is in the version
http://ada-auth.org/standards/rm12_w_tc1/RM-Final.pdf
but not in
http://ada-auth.org/standards/aarm12_w_tc1/html/AA-3-10-2.html
Oh, now I see: the paragraph (20) is erroneously present. When removed, the
text is correct again.
I haven't checked the other versions.
-------- Weitergeleitete Nachricht --------
Betreff: Ruined paragraph
Datum: Fri, 19 Feb 2016 13:08:56 +0100
Von: Christoph Grein
!topic Ruined paragraph
!reference 2012 RM3.10.2(20)
!from Christoph Grein 16-02-19
!discussion
This paragraph is a bullet with an incomplete sentence.
This is the previous version:
For determining whether one level is statically deeper than another when
within a generic package body, the generic package is presumed to be
instantiated at the same level as where it was declared; run-time checks are
needed in the case of more deeply nested instantiations.
This is the new content:
or generic function F
It looks like an error - there is no reason to insert "generic function" in
this paragraph - and also no /4 indication.
***************************************************************
From: Randy Brukardt
Sent: Thursday, March 24, 2016 11:37 PM
> I resend this since I've never received a reply from the list, so I
suspect the mail was lost somehow.
I didn't think that it needed a reply.
> Oh, now I see: the paragraph (20) is erroneously present.
> When removed, the text is correct again.
Right, just a chunk of floating junk. I'd guess that I cached a copy of a
change block while I was inserting changes, and forgot to get rid of it when
done (that happens periodically, I just usually see it before anything gets
issued). The way the formatter works, anything at all gets a paragraph number.
[I've seen a single square bracket with a paragraph number.]
Since it only appears in the consolidated RM and AARM (but not the Ada 2012
Standard or Corrigendum), no formal action is needed. I repaired the source
files and regenerated the HTML (which is easy) - which is why the error has
magically disappeared from the online HTML. Regenerating the PDFs takes 4-6
hours (each needs a set of hand-repairs, and the only software that can make
the PDF without crashing is on a very slow ancient machine -- and there is 7
different PDF files). So I thought I'd wait until some time had passed for any
other errors to be reported.
We have a tool that compares RM and Corrigendum text, but it only compares
paragraphs that are supposed to have been changed. So it can't find extra junk
(nor can it find paragraphs left out of the Corrigendum, another annoyance).
Still is a lot better than nothing.
P.S. Was this reply long enough? ;-)
***************************************************************
From: Christoph Grein
Sent: Friday, March 25, 2016 9:30 AM
> P.S. Was this reply long enough? ;-)
Oh sure, by Jove!
(I meant however the automatic list reply which I received this time.)
***************************************************************
!topic Undeleted deleted paragraph
!reference Ada 2012 TC1 RM 3.3.1(19/2)
!from Christoph Grein 16-07-15
!discussion
In the Adobe Acrobat (.pdf) with changes from Ada 95 highlighted version, the
para indicated above (on page 66) is not crossed out.
The online HTML version (without highlighted changes) is OK.
I haven't checked the other versions.
***************************************************************
From: Randy Brukardt
Sent: Thursday, July 21, 2016 6:05 PM
Must be a tools bug. It appears in that version, and *only* that version,
going back at least to the Ada 2005 RM. (All of the other RM formats and all
of the AARM formats I checked are OK.) At least that is always an unofficial
version; the critical version is RM-Final, and it is OK.
Until it can be fixed, I suggest crossing the paragraph out with a pen on your
printed copy, and using a different electronic version.
***************************************************************
From: Steve Baird
Sent: Thursday, October 6, 2016 2:06 PM
In AARM 13.1 we've got
22.d
The above code should instead be written like this:
22.e
Y : constant Address := G(...);
X : Integer := F(...);
for X'Address use Y;
Should the last two lines be replaced with
X : Integer := F(...) with Address => Y;
?
I figured you'd want to hear about this while you are dealing with all the
last-minute stuff just before an ARG meeting.
[Editor's note: changed 13.1(14.c, 14.d, 22.b, and 22.e to use
aspects.]
***************************************************************
From: Tucker Taft
Sent: Tuesday, May 2, 2017 11:52 AM
I bumped into the following when looking for cases where dynamic accessibility
checks occur. The rule for array type conversion talks about access
parameters, but I don't see how they are relevant to this issue:
In section 4.6, in the dynamic semantics for Array Type Conversion:
39.1/2
{AI95-00392-01} If the component types of the array types are anonymous access
types, then a check is made that the accessibility level of the operand type
is not deeper than that of the target type.
39.b/2
Reason: This check is needed for operands that are access parameters and in
instance bodies. Other cases are handled by the legality rule given previously.
---
I would suggest we drop the mention of access parameters here. Since the
designated type of the access parameter is necessarily a named type, even when
converting X.all where X is "access Array_Of_Anon_Acc" you know the level of
the components of Array_Of_Anon_Acc.
***************************************************************
From: Randy Brukardt
Sent: Thursday, May 11, 2017 12:10 AM
> I bumped into the following when looking for cases where dynamic
> accessibility checks occur.
Careful: you might convince me to issue more ACATS tests on that. ;-)
> The rule for array type
> conversion talks about access parameters, but I don't see how they are
> relevant to this issue:
You mean the AARM note, obviously not normative.
> In section 4.6, in the dynamic semantics for Array Type Conversion:
>
> 39.1/2
> {AI95-00392-01} If the component types of the array types are
> anonymous access types, then a check is made that the accessibility
> level of the operand type is not deeper than that of the target type.
>
> 39.b/2
> Reason: This check is needed for operands that are access parameters
> and in instance bodies. Other cases are handled by the legality rule
> given previously.
>
> ---
>
> I would suggest we drop the mention of access parameters here. Since
> the designated type of the access parameter is necessarily a named
> type, even when converting X.all where X is "access Array_Of_Anon_Acc"
> you know the level of the components of Array_Of_Anon_Acc.
I tried to figure out where this particular note came from, but it doesn't
seem to be mentioned anywhere. So it's possible I just copied it from the
access version 4.6(48.a), without enough thought.
Assuming that Mr. Baird agrees with this change (he can find ways to cause
issues that defy the rest of us!), I'll just make it (like other AARM note
changes, those do not go on the agenda or get discussed at the ARG level).
[Steve, I'd like a positive answer that you agree with Tuck.]
***************************************************************
From: Steve Baird
Sent: Thursday, May 11, 2017 8:44 AM
> Assuming that Mr. Baird agrees with this change...
I agree with Tuck.
***************************************************************
[Editor's note: The following is a heavily edited part of a private thread
not related to the Ada Standard.]
From: Gary Dismukes
Sent: Tuesday, August 8, 2017 7:29 PM
Consider:
package Aspects is
X : constant Integer;
type A is new Natural with Size => X;
private
X : constant Integer := Integer'Size;
end Aspects;
One might think that the expression for aspect Size should be static, though
clearly "X" is not a static expression here, since it refers to a deferred
constant. If it's required to be static, then it's illegal, but there seem
to be no rules that require the expression of the aspect to be static (though
if it were to be given in an attribute_definition_clause for Size it would
have to be static, by 13.3(48)), which is more than a bit surprising to us.
Our expectation is that specifying the Size as an aspect would be subject to
the same static restriction as the attribute clause. (If for some reason
X *is* considered static here, then this would be illegal, as a consequence
of 13.14(7.2/3).)
***************************************************************
From: Randy Brukardt
Sent: Tuesday, August 8, 2017 8:47 PM
13.3(48) applies to aspect specifications via the equivalence rule of
13.1.1(31/3). If that wasn't true, we'd have to repeat all of the Legality
Rules and details for specifying each attribute when specifying as an aspect,
which would completely defeat the purpose of this equivalence. The Dewar rule
at a minimum says that all of 13.3 applies to the similar aspects.
Perhaps it would be good to add an AARM note, or even a bit of wording, to this
equivalence to make it clear that all of the rules for attribute specification
apply to aspect specification. But the entire intent would be broken if this
was not the case.
***************************************************************
From: Steve Baird
Sent: Wednesday, August 9, 2017 2:22 PM
> Perhaps it would be good to add an AARM note, or even a bit of
> wording, to this equivalence to make it clear that all of the rules
> for attribute specification apply to aspect specification. But the
> entire intent would be broken if this was not the case.
Agreed on both points.
I think clarification is needed here.
***************************************************************
From: Randy Brukardt
Sent: Wednesday, August 9, 2017 11:09 PM
I'm leaning toward an AARM Note, because I can add those without getting a
full ARG discussion involved. I don't want to rewrite all of 13.3 and parts
of 13.11 and other clauses. (Likely to introduce a lot of bugs.)
The note would say something like:
AARM Ramification: Unless specified otherwise, all of the requirements on
specifying a specific aspect with an attribute_definition_clause also apply
to the an aspect_specification for the aspect. For instance, for the Size
aspect for the subtype, the expression has to be a static expression with
an integer type and nonnegative value, all of the recommended level of
support requirements apply if Annex C is supported, and so on.
OK? If not, I'll trust that you'll take the question to the ARG list. (I
don't want to cause the "wrath of Bob", especially as this equivalence
semantics was his idea.)
***************************************************************
From: Steve Baird
Sent: Thursday, August 10, 2017 11:13 AM
> AARM Ramification: Unless specified otherwise, all of the requirements
> on specifying a specific aspect with an attribute_definition_clause
> also apply to the an aspect_specification for the aspect. For
> instance, for the Size aspect for the subtype, the expression has to
> be a static expression with an integer type and nonnegative value, all
> of the recommended level of support requirements apply if Annex C is
> supported, and so on.
Looks good, and I agree that adding AARM wording is the right thing to do
here.
Some minor wordsmithing:
AARM Ramification: Unless specified otherwise, all of the requirements
[for] {on} specifying a specific aspect with an
attribute_definition_clause also apply
to [an] {the} aspect_specification for the aspect. For instance, when
[specifying] the Size aspect [of a] {for the} subtype, the expression
has to be a static expression with an integer type and [a] nonnegative
value, all of the recommended level of support requirements apply if
Annex C is supported, and so on.
I'd also consider using "particular" instead of "specific" just because we
are already talking about specifications. Ditto for "example" instead of
"instance" just because somebody searching the RM for "instance" probably
doesn't want to see this.
***************************************************************
From: Randy Brukardt
Sent: Thursday, August 10, 2017 9:54 PM
...
> Looks good, and I agree that adding AARM wording is the right thing to
> do here.
Thanks, and good.
> Some minor wordsmithing:
>
> AARM Ramification: Unless specified otherwise, all of the requirements
> [for] {on} specifying a specific aspect with an
> attribute_definition_clause also apply
> to [an] {the} aspect_specification for the aspect. For instance, when
> [specifying] the Size aspect [of a] {for the} subtype, the expression
> has to be a static expression with an integer type and [a] nonnegative
> value, all of the recommended level of support requirements apply if
> Annex C is supported, and so on.
You confused the heck out of me by getting the insertions and deletions
backwards. I couldn't figure out why you were deleting the better version in
most of the text. Finally, I went carefully back to the original and figured
out the problem.
> I'd also consider using "particular" instead of "specific"
> just because we are already talking about specifications.
> Ditto for "example"
> instead of "instance" just because somebody searching the RM for
> "instance" probably doesn't want to see this.
Makes sense.
I added a sentence about these rules being enforced at the freezing point (like
all other aspect rules), after rereading Gary's original question. I wanted it
to be clear that A is legal below:
package Aspect2 is
X : constant Integer;
private
type A is new Natural with Size => X; -- OK, does not freeze X.
type B is new Natural with Size => X;
Obj : B; -- Illegal, freezes B and X, and X is not completed yet.
X : constant Integer := Integer'Size;
end Aspect2; -- A frozen here.
The whole thing would be legal if Obj was removed; when A is frozen, X is
resolved to a static constant.
Anyway, I've added the following to the draft AARM. Coincidentally, that
should be posted with the minutes tomorrow -- talk about service! :-)
AARM Ramification: Unless specified otherwise, all of the requirements
for specifying a particular aspect with an attribute_definition_clause also
apply to an aspect_specification for the aspect. These are enforced at the
freezing point of the entity. For example, when
specifying the Size aspect of a subtype, the expression
has to be a static expression with an integer type and a nonnegative
value, all of the recommended level of support requirements apply if
Annex C is supported, and so on.
Randy.
P.S. You could argue that this is a To Be Honest note rather than a
Ramification, but that's the sort of useless argument that I'd prefer
to avoid.
***************************************************************
From: Steve Baird
Sent: Friday, February 8, 2019 12:51 PM
Does it seem odd to you that the Ada.Strings.Unbounded spec doesn't seem to
rule out constructing a string longer than Integer'Last?
If you concatenate, for example, two strings whose lengths add up to more than
Integer'Last, it seems like an exception ought to be guaranteed to result
(obviously storage_error is possible, but I'm saying that it should be
guaranteed that the call does not return normally).
It's not documented what the Length function is supposed to do with such a
string. Presumably it raises Constraint_Error, but that's not stated.
Better IMO to leave the spec for Length unmodified and instead rule out this
case by preventing construction of such a too-long string.
What do you think?
***************************************************************
From: Randy Brukardt
Sent: Friday, February 8, 2019 4:16 PM
I don't know if it is "odd", but it certainly isn't possible. Janus/Ada raises
Constraint_Error in that case (and since Integer is 16-bit in Janus/Ada, it
does come up periodically. I even had to make a Long_Unbounded_String that
uses Long_Integer indexes for some projects.), but that might be just because
that's what happens in the Ada code.
That is
Str.Length := Str1.Length + Str2.Length;
overflows in the case in question. I never made any attempt to prevent it,
because what else could it do?
(Looks at wording).
Actually, in the case of "&", the wording does say that Constraint_Error is
raised in this case. It is defined in terms of the String "&", and that would
have an upper bound outside of the index subtype of Natural, which would raise
Constraint_Error by 4.5.3(8). Indeed, an implementation that allowed
Unbounded_Strings longer than Natural would be wrong for "&".
Append is defined in terms of "&", so it too is covered.
And the others like Replace_Slice and Insert are defined in terms of
Ada.Strings.Fixed operations, which I hope (I didn't check) would also check
the index subtype.
So I conclude there is no problem here. (Any problem is in Ada.Strings.Fixed.)
It might make sense to have an AARM note that mentions this; I certainly agree
that this is a non-obvious ramification. (We can just do that, no need to
involve anyone else.)
***************************************************************
From: Edmond Schonberg
Sent: Monday, February 11, 2019 1:54 PM
Subject: infinitesimal glitches in the AARM
(with corresponding priority). I came across the following in the latest
version (I have to say that the amount of work that you
have put and continue putting into this is beyond awesome!):
2.9 (3.g/5) : 2012=> 2020
3.10.2 (23.r/4) : (is) leads [Editor's note: this is really 3.10.1 (23.r/4).]
6.1.1 (41.e/4) these are not [be] allowed
6.3.1 (10.a/2) different than => different from
For the last one I’ll defer to a native speaker, but “different than” grates
to my ears. It’s like using a comparison operator rather than
an equality operator!
***************************************************************
!topic ... In contrast, a[n] loop parameter of an iterated_component_association takes ...
!reference Ada 202x RM4.3.3(23.c/5)
!from Christoph Grein 19-02-20
***************************************************************
From: Randy Brukardt
Sent: Wednesday, February 20, 2019 6:03 PM
Got it!
***************************************************************
!topic Jorvik
!reference Ada 202x AARM D.13(7.a/3,7.b/5)
!from Christoph Grein 19-02-20
!discussion :
There is a note (7.a/3) on where the name Ravenscar comes form.
Shouldn't there be a similar note on (7.b/5) where the name Jorvik comes from
and how it is pronounced? It's far enough from normal English rules so that
everyone will say Zhorvik without such a remark.
(It's like the Runge-Kutta method, which to the dismay of Germans is
pronounced runzh-cutta, while both are Germans and the names are pronounced
approximately roo-ng-e and koottah.)
***************************************************************
From: Randy Brukardt
Sent: Wednesday, February 20, 2019 6:06 PM
Probably a good idea. I took the sentence from the AI that had that
information, and added it as a note.
**************************************************************
From Jeff Cousins' RM review:
E.2.2 (20.j/4) Added rules for {the} returning of remote ...
E.2.3 (19.a/4) ... all indirect or dispatching remote subprogram calls from
outside the RCI unit{,} and all direct calls from outside the subsystem
rooted at the RCI unit{,} are ...
E.2.3 (19.b/4) There is no point [to force]{in forcing} local ...
**************************************************************
From Bob Duff's RM review:
4.6(7.a/4): This matters [as]{because}...
4.6(24.q/4): [recheck]{rules}
4.6(71.x/4): Hyphenate assume-the-worst. ... unlikely [as]{because}...
**************************************************************
From Steve Baird's RM review:
3.10.2(7.b/4) says (as per AI12-0005)
"... as well as the accessibility level of anonymous access types in a
component_definition"
Should "in" be replaced with "defined by"? [Yes - Editor.]
In 3.10.2(19.3/4) we say
"... when within ... or the return expression of expression function F,
the <blah blah blah> is presumed to be the same as that of the level of
the master that elaborated the body of F."
Is it ok to talk about elaborating the body of an expression function?
[Editor's reply:
It's bit iffy, because there isn't a static definition of the "body" of an
expression function. But the only way to reword this would require a separate
(and long) sentence only about expression functions. That seems like overkill.
I added a To Be Honest note about this:
For an expression function F, the "body of F" is the
expression_function_declaration of F.]
***************************************************************
From: Bob Duff
Sent: Monday, April 1, 2019 2:49 PM
Maybe you can handle this as a simple editorial fix in 2.3:
4.1/5 {AI12-0004-1} {AI12-0263-1} An identifier shall only contain characters
that may be present in Normalization Form KC (as defined by Clause 21 of
ISO/IEC 10646:2017).
4.b/5 Implementation Note: An implementation can usually detect this
during lexical processing. The code points not allowed are those
for which Unicode property NFKC_QC (Normalization Form KC
Quick_Check) has the value No. We say "might be allowed" so that
No, we don't. We say "may be present".
characters for which the value is Maybe (really, one of the
possible values is Maybe) are allowed (these are mainly combining
marks). The necessary tables can be found in
http://www.unicode.org/Public/UCD/latest/ucd/DerivedNormalizationProps.txt
. Versions for older Unicode versions can be found on this site as
well; start at http://www.unicode.org/Public/ and find the
appropriate version number.
**************************************************************
From Ed Schonberg's RM review:
12.5.1 (5.g/4) types [that differ from the kind] {whose
kind differs from that of}
12.6 (8.e.2/5) ..of [an] {a} formal abstract subprogram.
> 13.1.1 (18.c/5) … they all have to specify the same
> [primitive of T] value for that aspect )?) Explanation is garbled.
**************************************************************
From Tucker Taft's RM review:
8.1(18.t/4)
... Note that some implementations already allow this common
sense interpretation, so this extension [may]{might} in fact
{already} be used in existing code.
8.5.1(4.a/5)
[This rule prevents] {These rules prevent} "lying". ...
**************************************************************
From Brad Moore's RM review:
13.14(3.g/4) Ramification: Note that the rule about proper
bodies [being]{causing} freezing only applies in declarative_parts.
***************************************************************
From: Steve Baird
Sent: Tuesday, May 28, 2019 5:04 PM
[From private mail.]
>> AFAIK, there are no restrictions on calling
>> Task_Identification.Current_Task during the execution of a parallel
>> construct.
>>
>> Should there be? I don't think so, but I raise the question.
>
> I don't see any problem here, a task /= LToC. The id would be in the
> TCB somehow, and that has to be accessible from any thread executing
> on behalf of that task (for things like task attributes as well as the
> task id).
Ok.
...
>> Do we want a C.7.1 AARM note saying something about interactions with
>> parallel constructs, just for clarification?
>
> Doesn't seem necessary, seems obvious to me. But what would you suggest??
> (We don't need to do anything "official" to add such a note, someone
> needs to author it and I can just add it.)
>
If it seems obvious then I'm fine with no action.
Would there be any value in something like
The logical threads of control associated with the execution
of a given parallel construct all execute as part of the execution of
one task. Thus, the result returned by a call to
Task_Identification.Current_Task is independent of whether the call
takes place during the execution of a parallel construct.
? "No" is a fine answer.
***************************************************************
From: Pascal Pignard
Sent: Wednesday, October 9, 2019 11:56 PM
[From private mail.]
I've read the AARM 202x draft 22 (text version).
Section 12.3 Generic Instantiation, I've found:
- Paragraph 15:
15.h type T1 is tagged record ... end record;
15.i generic
type Formal is new T1;
package G is
type Derived_From_Formal is new Formal with record ... end record;
procedure Foo(X : in Derived_From_Formal); -- Does not override anything.
end G;
15.j type T2 is new T1 with record ... end record;
procedure Foo(X : in T2);
15.k package Inst is new G(Formal => T2);
== As T1 is tagged, Formal needs "with private", as:
type Formal is new T1 with private;
Is it correct?
- Paragraph 22:
22.e generic
type T1 is private;
-- A predefined "=" operator is implicitly declared here:
-- function "="(Left, Right : T1) return Boolean;
-- Call this "="(1).
package G is
subtype S1 is T1; -- So we can get our hands on the type from
-- outside an instance.
type T2 is new T1;
-- An inherited "=" operator is implicitly declared here:
-- function "="(Left, Right : T2) return Boolean;
-- Call this "="(2).
22.f T1_Obj : T1 := ...;
Bool_1 : Boolean := T1_Obj = T1_Obj;
22.g T2_Obj : T2 := ...;
Bool_2 : Boolean := T2_Obj = T2_Obj;
end G;
== As T1 is a private formal type, so unknown, and therefore T2 unknown as
well (derived from T1), what initial value could be given for T1_Obj and
T2_Obj? Should be added a formal function? as:
with function Init return T1;
So:
T1_Obj : T1 := Init;
T2_Obj : T2 := T2 (Init);
Thus:
22.h package P is
type My_Int is new Integer;
-- A predefined "=" operator is implicitly declared here:
-- function "="(Left, Right : My_Int) return Boolean;
-- Call this "="(3).
function "="(X, Y : My_Int) return Boolean;
-- Call this "="(4).
-- "="(3) is hidden from all visibility by "="(4).
-- Nonetheless, "="(3) can "reemerge" in certain circumstances.
function Init return My_Int; -- == Added ==
end P;
use P;
...
package I is new G(T1 => My_Int, Init => Init);
-- "="(5) is declared in I (see below). -- == Changed ==
use I;
Is it correct?
***************************************************************
From: Pascal Pignard
Sent: Wednesday, October 9, 2019 11:56 PM
[From private mail.]
I've read the AARM 202x draft 22 (text version).
Section 12.6 Formal Subprograms, I've found:
8.k/2 generic
type NT(<>) is new T with private;
-- Presume that T has the following primitive operation:
-- with procedure Bar (Obj : in T);
package Gr ...
The comment:
-- with procedure Bar (Obj : in T); would be better :
-- procedure Bar (Obj : in T); wouldn't it?
***************************************************************
From: Randy Brukardt
Sent: Thursday, October 10, 2019 7:53 PM
[Sent to Tucker Taft.]
Both of these are original Ada 95 examples; I found both in the October 1994
draft AARM as well as the current draft AARM.
I'm pretty sure the first comment is correct, as the second sentence of
12.5.1(5/3) clearly applies. It's rather amazing that no one noticed this
obvious mistake in the last 25 years.
For the second comment, I think that adding a formal subprogram would hide the
operative parts of the example. Since it is incomplete already, I propose
adding "..." to the formal part and to the instance in the example to show that
there are other formal parameters without burdening the reader with the details.
Do you agree with both of these?
Assuming so, these are both AARM examples, so I propose to put this thread into
AI12-0005-1 and then make the corrections (we do not follow a formal process
for fixing the AARM unless there is a question that needs ARG input).
***************************************************************
From: Tucker Taft
Sent: Thursday, October 10, 2019 8:45 PM
They both look like legitimate gripes to me. The first is clearly a bug. The
second is simply complaining about the fact that there is no legitimate
replacement for the ellipsis, which is interesting, but doesn't affect the
fundamental point of the example, so is clearly less important (though more
impressive as far as being noticed at all!).
***************************************************************
From: Randy Brukardt
Sent: Friday, October 11, 2019 4:41 PM
...
> == As T1 is tagged, Formal needs "with private", as:
> type Formal is new T1 with private;
Yes, this is wrong. This is an original Ada 95 example, so this mistake has
been in the AARM since at least October 1994 (I verified that in a draft from
that time). Amazing that no one has reported it.
...
> == As T1 is a private formal type, so unknown, and therefore
> T2 unknown as well (derived from T1), what initial value
> could be given for T1_Obj and T2_Obj?
> Should be added a formal function?
This is also an original Ada 95 example. Tucker Taft found it amazing that
you even saw this situation, so you should pat yourself on the back for that.
However, correcting this as you suggest would somewhat hide the point of the
example. Such a formal function is unrelated to the point and could only
confuse a reader (and of course it makes the example longer). A better
solution [given that the example already uses ellipses (...) in a number of
places] is to place ellipses in the formal parameter list and in the
instantiation to show that there are additional formal parameters without
mentioning what they are.
P.S. Note that this is an instance of what Steve Baird calls "heat vision"
(think Superman). When one reads old text, it sometimes explodes into flames.
Best to only read existing text if one has a need to understand it for some
reason, lest your entire AARM turn to ashes. ;-)
***************************************************************
From: Randy Brukardt
Sent: Friday, October 11, 2019 4:42 PM
I don't find this important at all, but I suppose you are right. Again, this
is an example from Ada 2005, so it has been around for 12+ years and I don't
think anyone has been confused. It's common to think of primitive operations
of formal type much like implicit formal parameters - so the only reason to
change this is that the parameter is the wrong type for such a formal
parameter.
In any case, we're mostly interested in finding problems in *new* text (/4
and /5 paragraphs), not in examples that have been around forever. It takes
time and energy to make these changes that probably would be better spent on
things that are really wrong and/or brand-new (such as the stray text you
noted in Chapter 4).
Note that I don't mean that you should skip reporting problems that you happen
to notice, but more that you should try to avoid even reading for review old
text because any such reading inevitably leads to complaints.
(That's a sad fact about any document as large as the AARM; the same thing
happens with the Janus/Ada documentation and the Claw documentation.)
***************************************************************
Editor's note (October 11, 2019): All of the items above this
marker have been included in the working version of the AARM.
****************************************************************
Questions? Ask the ACAA Technical Agent