CVS difference for ai12s/ai12-0112-1.txt

Differences between 1.31 and version 1.32
Log of other versions for file ai12s/ai12-0112-1.txt

--- ai12s/ai12-0112-1.txt	2021/02/13 04:55:41	1.31
+++ ai12s/ai12-0112-1.txt	2021/05/30 00:35:10	1.32
@@ -3223,3 +3223,112 @@
 
 ***************************************************************
 
+From: John Barnes
+Sent: Wednesday, February 3, 2021  4:04 AM
+
+I am making an attempt to rewrite my book before I get even older.
+
+The behaviour of the container subprograms are now all described by pre and 
+post conditions. Although that is hopefully correct, it does not follow that
+the average human reader will find all of them easy to digest. 
+
+Moreover, when it comes to adding further description in the text after the 
+package specification the pre and post conditions are repeated because they 
+are part of the subprogram specification. But it does take a lot of space. If
+the new RM is printed then it will be even bigger.
+
+Perhaps we could omit the pre and post conditions when discussing the 
+individual subprograms or maybe repeat them in the AARM only.
+
+However, I expect we have to put up with it.
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, February 3, 2021  4:04 PM
+
+> I am making an attempt to rewrite my book before I get even older.
+
+Let me know if you figure out how to make that work... ;-)
+ 
+>... Perhaps we could omit the pre and post conditions when discussing the 
+individual subprograms or maybe repeat them in the AARM only.
+
+The English descriptions have been pared down a bit to avoid redundancy, 
+so it seems important to repeat the Pre/Post information.
+
+On the other hand, I could see showing other (non Pre/Post) aspects only 
+in the package spec, and leave them off in the individual discussions, since
+they don't really address functionality per se.
+
+>However, I expect we have to put up with it.
+
+Perhaps a middle ground, as suggested above?
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, February 3, 2021  10:38 PM
+
+>>... Perhaps we could omit the pre and post conditions when discussing 
+>>the individual subprograms or maybe repeat them in the AARM only.
+
+>The English descriptions have been pared down a bit to avoid 
+>redundancy, so it seems important to repeat the Pre/Post information.
+
+Right. We discussed this at the ARG level, and the decision was to repeat
+the information for that reason. I think it is rather too late to revisit 
+that (it would be a massive amount of work to change all of the containers 
+clauses).
+
+>On the other hand, I could see showing other (non Pre/Post) aspects 
+>only in the package spec, and leave them off in the individual 
+>discussions, since they don't really address functionality per se.
+
+Those are almost never more than one line; the lengthy items are always Pre 
+or Post (and often both). Probably half of the routines don't have any at all.
+I doubt it would shorten anything noticably; they're less than 10% of the 
+added lines and less than 4% of the total.
+
+But it would complicate creating and maintaining these things, by increasing 
+the differences between the spec and the subprogram descriptions. They're 
+already not 100% the same, since the indentation is different (the spec 
+routines are indented one level, while the descriptions are not). But that 
+and the indexing markers are the only (intentional) difference.
+
+Moreover, we'd have to somehow tell readers that some aspects were omitted.
+Even doing that, I'd expect that we'd get occasional complaints about missing
+aspects. After all, people complained about the on-line formatting of AIs so 
+much that I had to get rid of it, even though I repeatedly told everyone how 
+it worked (that is, fully automated based on plain text).
+
+>>However, I expect we have to put up with it.
+
+>Perhaps a middle ground, as suggested above?
+
+That seems like quite a bit of work for not much gain. One can't just delete 
+the lines as some of them end the constructs and we don't want these ending 
+with commas (not to mention we have to move the closing markers for the 
+editing constructs). As mentioned above, I don't think anyone would be able 
+to tell the difference in the size of the Standard, but probably someone would
+complain that the specs don't match the descriptions.
+
+***************************************************************
+
+From: John Barnes
+Sent: Thursday, February 4, 2021  5:52 AM
+
+I agree. Foolish suggestion. Forget it.
+
+Incidentally are we planning to publish the RM with Springer?
+
+***************************************************************
+
+From: Tullio Vardanega
+Sent: Thursday, February 4, 2021  6:51 AM
+
+Speaking with my Ada-Europe hat on: yes, I believe that publishing the RM with 
+Springer would be expected, but there are other stakeholders who have their 
+say in this matter.
+
+***************************************************************

Questions? Ask the ACAA Technical Agent