CVS difference for ais/ai-10217.txt

Differences between 1.4 and version 1.5
Log of other versions for file ais/ai-10217.txt

--- ais/ai-10217.txt	2001/09/08 03:35:06	1.4
+++ ais/ai-10217.txt	2001/09/19 00:04:39	1.5
@@ -4793,3 +4793,80 @@
 
 *************************************************************
 
+From: Pascal Leroy
+Sent: Thursday, September 13, 2001, 3:24 AM
+
+I have updated AIs 195, 229, 255 and 271 which were on my action items list.
+The updated AIs are on the web site.
+
+271 was updated to reflect Bob's detailed analysis of the last cut of this AI.
+So now the abstract is a separate compilation unit again (I actually started
+from Tuck's original write-up) and I have removed most of the restrictions
+(Bob's message was full of questions of the kind "why do we want to disallow
+this?" and I must say that I was unable to answer most of these questions).  I
+am sure this proposal is going to look a bit extreme to some people, but at
+least it's a basis for discussing the topic at the next meeting.  Please, no
+quibbling on the syntax: it's much more important to look at the semantics at
+this point.
+
+*************************************************************
+
+From: Tucker Taft
+Sent: Thursday, September 13, 2001, 3:55 PM
+
+It actually looks pretty good, now that all the restrictions are
+removed.  Your example needs a minor tweak -- you are repeating
+the declaration of the access types.  I don't believe repeating
+the declaration is required (nor is it allowed) with the new proposal.
+
+I'm not sure whether you answered the question of about the legality of
+a "with P abstract" when a "with P" was already in scope.
+I think I had suggested that a "with P abstract" should be
+illegal if a "with P" was already applicable.  I suppose
+since you didn't disallow it, it is legal, but it might
+be worth a note.  One reason to disallow it is that
+when you see a "with P abstract" on a package Q one tends
+to presume that "P" may safely "with Q".  However, if
+the abstract of Q had a "with P" then it would not be legal
+for P to "with Q."  Hence, allowing the (redundant) "with P abstract"
+on Q could turn out to be misleading, which is something
+we generally try to minimize.  (I'll admit that this is
+not totally compelling. ;-)
+
+*************************************************************
+
+From: Pascal Leroy
+Sent: Friday, September 14, 2001, 3:23 AM
+
+> Your example needs a minor tweak -- you are repeating
+> the declaration of the access types.  I don't believe repeating
+> the declaration is required (nor is it allowed) with the new proposal.
+
+True.  The example needs fixing.
+
+> I'm not sure whether you answered the question of about the legality of
+> a "with P abstract" when a "with P" was already in scope.
+> I think I had suggested that a "with P abstract" should be
+> illegal if a "with P" was already applicable.  I suppose
+> since you didn't disallow it, it is legal, but it might
+> be worth a note.
+
+Yes, my intent was that the "with P abstract" should have no effect.  I could
+live with making it illegal, but...
+
+> One reason to disallow it is that
+> when you see a "with P abstract" on a package Q one tends
+> to presume that "P" may safely "with Q".  However, if
+> the abstract of Q had a "with P" then it would not be legal
+> for P to "with Q."  Hence, allowing the (redundant) "with P abstract"
+> on Q could turn out to be misleading, which is something
+> we generally try to minimize.  (I'll admit that this is
+> not totally compelling. ;-)
+
+... it is currently legal for the spec and body of Q to have a "with P", and I
+guess you could apply the same reasoning: when you see "with P" on the body of
+Q, you could assuming that P may safely "with Q", but it's not the case.  So
+your argument is indeed "not totally compelling".
+
+*************************************************************
+

Questions? Ask the ACAA Technical Agent