CVS difference for ai05s/ai05-0115-1.txt
--- ai05s/ai05-0115-1.txt 2010/12/15 00:10:58 1.6
+++ ai05s/ai05-0115-1.txt 2011/02/16 06:15:22 1.7
@@ -1518,3 +1518,618 @@
****************************************************************
+From: Tucker Taft
+Sent: Friday, November 19, 2011 3:46 PM
+
+Here is some possible wording to add to 7.3.1, probably after paragraph 5, as an
+alternative way to address AI05-0115. As a reminder, here are paragraphs 3, 4,
+and 5 of 7.3.1:
+
+ For a composite type, the characteristics (see 7.3) of the type are
+ determined in part by the characteristics of its component types. At
+ the place where the composite type is declared, the only
+ characteristics of component types used are those characteristics
+ visible at that place. If later immediately within the declarative
+ region in which the composite type is declared additional characteristics become
+ visible for a component type, then any corresponding characteristics
+ become visible for the composite type. Any additional predefined
+ operators are implicitly declared at that place. If there is no such
+ place, then additional predefined operators are not declared at all,
+ but they still exist.
+
+ The corresponding rule applies to a type defined by a
+ derived_type_definition, if there is a place immediately within the
+ declarative region in which the type is declared where additional
+ characteristics of its parent type become visible.
+
+ [Redundant: For example, an array type whose component type is limited private
+ becomes nonlimited if the full view of the component type is
+ nonlimited and visible at some later place immediately within the
+ declarative region in which the array type is declared. within the
+ immediate scope of the array type. In such a case, the predefined
+ "=" operator is implicitly declared at that place, and assignment is
+ allowed after that place.]
+
+Here is a possible additional paragraph 7.3.1(5.1)
+
+ {At a given point, the current view of a type is a /descendant/ of
+ the view of an ancestor from which it currently inherits its
+ characteristics. In particular, a type is a descendant of the full
+ view of some ancestor of its parent type only if the current view
+ it has of its parent is a descendant of the full view of that
+ ancestor.}
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Monday, February 14, 2011 6:08 PM
+
+A while back, Tucker proposed an alternative approach for addressing AI05-115:
+
+> Here is some possible wording to add to 7.3.1, probably after
+> paragraph 5, as an alternative way to address AI05-0115. As a
+> reminder, here are paragraphs 3, 4, and 5 of 7.3.1:
+>
+> ...
+>
+> Here is a possible additional paragraph 7.3.1(5.1)
+>
+> {At a given point, the current view of a type is a /descendant/ of
+> the view of an ancestor from which it currently inherits its
+> characteristics. In particular, a type is a descendant of the full
+> view of some ancestor of its parent type only if the current view
+> it has of its parent is a descendant of the full view of that
+> ancestor.}
+
+It took me a while to get comfortable with this phrasing, but I think that this
+basically works, and is preferable to any other approaches that have been
+proposed.
+
+I just have a few small issues/questions regarding the wording:
+
+1. I wonder if it would be better to put this into 3.4.1, following the
+ paragraph (10/2) that defines descendant and ancestor? I think I prefer that
+ to putting it in 7.3.1.
+
+2. Normally inheritance is defined in terms of what you get from your direct
+ parent, not from some other ancestor, so I'm not sure that the notion of
+ inheriting characteristics from an ancestor is formally defined, though
+ informally I think it's clear what's meant. Maybe it's clear enough as is,
+ but one possibility is to add ", directly or indirectly" at the end of the
+ first sentence. But maybe that's being overly picky.
+
+3. I'm not sure that the current extension aggregate wording of 4.3.2(5/2) is
+ adequate for working with this definition of descendant. 4.3.1(14) seems to
+ work fine, but the extension aggregate rule doesn't mention the word
+ descendant, it only talks about deriving from the type of the ancestor part.
+ Should we adjust the wording so that it explicitly mentions descendants, or
+ is it OK as is?
+
+4. The last sentence should be marked Redundant.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February 14, 2011 6:57 PM
+
+> It took me a while to get comfortable with this phrasing, but I think
+> that this basically works, and is preferable to any other approaches
+> that have been proposed.
+
+I'm not so sure about that. We're trying to fix a problem with record and
+extension aggregates (only); this is changing the rules for inheritance of
+everything by changing the definition of a widely used term (descendant). This
+sounds like a recipe for disaster. I cannot even understand how this corresponds
+to existing use of the term "descendant", which is purely a derivation
+relationship.
+
+To take one example, this wording would appear to make the result of
+Ada.Tags.Descendant_Tag dependent on the view of the type in question at the
+time of the call. That way seems to lie madness.
+
+Similarly, I don't think we want to be changing the way characteristics are
+inherited in cases other than the one in question. It is just too risky; it is
+likely to cause new runtime dependencies that would add overhead for no good
+reason.
+
+So I can understand defining a new relationship that is view based, but I'm
+pretty certain we do not want to use the existing term "descendant" (at least by
+itself). Maybe something like "characteristics ancestor" or the like.
+
+> I just have a few small issues/questions regarding the wording:
+>
+> 1. I wonder if it would be better to put this into 3.4.1, following
+> the paragraph (10/2) that defines descendant and ancestor? I think I
+> prefer that to putting it in 7.3.1.
+
+As noted above, changing the meaning of "descendant" generally leads directly to
+madness. I think Tuck has the rule in the right place, but we need a different
+term.
+
+> 2. Normally inheritance is defined in terms of what you get from your
+> direct parent, not from some other ancestor, so I'm not sure that the
+> notion of inheriting characteristics from an ancestor is formally
+> defined, though informally I think it's clear what's meant. Maybe
+> it's clear enough as is, but one possibility is to add ", directly or
+> indirectly" at the end of the first sentence. But maybe that's being
+> overly picky.
+
+Not really. I think your additional wording is clarifying.
+
+> 3. I'm not sure that the current extension aggregate wording of
+> 4.3.2(5/2) is adequate for working with this definition of descendant.
+> 4.3.1(14) seems to work fine, but the extension aggregate rule doesn't
+> mention the word descendant, it only talks about deriving from the
+> type of the ancestor part.
+> Should we adjust the wording so that it explicitly mentions
+> descendants, or is it OK as is?
+
+Well, since using the term "descendants" is a non-starter in my book, the rules
+in question will definitely need changing to invoke the new term, whatever it
+is.
+
+> 4. The last sentence should be marked Redundant.
+
+Yup; definitely not important if it doesn't get marked.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, February 14, 2011 7:53 PM
+
+> I'm not so sure about that. We're trying to fix a problem with record
+> and extension aggregates (only); this is changing the rules for
+> inheritance of everything by changing the definition of a widely used term (descendant).
+> This sounds like a recipe for disaster. I cannot even understand how
+> this corresponds to existing use of the term "descendant", which is
+> purely a derivation relationship.
+
+I think you may be overstating this. We already have statements like the
+following (RM 7.3(7.3)):
+
+ the partial view shall be a descendant of an interface type (see 3.9.4)
+ if and only if the full type is a descendant of the interface type.
+
+Clearly we are acknowledging that a full view and a partial view might be
+descendants of different sets of types. With private extensions, the partial
+view has a specified ancestor, while the full view might have additional
+ancestors. So the point of this new wording is to specify the "descendant"
+relationship between views of types. In general "descendant" is part of static
+semantics. The "Descendant_Tag" operation is perhaps the anomaly here, in that
+it is translating a static semantic relationship into a dynamic semantic value.
+To do so we will clearly have to identify what views we are talking about, since
+we don't want the value to in fact depend on where the operation is called.
+
+> To take one example, this wording would appear to make the result of
+> Ada.Tags.Descendant_Tag dependent on the view of the type in question
+> at the time of the call. That way seems to lie madness.
+>
+> Similarly, I don't think we want to be changing the way
+> characteristics are inherited in cases other than the one in question.
+> It is just too risky; it is likely to cause new runtime dependencies
+> that would add overhead for no good reason.
+
+I think we are merely formalizing the relationship that already is presumed in
+rules having to do with all kinds of characteristics. Do you have an example of
+how this new wording conflicts with existing uses of the term "descendant"? The
+point was to formalize the definition of descendant, not introduce a new term
+and leave descendant vaguely defined.
+
+> So I can understand defining a new relationship that is view based,
+> but I'm pretty certain we do not want to use the existing term
+> "descendant" (at least by itself). Maybe something like
+> "characteristics ancestor" or the like.
+>
+>> I just have a few small issues/questions regarding the wording:
+>>
+>> 1. I wonder if it would be better to put this into 3.4.1, following
+>> the paragraph (10/2) that defines descendant and ancestor? I think I
+>> prefer that to putting it in 7.3.1.
+>
+> As noted above, changing the meaning of "descendant" generally leads
+> directly to madness. I think Tuck has the rule in the right place, but
+> we need a different term.
+>
+>> 2. Normally inheritance is defined in terms of what you get from your
+>> direct parent, not from some other ancestor, so I'm not sure that the
+>> notion of inheriting characteristics from an ancestor is formally
+>> defined, though informally I think it's clear what's meant. Maybe
+>> it's clear enough as is, but one possibility is to add ", directly or
+>> indirectly" at the end of the first sentence. But maybe that's being
+>> overly picky.
+>
+> Not really. I think your additional wording is clarifying.
+
+I agree.
+
+>
+>> 3. I'm not sure that the current extension aggregate wording of
+>> 4.3.2(5/2) is adequate for working with this definition of
+>> descendant. 4.3.1(14) seems to work fine, but the extension
+>> aggregate rule doesn't mention the word descendant, it only talks
+>> about deriving from the type of the ancestor part.
+>> Should we adjust the wording so that it explicitly mentions
+>> descendants, or is it OK as is?
+>
+> Well, since using the term "descendants" is a non-starter in my book,
+> the rules in question will definitely need changing to invoke the new
+> term, whatever it is.
+
+Descendant and ancestor are defined in terms of one another, which is another
+advantage of clarifying the definition of "descendant" rather than some new
+term.
+
+>> 4. The last sentence should be marked Redundant.
+>
+> Yup; definitely not important if it doesn't get marked.
+
+I'm confused by this. I don't believe the second sentence is implied by the
+first, but rather is further refining what it says.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February 14, 2011 8:42 PM
+
+> I think you may be overstating this. We already have statements like
+> the following (RM 7.3(7.3)):
+>
+> the partial view shall be a descendant of an interface type (see 3.9.4)
+> if and only if the full type is a descendant of the interface type.
+>
+> Clearly we are acknowledging that a full view and a partial view might
+> be descendants of different sets of types.
+
+I don't see this, exactly. Now that you point it out, this rule also seems to be assuming something that is not borne out by the standard.
+
+Even so, my understanding of this rule is that it only depends on the derivation relationship of the parent and progenitors. In particular, I never expected it to have any relationship to visibility. By bringing visibility into the equation, at the very l
east you are forcing compiler writers to prove that visibility cannot matter. (I think that is true in this case because this rule itself makes all interfaces visible; but the effort to prove that is significant.)
+
+> With private extensions, the partial view has a specified ancestor,
+> while the full view might have additional ancestors. So the point of
+> this new wording is to specify the "descendant" relationship between
+> views of types. In general "descendant" is part of static semantics.
+
+This is true, and I see your point. (This whole business of different ancestors is madness, but it is commonly used, so we're stuck with it.) But then we have a serious problem, because this is not true in existing rules or implementations.
+
+> The "Descendant_Tag" operation is perhaps the anomaly here, in that it
+> is translating a static semantic relationship into a dynamic semantic
+> value. To do so we will clearly have to identify what views we are
+> talking about, since we don't want the value to in fact depend on
+> where the operation is called.
+
+Right, but the problem here is that this is the *first* rule that came up when I searched for "descendant". This wasn't daisy picking! If we're going to make a change as significant as this, someone is going to have to read all 55 clauses that the search
engine shows contains this term. And that is a massive job.
+
+...
+> > To take one example, this wording would appear to make the result of
+> > Ada.Tags.Descendant_Tag dependent on the view of the type in
+> > question at the time of the call. That way seems to lie madness.
+> >
+> > Similarly, I don't think we want to be changing the way
+> > characteristics are inherited in cases other than the one in question.
+> > It is just too risky; it is likely to cause new runtime dependencies
+> > that would add overhead for no good reason.
+>
+> I think we are merely formalizing the relationship that already is
+> presumed in rules having to do with all kinds of characteristics.
+
+The rules for characteristics are all over the map, and are defined individually
+(and for the most part, without much sanity IMHO). You are claiming that anyone
+understands how those work? Good luck.
+
+> Do you have an example of how this new wording conflicts with existing
+> uses of the term "descendant"? The point was to formalize the
+> definition of descendant, not introduce a new term and leave
+> descendant vaguely defined.
+
+I pointed out one with my first probe into the standard. (The only clause before
+it in the search engine results is the one that defines the term.) I'm not going
+to spend two hours reading the other 53 clauses to see if any are affected;
+that's the responsibility of the proposer!
+
+If you want to go this route, I think you owe it to everyone to verify that it
+doesn't cause any problems beyond the one I stumbled into immediately.
+
+BTW, I agree with Gary that if you are going to make such a massive change to
+the language, it had better go in 3.4.1, so that it is clear that the "obvious"
+definition is not accurate.
+
+...
+> >> 3. I'm not sure that the current extension aggregate wording of
+> >> 4.3.2(5/2) is adequate for working with this definition of
+> >> descendant. 4.3.1(14) seems to work fine, but the extension
+> >> aggregate rule doesn't mention the word descendant, it only talks
+> >> about deriving from the type of the ancestor part.
+> >> Should we adjust the wording so that it explicitly mentions
+> >> descendants, or is it OK as is?
+> >
+> > Well, since using the term "descendants" is a non-starter in my
+> > book, the rules in question will definitely need changing to invoke
+> > the new term, whatever it is.
+>
+> Descendant and ancestor are defined in terms of one another, which is
+> another advantage of clarifying the definition of "descendant" rather
+> than some new term.
+
+Gary's point is that 4.3.2(5/2) talks about "derived from" rather than
+descendant or ancestor. It has to be rewritten in any case; I don't see how
+"derived from" can be view dependent.
+
+> >> 4. The last sentence should be marked Redundant.
+> >
+> > Yup; definitely not important if it doesn't get marked.
+>
+> I'm confused by this. I don't believe the second sentence is implied
+> by the first, but rather is further refining what it says.
+
+The sentence starts "In particular", which says that it is giving an example of
+the effects of the first sentence. (Call it a "refinement", it's the same
+thing.) Moreover, the type from which "it currently inherits its
+characteristics" seems well-defined (although somewhat informal). If you *don't*
+think the first sentence is well-defined enough to stand alone, then I don't
+think you should give it at all. Just give the second sentence and be done with
+it.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, February 14, 2011 9:11 PM
+
+>> Descendant and ancestor are defined in terms of one another, which is
+>> another advantage of clarifying the definition of "descendant" rather
+>> than some new term.
+>
+> Gary's point is that 4.3.2(5/2) talks about "derived from" rather than
+> descendant or ancestor. It has to be rewritten in any case; I don't
+> see how "derived from" can be view dependent.
+
+"Derived from" is view dependent, if you think about partial views or formal
+derived types. For example, in 7.3(8) it says:
+
+ ... The full view of a private extension shall be derived (directly or
+ indirectly) from the ancestor type.
+
+Clearly "derived from" is a view-specific relationship in this sentence.
+
+>
+>>>> 4. The last sentence should be marked Redundant.
+>>>
+>>> Yup; definitely not important if it doesn't get marked.
+>>
+>> I'm confused by this. I don't believe the second sentence is implied
+>> by the first, but rather is further refining what it says.
+>
+> The sentence starts "In particular", which says that it is giving an
+> example of the effects of the first sentence. (Call it a "refinement",
+> it's the same
+> thing.) Moreover, the type from which "it currently inherits its
+> characteristics" seems well-defined (although somewhat informal). If
+> you
+> *don't* think the first sentence is well-defined enough to stand
+> alone, then I don't think you should give it at all. Just give the
+> second sentence and be done with it.
+
+These two sentences are serving two different purposes. The first sentence
+links "descendant" with "inherited characteristics." The second specifies the
+rule that a type is a descendant of the full view of its ancestor only where it
+has a view of its parent that is a descendant of the ancestor's full view. Both
+are needed and neither is redundant.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February 14, 2011 9:18 PM
+
+...
+> > Do you have an example of how this new wording conflicts with
+> > existing uses of the term "descendant"? The point was to formalize
+> > the definition of descendant, not introduce a new term and leave
+> > descendant vaguely defined.
+>
+> I pointed out one with my first probe into the standard. (The only
+> clause before it in the search engine results is the one that defines
+> the term.) I'm not going to spend two hours reading the other 53
+> clauses to see if any are affected; that's the responsibility of the
+> proposer!
+>
+> If you want to go this route, I think you owe it to everyone to verify
+> that it doesn't cause any problems beyond the one I stumbled into
+> immediately.
+
+I think it would be very valuable to everyone (presuming that we go this way),
+that every use of "descendant" and "ancestor" is examined for whether visibility
+makes a difference, and that result is recorded in the AI (and better still, in
+the AARM) for future readers. Otherwise, we are at risk of introducing nasty
+problems. (As Bob likes to say, we don't have regression tests for the
+Standard.)
+
+I can start this by saying that the uses in 3.9 (Descendant_Tag) should not
+depend on visibility, but have the potential to do so (so there is a problem).
+The uses in 4.9 (descendant of a formal type) don't appear to depend on
+visibility (can't imagine how a formal type could be private). The uses in 3.4.1
+are the definition of the term.
+
+Based on the amount of time I spent figuring those three out, I'm not going to
+look at the other 52 clauses that contain the term! I've got a lot of other work
+to do to get ready for the meeting...
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, February 15, 2011 2:10 AM
+
+...
+> > Gary's point is that 4.3.2(5/2) talks about "derived from" rather
+> > than descendant or ancestor. It has to be rewritten in any case; I
+> > don't see how "derived from" can be view dependent.
+>
+> "Derived from" is view dependent, if you think about partial views or
+> formal derived types. For example, in 7.3(8) it says:
+>
+> ... The full view of a private extension shall be derived (directly
+> or
+> indirectly) from the ancestor type.
+>
+> Clearly "derived from" is a view-specific relationship in this
+> sentence.
+
+Huh? It's only view-specific in the sense that everything is view-specific:
+if the entity in question doesn't exist yet, you might depend on the view.
+Otherwise, it's a purely syntactic relationship.
+
+I really don't understand why you keep giving examples that give the same answer
+whether or not you consider any views, and then claim that there is some
+relevance of views. Of course, the near complete absence of mentioning views in
+the standard makes it impossible to even guess what the intent *really* was;
+perhaps I just don't understand some magic somewhere.
+
+> >>>> 4. The last sentence should be marked Redundant.
+> >>>
+> >>> Yup; definitely not important if it doesn't get marked.
+> >>
+> >> I'm confused by this. I don't believe the second sentence is
+> >> implied by the first, but rather is further refining what it says.
+> >
+> > The sentence starts "In particular", which says that it is giving an
+> > example of the effects of the first sentence. (Call it a
+> > "refinement", it's the same
+> > thing.) Moreover, the type from which "it currently inherits its
+> > characteristics" seems well-defined (although somewhat informal). If
+> > you
+> > *don't* think the first sentence is well-defined enough to stand
+> > alone, then I don't think you should give it at all. Just give the
+> > second sentence and be done with it.
+>
+> These two sentences are serving two different purposes. The first
+> sentence links "descendant" with "inherited characteristics." The
+> second specifies the rule that a type is a descendant of the full view
+> of its ancestor only where it has a view of its parent that is a
+> descendant of the ancestor's full view. Both are needed and neither
+> is redundant.
+
+OK, but then I don't understand "In particular" here, if there isn't any
+relationship. Moreover, I don't understand why we care about "inherited
+characteristics" at all. We're surely not going to change any rules regarding
+them (if you want to do that, you have to find and delete all of the old rules,
+because we can't have two sets of rules with [almost] the same effect). The
+rules in 4.3.1 and 4.3.2 that we are trying to fix say nothing whatsoever about
+"characteristics". If it ain't broke, don't fix it!
+
+I can believe that the descendant relationship has some problem (although really
+I'm skeptical that the problem actually lies there), but let's not start
+changing stuff for no reason at all. If you want to go beyond the targeted
+fixes, you really need good reasons, and I haven't heard any to this point.
+
+P.S. But I may have just lost my mind.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, February 15, 2011 2:18 AM
+
+...
+> > Gary's point is that 4.3.2(5/2) talks about "derived from" rather
+> > than descendant or ancestor. It has to be rewritten in any case; I
+> > don't see how "derived from" can be view dependent.
+>
+> "Derived from" is view dependent, if you think about partial views or
+> formal derived types. For example, in 7.3(8) it says:
+>
+> ... The full view of a private extension shall be derived (directly or
+> indirectly) from the ancestor type.
+>
+> Clearly "derived from" is a view-specific relationship in this
+> sentence.
+
+Even if I grant that "derived from" is view dependent somehow, that's
+irrelevant. The whole reason that this bug comes up is because we don't know
+what it means in *this* case. You are proposing to change the definition of
+"descendant", which would fix the 4.3.1 rules. But that can't change the 4.3.2
+rules that depend on "derived from", since "descendant" is defined in terms of
+"derived from", not vice-versa.
+
+The claim that we don't need to change this wording is essentially the same as
+saying that there is no bug currently -- and that is clearly not true.
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Tuesday, February 15, 2011 4:56 PM
+
+> > These two sentences are serving two different purposes. The first
+> > sentence links "descendant" with "inherited characteristics." The
+> > second specifies the rule that a type is a descendant of the full
+> > view of its ancestor only where it has a view of its parent that is
+> > a descendant of the ancestor's full view. Both are needed and
+> > neither is redundant.
+>
+> OK, but then I don't understand "In particular" here, if there isn't
+> any relationship. Moreover, I don't understand why we care about
+> "inherited characteristics" at all. We're surely not going to change
+> any rules regarding them (if you want to do that, you have to find and
+> delete all of the old rules, because we can't have two sets of rules
+> with [almost] the same effect). The rules in 4.3.1 and 4.3.2 that we
+> are trying to fix say nothing whatsoever about "characteristics". If it ain't broke, don't fix it!
+
+I certainly found the use of "In particular" leading me to believe that it's a
+specific consequence of rule stated in the preceding sentence. I thought I had
+convinced myself that it is a consequence, but evidently I'm confused about
+that. So if we keep any rule like this (and now I'm starting to have my doubts
+about doing that), it needs some revision since it's misleading as is.
+
+After thinking about this further today, I'm now finding myself puzzled as to
+how this even addresses the problem. I'm not managing to see how this
+definition fixes the problem of making the aggregates illegal, without at least
+making some kind of changes to the aggregate paragraphs, though exactly what
+sort of changes are needed I'm not sure. (However, this may just be due to the
+fact that I had really bad insomnia last night and only got 2-3 hours of sleep,
+so I'm not exactly in the clearest state of mind today.)
+
+> I can believe that the descendant relationship has some problem
+> (although really I'm skeptical that the problem actually lies there),
+> but let's not start changing stuff for no reason at all. If you want
+> to go beyond the targeted fixes, you really need good reasons, and I
+> haven't heard any to this point.
+
+Since we're both having misgivings about this approach of changing (or
+augmenting, or whatever) the definition of descendant, I'm not sure we should go
+further with this approach, at least for writing it up. I had some vain hope of
+trying to revise the AI to reflect Tucker's suggestion, but I'm afraid that I
+don't grok it well enough to do that at this point (not to mention being out of
+time...). Maybe we should just go back to the proposal based on a new "has
+known components" characteristic. On the other hand, perhaps if Tucker can
+clear up why this approach makes sense, maybe it's still viable. Will we be
+able to discuss this further at the meeting without having an AI version based
+on this wording?
+
+> P.S. But I may have just lost my mind.
+
+Ditto.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, February 15, 2011 5:12 PM
+
+> Since we're both having misgivings about this approach of changing (or
+> augmenting, or whatever) the definition of descendant, I'm not sure we
+> should go further with this approach, at least for writing it up.
+> I had some vain hope of trying to revise the AI to reflect Tucker's
+> suggestion, but I'm afraid that I don't grok it well enough to do that
+> at this point (not to mention being out of time...). Maybe we should
+> just go back to the proposal based on a new "has known components"
+> characteristic. On the other hand, perhaps if Tucker can clear up why
+> this approach makes sense, maybe it's still viable. Will we be able
+> to discuss this further at the meeting without having an AI version
+> based on this wording?
+
+We surely can discuss it. I sort of understand what Tucker is trying to do, but
+I fear the consequences of changing something widely used. But I agree that it
+probably isn't worth a full write-up right now.
+
+> > P.S. But I may have just lost my mind.
+>
+> Ditto.
+
+;-)
+
+****************************************************************
Questions? Ask the ACAA Technical Agent