CVS difference for ais/ai-00083.txt

Differences between 1.8 and version 1.9
Log of other versions for file ais/ai-00083.txt

--- ais/ai-00083.txt	2000/03/27 18:17:33	1.8
+++ ais/ai-00083.txt	2000/03/28 01:25:55	1.9
@@ -1115,3 +1115,155 @@
 
 ****************************************************************
 
+From: Robert A Duff
+Sent: Monday, March 27, 2000 12:06 PM
+
+Robert,
+
+> Remember what we are talking about here is just one thing
+>
+> denial or approval of validatoin
+>
+> Nothing else is important.
+
+It seems to me that *users* of Ada are more important than validation
+issues, and uniformity in the case of controlled aggregates is of
+benefit to users.
+
+I understand your point, but I think there is plenty of precedent for
+making this sort of small change to fix what is clearly a bug in the
+language design.  I don't see it as an indication that the ARG is
+running amok.
+
+I would like to see a (required-to-pass) ACATS test for this feature.
+The "market" alone has not shown itself to be capable of forcing this
+kind of uniformity.
+
+****************************************************************
+
+From: John Barnes
+Sent: Monday, March 27, 2000 1:15 PM
+
+>> And since there is no way I can count the aggregate evaluations since
+>> they occur silently, the whole quest is lost. Well that's a shame.
+
+>If you type is not private, it is not remotely bulletproof -- all that it
+>takes to mess up your count is for someone to change it explicitly. So what
+>is the concern? At most this gives you one more way to mess things up.
+
+Nonsense, the count is not in the object, it is in the package
+defining the type and thus not visible to users. Privateness is a red
+herring.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Monday, March 27, 2000 2:26 PM
+
+John, I have read this paragraph five times, and I still don't understand it.
+Could you illustrate what you mean with a code example?
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, March 27, 2000 2:04 PM
+
+In John's example, he only has one count, which is an overall
+count of objects/values of the type.  In such a case, it is certainly
+true that the count can be hidden even though the controlled type
+is public.  I also agree with John that this shows that controlled
+types are not particularly good for this kind of application.
+
+However, I also will say that this is not the application for which
+they were designed.  They were designed to support treating objects
+with possible levels of indirection as a single conceptual object,
+so assignment did the appropriate amount of copying or reference
+counting of underlying levels of indirection, and storage was
+automatically reclaimed when the object went away.  This application
+works fine, and is probably the kind of application that should be
+used in examples of non-limited controlled types.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, March 27, 2000 2:22 PM
+
+That seems far too limited a view of why they were designed. perhaps that
+was Tuck's main purpose, but they have many other purposes (e.g. we use
+them internally for protected types, to make sure that various
+operating system resources such as locks, are released).
+
+****************************************************************
+
+From: Robert A Duff
+Sent: Monday, March 27, 2000 2:55 PM
+
+That's what *limited* controlled types are for.  I think Tuck was
+talking only about non-limited controlled types.
+
+By the way, remember the history?  Non-limited controlled types very
+nearly didn't make it into the language, which was not true of the
+limited kind.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, March 27, 2000 3:25 PM
+
+Responding to Robert Dewar:
+
+I am surprised that you would use *non-limited* controlled types
+for this purpose.  I certainly understand the resource management
+uses of *limited* controlled types, but non-limited controlled types
+seem most naturally designed for treating objects with levels of
+indirection as "first class citizens."
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, March 27, 2000 4:34 PM
+
+OK, point taken, yes, indeed these are of course limited types ...
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, March 27, 2000 1:46 PM
+
+<<Well, for what it is worth, there is an Annex H test which requires
+implementation of AI-83. So at least compilers which have validated Annex H
+have indeed been held to this requirement. I've even rejected petitions on
+the test based on approved AI-83; I think Dan Lehman did so as well. So we've
+been requiring this behavior for validation for quite a while.
+>>
+
+Sorry, I misread this, can you quote the test, since this claim is definitely
+interesting.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, March 27, 2000 1:45 PM
+
+But validation is never withheld for failing an annex test, so this is not
+nearly so critical. I must say I don't know what AI-83 is offhand, so I
+don't know whether this is fully comparable.
+
+I agree with Pascal that if we want to force uniformity, requiring
+Program_Error is more appropriate.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, March 27, 2000 1:44 PM
+
+<<I would like to see a (required-to-pass) ACATS test for this feature.
+The "market" alone has not shown itself to be capable of forcing this
+kind of uniformity.
+>>
+
+OK, then the disagreement is clear enough. I object to such a test and I
+think the ARG is overstepping its bounds by requiring such a test.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent