CVS difference for ai05s/ai05-0123-1.txt

Differences between 1.5 and version 1.6
Log of other versions for file ai05s/ai05-0123-1.txt

--- ai05s/ai05-0123-1.txt	2009/02/05 05:28:07	1.5
+++ ai05s/ai05-0123-1.txt	2009/02/15 07:58:28	1.6
@@ -1720,3 +1720,185 @@
 a new source of bugs.
 
 ****************************************************************
+
+From: Pascal Leroy
+Sent: Saturday, December 6, 2008  5:23 AM
+
+Hmm, I am a bit lost in the discussion, with no wording in the AI and comforting
+statements like "It is not clear how this principle applies in a some corner cases".
+I'd like to understand what happens in a case like this:
+
+package P is
+   type T is private;
+private
+   package BS is new Ada.Strings.Bounded_Strings.Generic_Bounded_Length(80);
+   type T is new BS.Bounded_String;
+end P;
+
+Here Bounded_String has a user-defined "=", which is inherited by T.  Does that mean
+that the above example is illegal?  Hopefully I am confused and it is not, otherwise
+it is an horrendous incompatibility.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Sunday, December 7, 2008  8:27 AM
+
+We will definitely need to do some wording if we want to assess the incompatibility.
+Here is paragraph 15 from 4.5.2, with possible changes marked:
+
+   For a private type, if its full type is [tagged]{a record type},
+   predefined equality is defined in terms of the primitive equals
+   operator of the full type; [if the full type is untagged]{otherwise},
+   predefined equality for the private type is that of its full type.
+
+Given the above, I'm not sure we need to worry so much about private types.  I think
+the thing we need to worry about are record types.  For those, the predefined "=" may
+only be overridden visibly.  Overriding it privately or after the freezing point should
+be illegal.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, December 8, 2008  1:37 PM
+
+But "full type" is the problem here: how is that enforced in generics for private
+formals and when deriving from a private type whose full type is a record type? You
+can't break privacy to make such a legality check, so you have to assume the worst.
+Which is how it ends up applying to private types.
+
+Now, I think it is perfectly reasonable to forget the legality rules here and only
+make the change you note above. (That's a dynamic semantics rule, after all, it can
+ignore privacy.) The problem comes from trying to enforce points of declaration
+statically.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, December 9, 2008  12:16 AM
+
+> But "full type" is the problem here: how is that enforced in generics 
+> for private formals and when deriving from a private type whose full 
+> type is a record type?
+
+Hmmm.  The above doesn't really talk about a type *derived* from a private type.  In
+fact, I'm not sure the term "full type" is well defined for a type derived from a
+private type.  One model of a private type is that it is somewhat like a record type
+with the full type as its component type.  This would perhaps argue for making the
+primitive equality of any private type "composable." The tricky thing there is that
+you would get a different answer about composability depending on the "view" of the
+type.  That can't be good.  We really want composability to be a view-independent
+feature of the type.
+
+On the other hand, privacy argues that if you derive from a private type and there
+is no place within the immediate scope of the derivative where the parent type is
+non-private, then it should/could be treated as though it *might* be a record type,
+and any overriding of equality must satisfy the rules for a record type, and
+becomes composable.  This would apply within a generic body with a formal private
+type, where deriving from it could presume it *was* a record type, with composability
+provided to overridings of the equality operator.  Derivatives in the spec would
+follow the rules associated with the actual type, since we want all views of the
+derived type to follow the same rules.
+
+Alternatively, we could say that any derivative of a private type must follow the
+restrictions that apply to record types, namely no "late" or "private" overrides
+of equality, but that composability is only provided if the type is a record type
+"deep down." This alternative seems simpler.
+
+To summarize: composability is a dynamic semantics property and sees through privacy,
+applying to types whose "underlying" type is a record type. The legality restrictions
+on overriding "=" presume the worst, namely that when you don't have the full view
+of a private type then presume it *might* be a record type (even though you don't
+actually get any "benefit" from the restrictions unless the type is *really* a
+record type).
+
+This would ensure that only record types would have different dynamic semantics, and
+that *if* the equality operator is composable, it is the only equality operator that
+ever applies to the (record) type.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Tuesday, December 9, 2008  1:48 AM
+
+So we get a change in the dynamic semantics of predefined equality operators and a
+legality rule prohibiting "late" user-defined equality operators in some cases.
+
+It seems like we need other changes as well if you still want to treat squirreling
+renames and abstract equality operators as they were discussed in earlier posts.
+
+What is your current thinking about these issues?
+
+I'm just trying to understand the full extent of this AI without glossing over any
+details.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, December 9, 2008  8:20 AM
+
+I think we still want squirreling via renames and require overriding or inherit
+abstractness, as appropriate, if a component has an abstract, composable, equality.
+I presumed that was independent of these other legality issues, but perhaps not...
+
+****************************************************************
+
+From: Steve Baird
+Sent: Tuesday, December 9, 2008  9:26 AM
+
+I was thinking about an interaction between the rule you described for the predefined
+equality operator of a private type and squirreling renames.
+
+In this example,
+
+    package Pkg is
+        type T is private;
+        function Eq1 (L, R : T) return Boolean renames "=";
+    private
+        type T is record F1, F2 : Integer; end record;
+
+        function Eq2 (L, R : T) return Boolean renames "=";
+        function "=" (L, R : T) return Boolean;
+    end Pkg;
+
+we have decided that a call to Eq2 should not invoke the user-defined "=" operator. What
+about a call to Eq1?
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, December 9, 2008  9:50 AM
+
+I would hope we get the same answer if we add "tagged"
+to the record declaration.  One key goal is to make tagged and untagged records work
+the same way, at least with respect to equality, so there are fewer perverse incentives
+to make a record type tagged just so that it "works right."  I really don't want us to
+end up in a situation where tagged record equality works one way, untagged record
+equality works a second way, and non-record equality works a third way.
+
+I realize tagged types have private extensions, which don't really have an analogy
+in the non-tagged world, but hopefully untagged derivation would work very much like
+null tagged record extensions with respect to equality, whether the parent type is a
+visible record type or a private type whose full type is a record type.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, December 9, 2008  8:24 PM
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, December 9, 2008  8:24 PM
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, December 9, 2008  8:24 PM
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, December 9, 2008  8:24 PM
+
+****************************************************************

Questions? Ask the ACAA Technical Agent