CVS difference for ai05s/ai05-0247-1.txt
--- ai05s/ai05-0247-1.txt 2011/04/26 05:39:53 1.7
+++ ai05s/ai05-0247-1.txt 2011/04/30 07:25:44 1.8
@@ -1,4 +1,7 @@
-!standard 13.3.2(0/3) 11-04-25 AI05-0247-1/06
+!standard 3.4(27/2) 11-04-28 AI05-0247-1/08
+!standard 3.9.2(20.2/2)
+!standard 6.1.1(0)
+!standard 7.3.2(0)
!reference AI05-0145-2
!class Amendment 11-03-21
!status work item 11-03-21
@@ -240,10 +243,10 @@
inherited subprogram is equivalent to the execution of a subprogram_body that
simply calls} [a call on] the corresponding primitive subprogram of the parent
or progenitor type {with its formal parameters as the actual parameters and, if
-it is a function, returns the value of the call} [is performed;]{. If there
-is more than one inherited homograph (see 8.3), the call is to the inherited
-subprogram that is neither abstract nor a null procedure, if any; otherwise,
-the call is to an arbitrary one of the null procedures. The}[the] normal
+it is a function, returns the value of the call} [is performed;]{. If there is
+more than one inherited homograph (see 8.3), the call is to the inherited
+subprogram that is neither abstract nor a null procedure, if any; otherwise, the
+call has no effect [Redundant: (as it is to a null procedure)]. The}[the] normal
conversion of each actual parameter to the subtype of the corresponding formal
parameter (see 6.4.1) performs any necessary type conversion as well. If the
result type of the inherited subprogram is the derived type, the result of
@@ -254,7 +257,7 @@
AARM Ramification: We define calls on inherited subprograms in terms of an
implicit body that calls the inherited subprogram. This has two effects:
-* The postconditions (see 13.3.2) and type invariants (see 13.3.3) that
+* The postconditions (see 6.1.1) and type invariants (see 7.3.2) that
are evaluated are those that apply to this implicit body; they may include
additional expressions from those that apply to the inherited routine if
there are multiple ancestors with such routines.
@@ -263,6 +266,18 @@
Note that both cases involve inheritance from more than one ancestor. If there
is only a single parent type, this definition is the same as directly calling
the inherited routine.
+
+Note that if the inherited subprogram is a null procedure, the call from the
+implicit subprogram_body has no effect, including the evaluation of
+preconditions or postconditions. We don't specify a particular null procedure
+being called, so we don't know which ones to check anyway. In contrast,
+preconditions and postconditions are checked for calls to other subprograms.
+Note that other rules ensure that class-wide preconditions do not need to be
+checked on such calls, as they are always the same or weaker that the
+class-wide precondition for the call on the inherited subprogram. But specific
+preconditions and postconditions need to be checked; where this is done depends
+on the implementation model for these checks (it might or might not need extra
+code).
End AARM Ramification.
Replace 3.9.2(20.3/3) [as replaced by AI05-0126-1 and AI05-0197-1]:
@@ -287,11 +302,13 @@
[Editor's note: Parts of this wording, including all of the Static Semantics,
are unchanged. We put the entire wording here to make it easy to see what
the entire rules are.]
+
+[Editor's note: Note that we're moving this to 6.1.1 by popular demand.]
- 13.3.2 Preconditions and Postconditions
+ 6.1.1 Preconditions and Postconditions
For a subprogram or entry, the following language-defined aspects may
- be specified with an aspect_specification:
+ be specified with an aspect_specification (see 13.3.1):
Pre
This aspect defines a specific precondition for a callable entity; it
shall be specified by an expression, called a *specific precondition
@@ -337,16 +354,22 @@
The Pre or Post aspect shall not be specified for an abstract
subprogram. [Redundant: Only the Pre'Class and Post'Class aspects may
be specified for such a subprogram.]
+
+ If a type has a inherited subprogram P implicitly declared, the corresponding
+ primitive subprogram of the parent or progentitor is neither null nor
+ abstract, a homograph (see 8.3) of P is declared and inherited from an
+ ancestor T2 that is different from the ancestor T1 from which P is inherited,
+ and at least one class-wide precondition that applies to the subprogram
+ inherited from T2 does not fully conform to any class-wide precondition that
+ applies P, then:
+
+ * If the type is abstract the implicit declared subprogram is *abstract*.
- If two or more homographs (see 8.3) that are subprograms are implicitly
- declared at the same place and at least one of the homographs is not
- abstract, then the homographs *require overriding* and shall be
- overridden with a nonabstract subprogram, unless each class-wide
- precondition that applies to each homograph fully conforms to some
- class-wide precondition that applies to each other homograph.
+ * Otherwise, the subprogram *requires overriding* and shall be overridden
+ with a nonabstract subprogram.
- [Editor's note: I borrowed a lot of the above wording from 3.9.3(6/2) and
- 8.3(12.1-3/2).]
+ [Editor's note: This is very similar to 3.9.3(4-6/3). I tried to combine that
+ into that text, but the result is just too confusing.]
AARM Reason: Such an inherited subprogram would necessarily violate the
Liskov Substitutability Principle (LSP) if called via a dispatching call
@@ -361,15 +384,24 @@
subprogram. In that case, the violation of LSP is explicitly in the code and
obvious to code reviewers (both human and automated).
+ We have to say that the subprogram is abstract for an abstract type in
+ this case, so that the next concrete type has to override it for the
+ reasons above. Otherwise, inserting an extra level of abstract types would
+ eliminate the requirement to override (as there is only one declared
+ operation for the concrete type), and that would be bad for the reasons
+ given above.
+ End AARM Reason.
+
AARM Ramification: This requires the set of class-wide preconditions that
- apply to each homograph to be identical. Since full conformance requires
- each name to denote the same declaration, it is unlikely that independently
- declared preconditions would conform. This rule does allow "diamond
- inheritance" of preconditions, and of course no preconditions at all match.
+ apply to each declared homograph to be identical. Since full conformance
+ requires each name to denote the same declaration, it is unlikely that
+ independently declared preconditions would conform. This rule does allow
+ "diamond inheritance" of preconditions, and of course no preconditions at
+ all match.
We considered adopting a rule that would allow examples where the expressions
would conform after all inheritance has been applied, but this is complex
- and is not likely to occur in practice. Since the penalty here is just that
+ and is not likely to be common in practice. Since the penalty here is just that
an explicit overriding is required, the complexity is too much.
End AARM Ramification.
[Editor's note: There is more on this topic in the !discussion.]
@@ -587,8 +619,8 @@
change any value that the precondition expression depends on, the precondition
may not hold within the subprogram or entry body.
-
+Move 13.3.3 [from AI05-0146-1] to clause 7.3.2.
!discussion
@@ -654,9 +686,18 @@
(these are class-wide expressions and they are resolved only once). Thus, type Int3
is illegal, as procedure Foo requires overriding.
+-----------------
+
+We move preconditions and postconditions directly after subprogram
+specifications (to clause 6.1.1) as these are strongly associated with these. It
+doesn't make sense for this section to be defined in chapter 13, especially
+with the Inline and No_Return aspects defined in Chapter 6. These are arguably
+more important.
+Similarly, we move type invariants to clause 7.3.2, directly after private types
+to which they apply.
-!corrigendum 13.3.2(0)
+!corrigendum 6.1.1(0)
@dinsc
@@ -7231,7 +7272,8 @@
> I'd be happy to write up a new version of AI05-0247-1 to this end, but:
> (1) I'd be violating the promise of no new wording I made on Friday;
-I'm glad you kept that promise! But I'd like to understand this particular rule you propose. You'll have to explain it either in email or during the meeting.
+I'm glad you kept that promise! But I'd like to understand this particular rule
+you propose. You'll have to explain it either in email or during the meeting.
> (2) I'm not certain that enough people agree with this approach to
> make it worthwhile.
@@ -7993,5 +8035,487 @@
> I strongly agree with that
Then you have to agree with "or" for preconditions.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, April 7, 2011 9:58 PM
+
+During today's phone call, it was pointed out that the title of Section 13
+("Representation Issues") no longer reflects the contents, and hasn't since Ada
+95. Bob Duff suggested that we call it "Hodgepodge of stuff". John suggested
+simply "Others". I think (hope??) that they both were joking.
+
+Tucker suggested that we have a naming contest, to end at midnight EDT (-4 UTC)
+next Thursday. He suggests that the prize be a bottle of scotch in Edinburgh
+(although he never specified who was buying it :-).
+
+Let me lay out a couple of rules, in case someone actually does put up a
+prize:
+ The first suggestion to post on the ARG list is considered the winner if
+ there are multiple occurrences of the same suggestion. If a message gets
+ stuck in moderation, it might be necessary to split the prize. If you are one
+ of those people who make more work for me by getting all of your incoming
+ messages stuck in my server's spam filter, tough if that delays it. :-) Send
+ it from Gmail if you care.
+
+ The ARG will hold an e-mail vote starting on tax day (April 15th) to choose a
+ winner; "stay unchanged" will be a choice, and if it wins, we'll just have to
+ share the bottle during the meeting. :-)
+
+Enter early and often!!
+
+Here is a summary of the contents of Section 13 today:
+
+ * Definition of aspects
+ * Definition of representation items and operational items
+ * Representation aspect Pack
+ * Attribute_Definition_Clauses
+ * Representation attributes
+ * Aspect_Specifications
+ * Preconditions, Postconditions, Type_Invariants
+ * Enumeration and Record rep clauses
+ * Package System and various children
+ * Machine code insertions
+ * Unchecked_Conversion
+ * Data Validity, 'Valid attribute
+ * Unchecked access
+ * Storage pools; subpools; Unchecked_Deallocation
+ * Pragma Restrictions; various restrictions
+ * Pragam Profile; No_Implementation_Extensions profile
+ * Streams
+ * Freezing rules(!)
+
+Humm, Bob's "Hodgepodge of stuff" is looking pretty good; seems like the leader
+in the clubhouse. ;-)
+
+I'll suggest
+ "Aspects of entities and representation issues"
+as my entry in the contest.
+
+To be fair, Tucker suggested
+ "Operational and Representation Control"
+during the call today. There might have been other suggestions, but I didn't
+write them down.
+
+Again, enter early and often!
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, April 7, 2011 10:12 PM
+
+> Again, enter early and often!
+
+Entry 2 from me:
+ "Aspects of entities and low-level constructs"
+
+[This is the union "and", it really should "or", but that doesn't help
+readability any.]
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, April 7, 2011 10:28 PM
+
+Controlling Representation and Operational Aspects
+
+Representation and Operational Aspects
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Friday, April 8, 2011 12:34 AM
+
+> I'll suggest
+> "Aspects of entities and representation issues"
+
+Representation is an aspect. I'd rather say:
+
+"Aspect of entities and low-level issues"
+
+(what happens when you modify a previous entry? Do we share the bottle
+50/50?)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, April 8, 2011 12:57 AM
+
+> "Aspect of entities and low-level issues"
+
+I think you combined both of my two previous submissions, but that's OK.
+
+> (what happens when you modify a previous entry? Do we share the bottle
+> 50/50?)
+
+Hard to take half a bottle home, though. I doubt I can take that through
+customs. :-) And I suspect that drinking half a bottle might be a bit much...
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Friday, April 8, 2011 2:49 AM
+
+> I think you combined both of my two previous submissions, but that's OK.
+
+I sent that message before I read your second ones. Seems we are already
+converging...
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, April 8, 2011 5:36 AM
+
+> Hard to take half a bottle home, though. I doubt I can take that
+> through customs. :-)
+
+The security actors don't like liquids. And you guys are talking about
+inflamable liquids! (Or "flamable", if you prefer.)
+
+(earlier):
+
+> Tucker suggested that we have a naming contest, to end at midnight EDT
+> (-4
+> UTC) next Thursday. He suggests that the prize be a bottle of scotch
+> in Edinburgh (although he never specified who was buying it :-).
+
+Clearly, the winner should buy it. ;-)
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Friday, April 8, 2011 6:59 AM
+
+> The security actors don't like liquids. And you guys are talking
+> about inflamable liquids! (Or "flamable", if you prefer.)
+
+Therefore, I'm afraid we'll have to drink it during the next ARG meeting...
+
+****************************************************************
+
+From: John Barnes
+Sent: Monday, April 11, 2011 1:12 PM
+
+> Here is a summary of the contents of Section 13 today:
+>
+> * Definition of aspects
+> * Definition of representation items and operational items
+> * Representation aspect Pack
+> * Attribute_Definition_Clauses
+> * Representation attributes
+> * Aspect_Specifications
+> * Preconditions, Postconditions, Type_Invariants
+> * Enumeration and Record rep clauses
+> * Package System and various children
+> * Machine code insertions
+> * Unchecked_Conversion
+> * Data Validity, 'Valid attribute
+> * Unchecked access
+> * Storage pools; subpools; Unchecked_Deallocation
+> * Pragma Restrictions; various restrictions
+> * Pragam Profile; No_Implementation_Extensions profile
+> * Streams
+> * Freezing rules(!)
+>
+> Humm, Bob's "Hodgepodge of stuff" is looking pretty good; seems like
+> the leader in the clubhouse. ;-)
+
+The real thing that sticks out for me is preconditions, postconditions and type
+invariants. They seem really out of place. We have discussed this before of
+course.
+
+****************************************************************
+
+From: John Barnes
+Sent: Monday, April 11, 2011 1:12 PM
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, April 11, 2011 1:12 PM
+
+I agree that the placement of preconditions/postconditions etc has nothing to do
+with chapter 13. These belong in the chapter on subprograms IMO.
+
+I don't see what's wrong with having the freezing rules in chapter 13, it's
+where they are relevant after all.
+
+****************************************************************
+
+From: John Barnes
+Sent: Monday, April 11, 2011 2:48 PM
+
+> I agree that the placement of preconditions/postconditions etc has
+> nothing to do with chapter 13. These belong in the chapter on
+> subprograms IMO.
+
+Well at least we agree on something! And clearly we cannot avoid forward
+references; it's a reference manual not a textbook.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, April 11, 2011 3:51 PM
+
+If chapter 13 were seen as defining the ability to define annotations of various
+sorts, where the annotations might specify representation, streaming,
+pre/post-conditions, etc., it doesn't seem so far off.
+
+Perhaps:
+
+ Chapter 13 -- Annotating the Program
+
+Most of chapter 13 is not about programming per se, but rather about annotating
+a program, and I think it is a reasonable gathering of topics when looked at
+that way.
+
+****************************************************************
+
+From: John Barnes
+Sent: Monday, April 11, 2011 4:49 PM
+
+That's a good viewpoint. (It's all about views as we know.) So I have to
+take back what I said about agreeing with Robert! It's bedtime
+anyway.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, April 12, 2011 1:46 PM
+
+Another entry:
+
+ Chapter 13 -- Program Annotations
+
+This would probably need to be explained in an introductory sentence or two to
+say that pragmas, rep clauses, aspect specifications, etc. are all ways of
+annotating an Ada program with information to control representation, run-time
+checking, streaming, storage management, etc.
+
+****************************************************************
+
+From: John Barnes
+Sent: Wednesday, April 13, 2011 8:43 AM
+
+> Another entry:
+>
+> Chapter 13 -- Program Annotations
+
+That's even better. John
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, April 13, 2011 12:59 PM
+
+> Well at least we agree on something! And clearly we cannot avoid
+> forward references; it's a reference manual not a textbook.
+
+I've previously in the "don't care" camp on this one, but in thinking about this
+further, having preconditions and invariants in Chapter 13 makes no sense. We
+have loads of other aspects scattered thoughout the standard, and I can't think
+of a single reason why these three are different. Specifically:
+
+ Predicates: Chapter 3 (3.2.4)
+ Default_Value: Chapter 3 (3.5)
+ Inline: Chapter 6 (6.3.2) [remember, this is now an aspect]
+ No_Return: Chapter 6 (6.5.1) [also an aspect]
+
+Not to mention many in the various annexes (B, C, D).
+
+So I now have changed to Bob's position: pre- and postconditions should be
+chapter 6 (either 6.1.1 or 6.3.3, the former makes more sense since these are
+specification-related, the latter is better because it doesn't make a single
+subsection), and invariants should be in chapter 7 (7.3.2) [as these are only
+allowed on private types, so they should be documented there].
+
+****************************************************************
+
+From: John Barnes
+Sent: Thursday, April 14, 2011 3:49 AM
+
+They also have affinity with exceptions because of the relationship with
+Assertion_Policy and that is in section 11. So one is going to get forward
+references again.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, April 28, 2011 9:39 PM
+
+We've previously discussed (without conclusion) that putting preconditions,
+postconditions, and type_invariants into Chapter 13 is weird.
+
+This is especially true as other aspects for other entities are scattered about
+the RM; Default_Value for types in 3.2.4, Inline for subprograms in 6.3.2,
+No_Return for subprograms in 6.5.1 (not to mention various specialized needs
+annexes). I fail to see what is different about preconditions and
+type_invariants.
+
+So I am asking for a quick straw poll on this issue. Note that all of the
+clauses are new, it is just the location in the standard that would change
+(along with a couple of forward references to 13.3.1). Type invariants are
+related to private types, so I think they should be moved there (if moved).
+Preconditions/postconditions are related to subprograms, but I'm not sure which
+place makes more sense (part of specifications, or near conformance).
+
+If a change passes, I'll put it into the forthcoming AI05-0247-1, which is
+rewriting 13.3.2 anyway, so moving it wouldn't be much of a change.
+
+Please rank the following solutions from 1 (preferred) to 3 (least
+preferred):
+
+_______ Leave preconditions/postconditions in 13.3.2 and type_invariants in 13.3.3.
+
+_______ Move preconditions/postconditions to 6.1.1 and type_invariants to 7.3.2.
+
+_______ Move preconditions/postconditions to 6.3.3 and type_invariants to 7.3.2.
+
+_______ Write in: move preconditions/postconditions to ____ and type_invariants to _____.
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Thursday, April 28, 2011 9:51 PM
+
+Please rank the following solutions from 1 (preferred) to 3 (least
+preferred):
+
+___3____ Leave preconditions/postconditions in 13.3.2 and
+type_invariants in 13.3.3.
+
+___1____ Move preconditions/postconditions to 6.1.1 and
+type_invariants to 7.3.2.
+
+____2___ Move preconditions/postconditions to 6.3.3 and
+type_invariants to 7.3.2.
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Friday, April 29, 2011 12:04 AM
+
+Please rank the following solutions from 1 (preferred) to 3 (least
+preferred):
+
+___3___ Leave preconditions/postconditions in 13.3.2 and
+type_invariants in 13.3.3.
+
+___1___ Move preconditions/postconditions to 6.1.1 and type_invariants
+to 7.3.2.
+
+___2___ Move preconditions/postconditions to 6.3.3 and type_invariants
+to 7.3.2.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Friday, April 29, 2011 12:09 AM
+
+Please rank the following solutions from 1 (preferred) to 3 (least
+preferred):
+
+___3____ Leave preconditions/postconditions in 13.3.2 and
+type_invariants in 13.3.3.
+
+___1____ Move preconditions/postconditions to 6.1.1 and
+type_invariants to 7.3.2.
+
+___2____ Move preconditions/postconditions to 6.3.3 and
+type_invariants to 7.3.2.
+
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Friday, April 29, 2011 12:35 AM
+
+____3___ Leave preconditions/postconditions in 13.3.2 and
+type_invariants in 13.3.3.
+
+___1____ Move preconditions/postconditions to 6.1.1 and
+type_invariants to 7.3.2.
+
+___2____ Move preconditions/postconditions to 6.3.3 and
+type_invariants to 7.3.2.
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Friday, April 29, 2011 3:42 AM
+
+My ballot:
+
+Please rank the following solutions from 1 (preferred) to 3 (least preferred):
+
+___3____ Leave preconditions/postconditions in 13.3.2 and type_invariants in 13.3.3.
+
+___1____ Move preconditions/postconditions to 6.1.1 and type_invariants to 7.3.2.
+
+___2____ Move preconditions/postconditions to 6.3.3 and type_invariants to 7.3.2.
+
+****************************************************************
+
+From: John Barnes
+Sent: Friday, April 29, 2011 7:54 AM
+
+Here is my vote
+
+> ____3___ Leave preconditions/postconditions in 13.3.2 and
+> type_invariants in 13.3.3.
+>
+> ____2___ Move preconditions/postconditions to 6.1.1 and
+> type_invariants to 7.3.2.
+>
+> ____1___ Move preconditions/postconditions to 6.3.3 and
+> type_invariants to 7.3.2.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, April 29, 2011 9:58 AM
+
+> _HORRIBLE______ Leave preconditions/postconditions in 13.3.2 and
+> type_invariants in 13.3.3.
+>
+> _OK______ Move preconditions/postconditions to 6.1.1 and
+> type_invariants to 7.3.2.
+>
+> _OK______ Move preconditions/postconditions to 6.3.3 and
+> type_invariants to 7.3.2.
+>
+> _DNA______ Write in: move preconditions/postconditions to ____ and
+> type_invariants to _____.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, April 29, 2011 8:01 AM
+
+My votes are identical to Randy's above (and a lot of other folks).
+
+****************************************************************
+
+From: Steve Baird
+Sent: Friday, April 29, 2011 11:28 AM
+
+Ditto.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, April 29, 2011 1:35 PM
+
+If you want a vote from me that is in more conventional form, I echo this vote
+:-)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, April 29, 2011 2:16 PM
+
+Tucker didn't vote yet, but since we have a landslide, I'm declaring a winner,
+putting it into the AI, and moving on to the letter ballot.
****************************************************************
Questions? Ask the ACAA Technical Agent