CVS difference for ais/ai-00251.txt

Differences between 1.31 and version 1.32
Log of other versions for file ais/ai-00251.txt

--- ais/ai-00251.txt	2005/05/15 23:41:36	1.31
+++ ais/ai-00251.txt	2005/06/16 23:47:15	1.32
@@ -1,5 +1,6 @@
-!standard 03.04    (02)                            05-05-05   AI95-00251/20
+!standard 03.04    (02)                            05-06-04   AI95-00251/21
 !standard 02.09    (02)
+!standard 03.02    (04)
 !standard 03.02.01 (02)
 !standard 03.04    (03)
 !standard 03.04    (08)
@@ -7,6 +8,8 @@
 !standard 03.04    (35)
 !standard 03.04.01 (02)
 !standard 03.04.01 (10)
+!standard 03.07    (01)
+!standard 03.07    (08)
 !standard 03.09.03 (04)
 !standard 03.09.03 (05)
 !standard 03.09.04 (01)
@@ -191,6 +194,10 @@
 
        interface
 
+3.2 Types and Subtypes
+
+Add "interface types" to the list in 3.2(4).
+
 3.2.1 Type Declarations
 
 Add to syntax
@@ -244,6 +251,9 @@
     is not itself a descendant of any other type. Every untagged type has a
     unique ultimate ancestor.
 
+3.7 Discriminants
+
+In 3.7(1) and 3.7(8), change "array" to "array or interface".
 
 3.9.3 Abstract Types and Subprograms
 
@@ -453,12 +463,12 @@
       * If two or more homographs are implicitly declared at the same place:
 
         - If one is a non-null non-abstract subprogram, then it overrides
-          all which are null or abstract subprograms.
+          those that are null or abstract subprograms.
 
         - If all are null procedures or abstract subprograms, then any null
           procedure overrides all abstract subprograms; if more than one
-          homograph remains that is not thus overridden, then one is chosen
-          arbitrarily to override the others.
+          such homograph remains that is not thus overridden, then one is
+          chosen arbitrarily to override the others.
 
 
 	AARM Note: Discussion: It is intended that in the case where the
@@ -511,10 +521,10 @@
 
     If two or more homographs are implicitly declared at the same place (and
     not overridden by a non-overridable declaration) then at most one shall be
-    a non-null non-abstract subprogram. If all are null or abstract, then all
-    of the null subprograms shall be fully conformant with one another. If all
-    are abstract, then all of the subprograms shall be fully conformant with
-    one another.
+    a non-null non-abstract subprogram. If all are null procedures or abstract
+    subprograms, then all of the null procedures shall be fully conformant
+    with one another. If all are abstract subprograms, then all of the
+    subprograms shall be fully conformant with one another.
 
     All of the above Legality Rules also apply to dispatching operations
     declared in the visible part of an instance of a generic unit. However,
@@ -959,6 +969,20 @@
 !comment @dinsl
 !comment @b<interface>
 
+!corrigendum 3.2(4)
+
+@drepl
+The composite types are the @i<record> types, @i<record extensions>, @i<array>
+types, @i<task> types, and @i<protected> types. A @i<private> type or
+@i<private extension> represents a partial view (see 7.3) of a type, providing
+support for data abstraction. A partial view is a composite type.
+@dby
+The composite types are the @i<record> types, @i<record extensions>, @i<array>
+types, @i<interface> types, @i<task> types, and @i<protected> types. A
+@i<private> type or @i<private extension> represents a partial view (see 7.3)
+of a type, providing support for data abstraction. A partial view is a
+composite type.
+
 !corrigendum 3.2.1(4)
 
 @drepl
@@ -1066,6 +1090,38 @@
 is not itself a descendant of any other type. Every untagged type has a unique
 ultimate ancestor.
 
+!corrigendum 3.7(1)
+
+@drepl
+A composite type (other than an array type) can have discriminants, which
+parameterize the type. A @fa<known_discriminant_part> specifies the
+discriminants of a composite type. A discriminant of an object is a component
+of the object, and is either of a discrete type or an access type. An
+@fa<unknown_discriminant_part> in the declaration of a partial view of a type
+specifies that the discriminants of the type are unknown for the given view;
+all subtypes of such a partial view are indefinite subtypes.
+@dby
+A composite type (other than an array or interface type) can have discriminants, which
+parameterize the type. A @fa<known_discriminant_part> specifies the
+discriminants of a composite type. A discriminant of an object is a component
+of the object, and is either of a discrete type or an access type. An
+@fa<unknown_discriminant_part> in the declaration of a partial view of a type
+specifies that the discriminants of the type are unknown for the given view;
+all subtypes of such a partial view are indefinite subtypes.
+
+!corrigendum 3.07(8)
+
+@drepl
+A @fa<discriminant_part> is only permitted in a declaration for a
+composite type that is not an array type (this includes generic formal
+types). A type declared with a @fa<known_discriminant_part> is called a
+@i<discriminated> type, as is a type that inherits (known) discriminants.
+@dby
+A @fa<discriminant_part> is only permitted in a declaration for a
+composite type that is not an array or interface type (this includes generic
+formal types). A type declared with a @fa<known_discriminant_part> is called a
+@i<discriminated> type, as is a type that inherits (known) discriminants.
+
 !corrigendum 3.9.3(04)
 
 @drepl
@@ -1097,7 +1153,7 @@
 
 @i<@s8<Static Semantics>>
 
-An interface type (also called an "interface") is a specific abstract
+An interface type (also called an @i<interface>) is a specific abstract
 tagged type that is defined by an @fa<interface_type_definition>.
 
 An interface type has no components.
@@ -1145,7 +1201,7 @@
 @dby
 The @i<tested type> of a membership test is the type of the @fa<range> or the
 type determined by the @fa<subtype_mark>. If the tested type is tagged, then
-then the @fa<simple_expression> shall resolve to be of a type that is
+the @fa<simple_expression> shall resolve to be of a type that is
 convertible (see 4.6) to the tested type; if untagged, the expected
 type for the @fa<simple_expression> is the tested type.
 
@@ -1337,9 +1393,9 @@
 @dinss
 @xbullet<If two or more homographs are implicitly declared at the same place:>
 @xinbull<If one is a non-null non-abstract subprogram, then it overrides
-all which are null or abstract subprograms.>
+those that are null or abstract subprograms.>
 @xinbull<If all are null procedures or abstract subprograms, then any null
-procedure overrides all abstract subprograms; if more than one homograph
+procedure overrides all abstract subprograms; if more than one such homograph
 remains that is not thus overridden, then one is chosen arbitrarily to override
 the others.>
 
@@ -1374,10 +1430,10 @@
 
 If two or more homographs are implicitly declared at the same place (and not
 overridden by a non-overridable declaration) then at most one shall be a
-non-null non-abstract subprogram. If all are null or abstract, then all of the
-null subprograms shall be fully conformant with one another. If all are
-abstract, then all of the subprograms shall be fully conformant with one
-another.
+non-null non-abstract subprogram. If all are null procedures or abstract
+subprograms, then all of the null procedures shall be fully conformant with
+one another. If all are abstract subprograms, then all of the subprograms
+shall be fully conformant with one another.
 
 All of the above Legality Rules also apply to dispatching operations declared
 in the visible part of an instance of a generic unit. However, they do not
@@ -5364,6 +5420,320 @@
 along the lines of C.5 (Discard_Names) or 13.2 (Pack).
 
 Comments?
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, June  6, 2005  12:36 PM
+
+I'm using draft 11.8 of the [A]ARM.
+
+3.9.4(7/2):
+
+7/2   {AI95-00251-01} [An interface type has no components.]
+
+    7.a/2 Proof: This follows from the syntax.
+
+That doesn't seem right to me.  It follows from the syntax, plus the rule saying
+interfaces can't have discriminants, plus the rule saying interfaces can't have
+non-interface ancestors.  Maybe we should just say "An interface type shall not
+have components.", and move it to "Legality Rules".
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, June  6, 2005  7:12 PM
+
+It seems weird to me to make this into a legality rule.
+I would rather it remain a consequence of other rules.
+I would suggest we beef up the "Proof" rather than
+making this into a legality rule.
+
+I suppose I could be convinced otherwise, but it
+feels to me like it should be syntactically "obvious"
+that an interface doesn't have any components.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, June  6, 2005  9:25 PM
+
+Tucker writes:
+
+> It seems weird to me to make this into a legality rule.
+> I would rather it remain a consequence of other rules.
+> I would suggest we beef up the "Proof" rather than
+> making this into a legality rule.
+
+That's OK, but we don't actually have a rule preventing discriminants on
+interfaces. It seems that we assumed that this one would take care of it in
+3.7, and assumed that this one was taken care of by 3.9.4. So which one
+should change? (Bob seems to want both, which is silly.)
+
+> I suppose I could be convinced otherwise, but it
+> feels to me like it should be syntactically "obvious"
+> that an interface doesn't have any components.
+
+Right, but Bob is also thinking about discriminants and inherited
+components. I think that fixing 3.7(8) to not allow discriminant parts on
+interfaces and beefing up the Reason would be enough.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, June  7, 2005  3:33 AM
+
+I agree with Tucker that we should beef up the proof, but surely there is
+no reason to move this rule to the "Legality Rules" section, as it is just
+a consequence of other rules.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, June  7, 2005  4:01 AM
+
+> That's OK, but we don't actually have a rule preventing
+> discriminants on interfaces.
+
+Oh, I see, I missed that.
+
+> It seems that we assumed that
+> this one would take care of it in 3.7, and assumed that this
+> one was taken care of by 3.9.4. So which one should change?
+
+I'd say do the same as for array, i.e. 3.7(1/2) and 3.7(8/1).
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Wednesday, June  8, 2005  7:04 AM
+
+> I suppose I could be convinced otherwise, but it
+> feels to me like it should be syntactically "obvious"
+> that an interface doesn't have any components.
+
+The problem are the discriminants, which are definitely not
+excluded syntactically. And I had a real hard time finding a
+rule that excluded them for interface types. And, if I recall
+correctly, D.11 did not have such a rule.
+
+I hope that D 11.8 has one; if anyone appeals to 3.9.4(7/2),
+7/2   {AI95-00251-01} [An interface type has no components.]
+I then side with Bob that this should be a legality rule.
+
+(I do agree that the syntax is obvious wrt. the "other components".)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, June  8, 2005  12:22 PM
+
+I believe we could disallow them syntactically,
+in the sense that we could have a "syntax" rule that
+an interface type shall not have a discriminant part.
+Don't ask for the LALR grammar for that one... ;-)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, June  8, 2005  2:16 PM
+
+> I hope that D 11.8 has one; if anyone appeals to 3.9.4(7/2),
+> 7/2   {AI95-00251-01} [An interface type has no components.]
+> I then side with Bob that this should be a legality rule.
+
+Nope, I think we agree that 3.7(1) and 3.7(8) should put "interfaces" next
+to "arrays". We didn't try to disallow them syntactically for arrays, it
+doesn't make much sense to do so for interfaces. (And I suspect we'd have
+contract problems for generics.)
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, June  6, 2005 12:33 PM
+
+Randy asked me to review the new RM, through section 7.5, which I did.
+I have 12 questions that I will e-mail to the group.
+The rest of the comments are minor issues, which I will send to Randy.
+
+----------------
+
+Here's the first question.
+
+I'm using draft 11.8 of the [A]ARM.
+
+Are interface types considered to be composite types?  Should they?
+
+3.2(4/2) says no:
+
+4/2   {AI95-00326-01} The composite types are the record types, record
+extensions, array types, task types, and protected types.
+
+3.2(2) says:
+
+2     {class (of types)} Types are grouped into classes of types, reflecting
+the similarity of their values and primitive operations.
+{language-defined class (of types)} There exist several language-defined
+classes of types (see NOTES below). {elementary type} Elementary types are
+those whose values are logically indivisible; {composite type} {component}
+composite types are those whose values are composed of component values.
+{aggregate: See also composite type}
+
+Interface types have no components.  But neither to null record types,
+and those are composite.  It seems to me that every type should be either
+elementary or composite.  And interface types are (sort of) like private types,
+which are considered composite even when the full type is not.  So it seems to
+me interface types should be composite.
+
+3.7(1/2):
+
+1/2   {AI95-00326-01} [{discriminant} {type parameter: See discriminant}
+{parameter: See also discriminant} A composite type (other than an array type)
+can have discriminants, which parameterize the type.
+
+Should "other than an array type" be "other than an array or interface type"?
+
+Same issue in 3.7(8/1).
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, June  6, 2005  1:33 PM
+
+> Are interface types considered to be composite types?  Should they?
+
+They should be.  Clearly int_type'Class contains lots of composite
+types, so it would be weird if int_type itself wasn't considered
+composite.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, June  6, 2005  2:42 PM
+
+> I'm using draft 11.8 of the [A]ARM.
+
+Just so everyone understands, this was a special version created
+specifically so that Bob could start his review. It wasn't published any
+other way.
+
+> Are interface types considered to be composite types?  Should they?
+
+Certainly Tucker's revision of the type classification chart includes
+interfaces under composite types.
+
+If says something else in the Standard, it probably should be fixed.
+
+****************************************************************
+
+From: Stephen W. Baird
+Sent: Monday, June  6, 2005  3:02 PM
+
+> Are interface types considered to be composite types?  Should they?
+>
+
+3.9.4(1/2) states that "An interface type is an abstract tagged type ...".
+Does that answer the question, or am I confused?
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, June  6, 2005  4:08 PM
+
+Steve said:
+
+> Bob Duff <bobduff@sofcheck.com> wrote on 06/06/2005 10:32:58 AM:
+> >
+> > Are interface types considered to be composite types?  Should they?
+> >
+>
+> 3.9.4(1/2) states that "An interface type is an abstract tagged type ...".
+> Does that answer the question, or am I confused?
+
+No, I don't think that works.  I don't see any place that says "all
+tagged types are composite".
+
+3.2(4/2) says:
+
+4/2   {AI95-00326-01} The composite types are the record types, record
+extensions, array types, task types, and protected types.
+
+and then 3.2(4.1/2) contradicts that by saying so are incomplete and
+private types.  I'll let the contradiction slide, although "The
+composite types include..." might be more correct than "The composite
+types are" -- I didn't say so, because it seemed insufficiently broken.
+
+But I do think we need to say somewhere that interfaces are composite.
+
+By the way, para 31 of the Forward:
+
+The main classes of types are
+elementary types (comprising enumeration, numeric, and access types) and
+composite types (including array and record types).
+
+makes it clear that the intent is that every type is either elementary
+or composite, and not both.  And, as Tucker pointed out, there's the
+"closed under derivation" property of classes to uphold.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, June  6, 2005  4:19 PM
+
+> > Are interface types considered to be composite types?  Should they?
+>
+> 3.9.4(1/2) states that "An interface type is an abstract tagged type ...".
+> Does that answer the question, or am I confused?
+
+You're confused, because the paragraph that Bob referenced which defines
+composite types mentioned neither tagged types nor abstract types. I think
+it is pretty clear that all tagged types should be composite (in the current
+language), but it appears that the Ada 9X wanted to leave the door open for
+tagged elementary types in the future, so they avoided ever saying that.
+
+We need to fix the paragraph that defines composite types. It's odd that
+Tucker noticed that the type chart (3.2(12-13)) was confusing, but didn't
+notice that the normative wording didn't match the chart. Of course, I
+shouldn't talk; I never checked, either.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, June  7, 2005  3:23 AM
+
+> Are interface types considered to be composite types?  Should they?
+
+I agree with others that they should be.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, June 13, 2005 11:53 PM
+
+> 3.2(4/2) says:
+>
+> 4/2   {AI95-00326-01} The composite types are the record types, record
+> extensions, array types, task types, and protected types.
+>
+> and then 3.2(4.1/2) contradicts that by saying so are incomplete and
+> private types.  I'll let the contradiction slide, although "The
+> composite types include..." might be more correct than "The composite
+> types are" -- I didn't say so, because it seemed insufficiently broken.
+
+No, that's not quite correct. We're talking about incomplete *views* and
+partial *views* (incomplete and private types are misnamed; there really isn't
+such a thing). So, while a *type* can be composite, it doesn't make a lot of
+sense to talk about a *view* being a *composite type*. The wording was changed
+from the Ada 95 wording for this reason (in part because Tucker complained a
+lot). It says that "an incomplete or partial view is considered a composite
+type", not that it *is* a composite type. What this means is that for the
+purposes of legality rules, such a view is treated as a composite type. But
+that doesn't make the view composite; that's a property of the type (and thus
+depends on the full type). These views don't appear in the chart of
+language-defined classes for this reason.
+
+To summarize: a view can be *considered* composite; but only a full type *is*
+composite.
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent