CVS difference for ais/ai-00108.txt

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

--- ais/ai-00108.txt	2000/06/02 00:23:26	1.8
+++ ais/ai-00108.txt	2000/06/20 04:22:42	1.9
@@ -208,10 +208,9 @@
 if they have defaults. If @i<T> is a tagged type, the tag is not included.
 @dby
 For untagged derived types, the Write or Read attribute of the parent type is
-inherited if it was directly specified for some ancestor type; otherwise, the
-default implementation of the attribute is used. For other derived types, the
-Write or Read attribute is not inherited; the default implementation is always
-used.
+inherited as specified in 13.1; otherwise, the default implementation of the
+attribute is used. For tagged derived types, the Write or Read attribute is not
+inherited; the default implementation is always used.
 
 The default implementation of Write and Read attributes is defined as follows:@hr
 For elementary types, the representation in terms of stream elements is
@@ -221,9 +220,12 @@
 aggregate order for a record. Bounds are not included in the stream if @i<T> is
 an array type. If @i<T> is a discriminated type, discriminants are included only
 if they have defaults. If @i<T> is a tagged type, the tag is not included.
-For nonlimited type extensions, the Write or Read attribute for the parent type
-is called, followed by the Write or Read attribute of each non-inherited
-component, in canonical order.
+For type extensions, the Write or Read attribute for the parent type
+is called, followed by the Write or Read attribute of each component of the
+extension part, in canonical order. For a limited type extension, if the
+attribute of any ancestor type has been directly specified and the attribute of
+any ancestor type of any of the limited extension components has not been
+specified, the attribute of @i<T> shall be directly specified.
 
 !corrigendum 13.13.02(25)
 
@@ -231,11 +233,10 @@
 Unless overridden by an @fa<attribute_definition_clause>, these subprograms
 execute as follows:
 @dby
-For untagged derived types, the Output or Input attribute of the parent type is
-inherited if it was directly specified for some ancestor type; otherwise, the
-default implementation of the attribute is used. For other derived types, the
-Output or Input attribute is not inherited; the default implementation is always
-used.
+For untagged derived types, the Output or Input attribute of the parent type
+is inherited as specified in 13.1; otherwise, the default implementation of
+the attribute is used. For tagged derived types, the Output or Input attribute
+is not inherited; the default implementation is always used.
 
 The default implementation of the Output and Input operations execute as
 follows:
@@ -258,8 +259,7 @@
 implementations for these operations. An @fa<attribute_reference> for one of
 these attributes is illegal if the type is limited, unless the attribute
 has been specified by an @fa<attribute_definition_clause> or (for a type
-extension) all of the attributes called by the default implementation can be
-referenced by this rule. For an
+extension) the attribute has been specified for an ancestor type. For an
 @fa<attribute_definition_clause> specifying one of these attributes, the
 subtype of the Item parameter shall be the base subtype if scalar, and the
 first subtype otherwise. The same rule applies to the result of the Input
@@ -932,5 +932,454 @@
 a user *really* wants inheritance without the extension components: just add an
 attribute_clause for the appropriate routine (presumably inherited as well - it
 has to be primitive for the parent type).
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, June 01, 2000 9:25 PM
+
+> Despite Tucker's violation of the our corrigendum rule (if you want a
+> wording change, you have to propose one), I've made an attempt to rewrite
+> this AI to address his concerns. I've also added points 3 and 5 from AI-195
+> to the discussion of this AI, as they are addressed in the corrigendum
+> wording.
+
+Thanks for taking the time to do this.  See below for comments.
+>
+> Here is my latest cut at the wording:
+>
+> Replace 13.1(15) by the following (the first paragraph is unchanged from the
+> previous Corrigendum):
+>
+> A derived type inherits each type-related aspect of representation of its
+> parent type that was directly specified before the declaration of the
+> derived type, or (in the case where the parent is derived) that was
+> inherited by the parent type from the grandparent type. A derived subtype
+> inherits each subtype-specific aspect of representation of its parent
+> subtype that was directly specified before the declaration of the derived
+> type, or (in the case where the parent is derived) that was inherited by the
+> parent subtype from the grandparent subtype, but only if the parent subtype
+> statically matches the first subtype of the parent type. An inherited aspect
+> of representation is overridden by a subsequent representation item that
+> specifies the same aspect of the type or subtype.
+>
+> In contrast, whether operational aspects are inherited for a derived type
+> depends on the specific aspect. When operational aspects are inherited for a
+> derived type, aspects that were directly specified before the declaration of
+> the derived type, or (in the case where the parent is derived) that were
+> inherited by the parent type from the grandparent type are inherited. An
+> inherited operational aspect is overridden by a subsequent operational item
+> that specifies the same aspect of the type.
+
+Do you think it would be useful to establish a default?
+E.g., unless stated otherwise in this standard, operational attributes
+are (not?) inherited by derived types.
+
+I wonder whether this whole thing could be simplified by defining something
+like "an aspect supports inheritance" to mean all of the gobbledygook
+about being specified before the point of derivation.  Then there is
+no need to repeat all that stuff everytime.  Otherwise, I fear there
+will be little bugs in your wording (see below for examples) when
+all we are trying to say is that it supports inheritance.
+
+> Add after 13.1(18):
+>
+> If an operational aspect is specified for an entity (meaning that it is
+> either directly specified or inherited), then that aspect of the entity is
+> as specified. Otherwise, the aspect of the entity has the default value
+> determined by the specific aspect.
+
+Is the above paragraph really necessary?  This sounds like a "to be pedantic"
+section to be included in the AARM only.  Perhaps if it was combined
+with establishing a default rule on operational attribute inheritance,
+it wouldn't sound so silly.
+
+> Replace 13.3(75) by:
+>
+> S'External_Tag  S'External_Tag denotes an external string representation for
+> S'Tag; it is of type String. External_Tag may be specified for a specific
+> tagged type via an attribute_definition_clause; the expression of such a
+> clause shall be static. The default external tag representation is
+> implementation-defined. See 3.9.2 and 13.13.2. The value of External_Tag is
+> never inherited[; the default value is always used unless
+> it is directly specified for a type].
+>
+> Replace 13.13.2(9) by:
+>
+> For untagged derived types, the Write or Read attribute of the parent type
+> is inherited if it was directly specified for some ancestor type; otherwise,
+> the default implementation of the attribute is used. For other derived
+> types, the Write or Read attribute is not inherited; the default
+> implementation is always used.
+
+Why say "For other derived types" when "For tagged derived types" is
+equivalent?  Another reason to switch to this wording is that the above
+paragraph has "otherwise..." and then "For other ..."
+That seems bound to cause confusion.
+Perhaps even better than "For tagged derived types" might be
+"For type extensions..."
+
+This paragraph also seems to have one of the "little bugs" I mentioned
+above because it says it is "inherited if it was directly specified
+for some ancestor type" but omits the discussion about the specification
+happening before the derivation.  Again, I think switching to something
+simple like "For untagged derived types, the Write and Read attributes
+support inheritance; for tagged derived types, the attributes are
+not inherited."
+
+> The default implementation of Write and Read attributes is defined as
+> follows:
+> For elementary types, the representation in terms of stream elements is
+> implementation defined. For composite types, the Write or Read attribute for
+> each component is called in a canonical order. The canonical order of
+> components is last dimension varying fastest for an array, and positional
+> aggregate order for a record. Bounds are not included in the stream if T is
+> an array type. If T is a discriminated type, discriminants are included only
+> if they have defaults. If T is a tagged type, the tag is not included. For
+> type extensions, the Write or Read attribute for the parent type is called,
+> followed by the Write or Read attribute of each non-inherited
+> component, in canonical order.
+
+Remember that discriminants are also "components."  For tagged types,
+they never have defaults, so it is safe to say "... of each non-inherited
+non-discriminant component..." (safe to say, yes; easy to say, no ;-).
+Or even better: "... of each component of the extension part ..."
+
+> Replace 13.13.2(25) by:
+>
+> For untagged derived types, the Output or Input attribute of the parent type
+> is inherited if it was directly specified for some ancestor type; otherwise,
+> the default implementation of the attribute is used. For other derived
+> types, the Output or Input attribute is not inherited; the default
+> implementation is always used.
+
+Again, why not say "For tagged derived types..." (or "For type extensions...").
+Also another one of the "little bugs" appears here.  Again, an
+alternative is "For untagged derived types, the Output and Input
+attributes support inheritance; for tagged derived types, the
+Output and Input attributes are not inherited."
+
+>
+> The default implementation of the Output and Input operations execute as
+> follows:
+>
+> Replace 13.13.2(36) by:
+>
+> The stream-oriented attributes may be specified for any type via an
+> attribute_definition_clause. All nonlimited types have default
+> implementations for these operations. An attribute_reference for one of
+> these attributes is illegal if the type is limited, unless the attribute has
+> been specified by an attribute_definition_clause or (for a type extension)
+> all of the attributes called by the default implementation can be referenced
+> by this rule.
+
+This doesn't seem quite right.  Suppose the type is a limited private
+extension of a type with specified stream attributes.  How do you
+know whether it is legal to call the attributes on the extension?
+I suggest the following:  If a limited tagged type specifies a Write or Read
+attribute, then the corresponding attribute may be legally called
+on any non-abstract descendant.  However, the default implementation of the
+stream attribute on such a descendant is (effectively) abstract if its
+parent type or an extension component does not have a legally callable
+corresponding attribute, in which case the attribute *must* be
+directly specified.  (This is analogous to the rule for functions
+with controlling results.)
+
+Furthermore, I would suggest that Output and Input piggy back automatically
+on Write and Read, even for limited types:
+If the Read attribute of a type can legally be called, then the Input
+attribute has a non-abstract default implementation; similarly,
+if the Write attribute of a type can legally be called, then
+the Output attribute has a non-abstract default implementation.
+
+> ... For an
+> attribute_definition_clause specifying one of these attributes, the subtype
+> of the Item parameter shall be the base subtype if scalar, and the first
+> subtype otherwise. The same rule applies to the result of the Input
+> function.
+>
+>
+> (The changes previously proposed for 13.13.2(26-27) are removed.)
+> ...
+> 13.13.2(36) needed wording to allow calling Read and Write for limited type
+> extensions when all of the
+> attributes that make up the extension exist.
+
+See above for comments on the "privacy violation" aspects of this
+proposal.  I think it can be fixed by adopting rules analogous to
+those for functions with controlling results.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, June 02, 2000 5:12 PM
+
+> > Replace 13.1(15) by the following (the first paragraph is unchanged from the
+> > previous Corrigendum):
+> >
+> > A derived type inherits each type-related aspect of representation of its
+> > parent type that was directly specified before the declaration of the
+> > derived type, or (in the case where the parent is derived) that was
+> > inherited by the parent type from the grandparent type. A derived subtype
+> > inherits each subtype-specific aspect of representation of its parent
+> > subtype that was directly specified before the declaration of the derived
+> > type, or (in the case where the parent is derived) that was inherited by the
+> > parent subtype from the grandparent subtype, but only if the parent subtype
+> > statically matches the first subtype of the parent type. An inherited aspect
+> > of representation is overridden by a subsequent representation item that
+> > specifies the same aspect of the type or subtype.
+> >
+> > In contrast, whether operational aspects are inherited for a derived type
+> > depends on the specific aspect. When operational aspects are inherited for a
+> > derived type, aspects that were directly specified before the declaration of
+> > the derived type, or (in the case where the parent is derived) that were
+> > inherited by the parent type from the grandparent type are inherited. An
+> > inherited operational aspect is overridden by a subsequent operational item
+> > that specifies the same aspect of the type.
+>
+> Do you think it would be useful to establish a default?
+> E.g., unless stated otherwise in this standard, operational attributes
+> are (not?) inherited by derived types.
+
+Not really. It wouldn't save much more than one line in the current situation
+(the added line in 13.3(75).) OTOH, it might be helpful if we ever try to add
+another one of these. What does everyone else think?
+
+> I wonder whether this whole thing could be simplified by defining something
+> like "an aspect supports inheritance" to mean all of the gobbledygook
+> about being specified before the point of derivation.  Then there is
+> no need to repeat all that stuff everytime.  Otherwise, I fear there
+> will be little bugs in your wording (see below for examples) when
+> all we are trying to say is that it supports inheritance.
+
+I thought that too; in fact, that was what I originally tried to do. And failed
+to come up with anything that made sense. That was partially because I couldn't
+come up with a term that seemed to have the right meaning. "An aspect supports
+inheritance" probably would work for defining the term, but I don't see how to
+use it after it was defined.
+
+I was thinking that these two paragraphs defines formally what it means to
+inherit an aspect. Then the use of the word "inherits" in other places was meant
+to invoke these paragraphs.
+
+I suppose we could try something like:
+
+---
+
+If a type related aspect is @i<inherited> @defn2(inherit, an aspect) for a
+derived type, only aspects that were directly specified before the declaration
+of the derived type, or (in the case where the parent is derived) that were
+inherited by the parent type from the grandparent type are inherited. If a
+subtype related aspect is @i<inherited> for a derived subtype, only aspects of
+the parent subtype that were directly specified before the declaration of the
+derived type, or (in the case where the parent is derived) that were inherited
+by the parent type from the grandparent type, but only if the parent subtype
+statically matches the first subtype of the parent type are inherited. An
+inherited aspect is overridden by a subsequent aspect item that specifies the
+same aspect of the type or subtype.
+
+Aspects of representation are always inherited [as described above]. In
+contrast, whether operational aspects are inherited depends on the specific
+aspect.
+
+----
+
+This wording could stand improvement! If you don't like this, please suggest
+something better! Please? :-)
+
+> > Add after 13.1(18):
+> >
+> > If an operational aspect is specified for an entity (meaning that it is
+> > either directly specified or inherited), then that aspect of the entity is
+> > as specified. Otherwise, the aspect of the entity has the default value
+> > determined by the specific aspect.
+>
+> Is the above paragraph really necessary?  This sounds like a "to be pedantic"
+> section to be included in the AARM only.  Perhaps if it was combined
+> with establishing a default rule on operational attribute inheritance,
+> it wouldn't sound so silly.
+
+Well, it's necessary, because you pointed out that "specified" has a specific
+meaning. However, that meaning is only defined for representation aspects in
+13.1(16-18), and we can't reuse those paragraphs to define it for operational
+aspects (because of 13.1(18), which is just outright wrong for stream attributes
+[and always has been - there should have been an AI on that, too, except that no
+one ever really believed it.]) And we need to use "specified" in 13.13.2, so
+leaving it undefined is not really an option.
+
+Without the definition of "specified", it's pretty silly, but then again, so are
+13.1(16-18), and someone thought *they* needed to be in the RM.
+
+A suggestion for an improvement here is welcome as well...
+
+> > Replace 13.13.2(9) by:
+> >
+> > For untagged derived types, the Write or Read attribute of the parent type
+> > is inherited if it was directly specified for some ancestor type; otherwise,
+> > the default implementation of the attribute is used. For other derived
+> > types, the Write or Read attribute is not inherited; the default
+> > implementation is always used.
+>
+> Why say "For other derived types" when "For tagged derived types" is
+> equivalent?
+
+Because that was the way it previously was done (except in reverse). I certainly
+have no objection to this change (I'll make it in the AI).
+
+> Another reason to switch to this wording is that the above
+> paragraph has "otherwise..." and then "For other ..."
+> That seems bound to cause confusion.
+> Perhaps even better than "For tagged derived types" might be
+> "For type extensions..."
+
+I don't like that change, because it always leads me to ask "what about tagged
+derived types that aren't extensions?". Of course, after thinking about it, I
+remember that there aren't any such things, but it *always* breaks my train of
+thought.
+
+> This paragraph also seems to have one of the "little bugs" I mentioned
+> above because it says it is "inherited if it was directly specified
+> for some ancestor type" but omits the discussion about the specification
+> happening before the derivation.  Again, I think switching to something
+> simple like "For untagged derived types, the Write and Read attributes
+> support inheritance; for tagged derived types, the attributes are
+> not inherited."
+
+No, that phrase "if it was directly specified for some ancestor type" is
+intended to be ADDED to all of the stuff in 13.1(15/1). It is trying to deal
+with the changing discriminants problem, which means we never want to inherit a
+default implemented aspect. (That's point 5 of AI-00195.)
+
+It seems that the revised wording for 13.1(15/1) seems to say that only
+specified aspects are inherited. Indeed, the original wording seems to say this
+as well. In that case, point 5 of AI-00195 is just a confirmation -- it doesn't
+change anything except some poorly worded discussion material in AI-00108.
+
+Assuming the previously proposed change for 13.1(15/1), and assuming that
+default values for aspects are never inherited, then we could simply say:
+
+---
+
+For untagged derived types, the Write or Read attribute of the parent type is
+inherited as specified in 13.1; otherwise, the default implementation of the
+attribute is used. For tagged derived types, the Write or Read attribute is not
+inherited; the default implementation is always used.
+
+---
+
+Is this better?
+
+
+> > The default implementation of Write and Read attributes is defined as
+> > follows:
+> > For elementary types, the representation in terms of stream elements is
+> > implementation defined. For composite types, the Write or Read attribute for
+> > each component is called in a canonical order. The canonical order of
+> > components is last dimension varying fastest for an array, and positional
+> > aggregate order for a record. Bounds are not included in the stream if T is
+> > an array type. If T is a discriminated type, discriminants are included only
+> > if they have defaults. If T is a tagged type, the tag is not included. For
+> > type extensions, the Write or Read attribute for the parent type is called,
+> > followed by the Write or Read attribute of each non-inherited component, in
+> > canonical order.
+>
+> Remember that discriminants are also "components."  For tagged types,
+> they never have defaults, so it is safe to say "... of each non-inherited
+> non-discriminant component..." (safe to say, yes; easy to say, no ;-).
+> Or even better: "... of each component of the extension part ..."
+
+Well, that wording is unchanged from the last three versions of this AI...but
+you're right of course. I've changed it to the latter version.
+
+> > Replace 13.13.2(25) by:
+> >
+> > For untagged derived types, the Output or Input attribute of the parent type
+> > is inherited if it was directly specified for some ancestor type; otherwise,
+> > the default implementation of the attribute is used. For other derived
+> > types, the Output or Input attribute is not inherited; the default
+> > implementation is always used.
+>
+> Again, why not say "For tagged derived types..." (or "For type extensions...").
+> Also another one of the "little bugs" appears here.  Again, an
+> alternative is "For untagged derived types, the Output and Input
+> attributes support inheritance; for tagged derived types, the
+> Output and Input attributes are not inherited."
+
+I would use (with all of the caveats above):
+
+----
+
+For untagged derived types, the Output or Input attribute of the parent type is
+inherited as specified in 13.1; otherwise, the default implementation of the
+attribute is used. For tagged derived types, the Output or Input attribute is
+not inherited; the default implementation is always used.
+
+----
+
+> > Replace 13.13.2(36) by:
+> >
+> > The stream-oriented attributes may be specified for any type via an
+> > attribute_definition_clause. All nonlimited types have default
+> > implementations for these operations. An attribute_reference for one of
+> > these attributes is illegal if the type is limited, unless the attribute has
+> > been specified by an attribute_definition_clause or (for a type extension)
+> > all of the attributes called by the default implementation can be referenced
+> > by this rule.
+>
+> This doesn't seem quite right.  Suppose the type is a limited private
+> extension of a type with specified stream attributes.  How do you
+> know whether it is legal to call the attributes on the extension?
+
+I wanted to define this in 13.13.2(9) so there wasn't a problem, but that would
+have caused nasty forward reference. I then tried here, which I didn't think
+about much .
+
+> I suggest the following:  If a limited tagged type specifies a Write or Read
+> attribute, then the corresponding attribute may be legally called
+> on any non-abstract descendant.  However, the default implementation of the
+> stream attribute on such a descendant is (effectively) abstract if its
+> parent type or an extension component does not have a legally callable
+> corresponding attribute, in which case the attribute *must* be
+> directly specified.  (This is analogous to the rule for functions
+> with controlling results.)
+
+OK, let's try the following:
+
+The stream-oriented attributes may be specified for any type via an
+attribute_definition_clause. All nonlimited types have default
+implementations for these operations. An attribute_reference for one of
+these attributes is illegal if the type is limited, unless the attribute has
+been specified by an attribute_definition_clause or (for a type extension)
+the attribute has been directly specified for an ancestor type.
+
+Then add the following to 13.13.2(9):
+
+For a limited type extension, if the attribute of any ancestor type has been
+directly specified and the attribute of any ancestor type of any of the limited
+extension components has not been specified, the attribute of @i<T> shall be
+directly specified.
+
+---
+
+This is bit different than Tucker's suggestion, mainly so that there is no
+requirement to specify an attribute if the parent attribute wasn't specified.
+I also used "specified" (in the sense of 13.1(18/1) - the paragraph Tucker would like to get rid of) rather than "callable" - which would require a definition. This gets a bit messy because limited type extension's attributes can be callable without being
 "specified" (inherited or directly specified); but in that case, some ancestor type must have been directly specified.
+
+
+> Furthermore, I would suggest that Output and Input piggy back automatically
+> on Write and Read, even for limited types:
+> If the Read attribute of a type can legally be called, then the Input
+> attribute has a non-abstract default implementation; similarly,
+> if the Write attribute of a type can legally be called, then
+> the Output attribute has a non-abstract default implementation.
+
+This seems like a good idea, but it's going well beyond the AI, or even what is
+currently in AI-00195. I don't want to bog the corrigendum down at the last
+minute with good ideas... I suggest that we add that to AI-195.
+
+Clearly, this wouldn't conflict with the current wording (which defines that
+these always use the default implementation, but leaves them uncallable for
+limited types). But I'm not sure it is useful for the implementation burden --
+Input is a function after all, and limited functions aren't very useful.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent