!standard 7.3.1(5.2/3)                              13-05-08    AI12-0065-1/00
!class binding interpretation
!status work item 13-05-08
!status received 13-01-26
!priority Low
!difficulty Medium
!qualifier Omission
!subject All properties of a profile are defined by pragmas

!summary

** TBD.

!question

The example of AARM 7.3.1(5.a.1-4/3) doesn't seem to have much to do with the
paragraph 7.3.1(5.2/3) that precedes it. Moreover, that paragraph is supposed to
be redundant, but it claims that types can be descendants of incomplete views of
a type, which is not backed up by any other text in the standard.

Should this be clarified? (Yes.)


!recommendation

(See !summary.)

!wording

** TBD.

!discussion

The author of this question turns out to also have been the author of the
paragraph and AARM notes in question. Which means that there is no real hope of
figuring out what he was thinking. :-)

It's clear that 7.3.1(5.2/3) is intended to be a clarification rather than
the definition of anything; however, it doesn't seem to be clarifying anything,
especially with its mention of "incomplete view".

It appears to the editor that 7.3.1(5.1/3) sufficiently defines the normative
wording. Perhaps it would be best to junk 7.3.1(5.2/3) or move its content into
AARM notes. Moreover, the example in AARM 7.3.1(5.a.1-4/3) does not illustrate
the situation described in 7.3.1(5.2/3) very well (there is no ancestor that
is clearly not visible, although it is true for Root_Integer).

Here's hoping that the stuckee for this AI can figure out better wording.


!ACATS Test

!ASIS

No ASIS effect expected.


!appendix

From: Tucker Taft
Sent: Saturday, January 26, 2013  5:51 PM

A question came up which related to the example given in paras 5.a.1 .. 5.a.4 in
section 7.3.1.  After investigating it further, the confusion seems to be in
part related to the fact that these AARM paragraphs really relate to RM
paragraph 5.1/3, but they actually follow 5.2/3.  I'm not sure whether that is a
limitation in the tools, or just a bug.  In any case it is confusing, and if the
AARM paragraphs can't be moved, they should probably specify that they are an
example of the issue described by 5.1, rather than 5.2.

****************************************************************

From: Randy Brukardt
Sent: Saturday, January 26, 2013  7:23 PM

No tools limitation here, I put that example where the AI (AI05-0115-1)
specified that it get placed. The original AI author put that note there, in
version /08. And who was that author that specified such an apparently confusing
location? None other than S. Tucker Taft. :-) (That STT guy also revised this AI
twice more without moving this note, I had to assume its location was intended.)

There is no problem moving these paragraphs, I'll just do it silently (no
numbering changes are needed or will happen, and no text is changed) and put
this discussion into AI12-0005-1, the holder for all changes to the AARM.

****************************************************************

From: Randy Brukardt
Sent: Saturday, January 26, 2013  7:36 PM

Having looked at this more, I don't see the problem. I think STT version 1.0 was
correct in the placement of these paragraphs.

7.3.1(5.2/3) is a "redundant" clarification and amplification of 7.3.1(5.1/3),
and the examples of 7.3.1(5.a.1-4/3) appear to me to be the motivating example
for that clarification. Specifically, this example is illustrating "It is
possible for there to be places where a derived type is visibly a descendant of
an ancestor type, but not a descendant of even a partial view of the ancestor
type, because the parent of the derived type is not visibly a descendant of the
ancestor." The type T3 in this example is such a type, and the consequences that
it is legal to convert T3 to Integer, but T3 is not a numeric type (so no
literals or arithmetic).

My understanding of the intent was that everything in 7.3.1(5.2/3) follows from
7.3.1(5.1/3), but the example is supposed to be illustrating 7.3.1(5.2/3). To
the extent that it doesn't do so is probably the fault of STT version 1.0 -- who
apparently has confused STT version 2.0. (I'm not sure where an "incomplete
view" comes into this example, or any other for that matter. The text claims to
be redundant, so that should follow from other rules.)

Does any of the this make sense? (This whole descendant business is right on the
edge of insanity, so I might have gotten it wrong...) I would hope that STT
version 1.0 could be summoned to answer such questions, but that's probably
asking a lot. ;-)

****************************************************************

From: Tucker Taft
Sent: Sunday, January 27, 2013  8:37 AM

> ... Does any of the this make sense? (This whole descendant business
> is right on the edge of insanity, so I might have gotten it wrong...)
> I would hope that STT version 1.0 could be summoned to answer such
> questions, but that's probably asking a lot. ;-)

I guess either STT version 1.0 or STT version 2.0 needs to take credit for all
of this confusion, then.  Mea culpa.  The "incomplete view" comment is
particularly confusing for the current version of STT ...

Before we change anything here, we should probably discuss it at an ARG meeting
and decide how it might be better explained.

Thanks for delving into the history on this one!

****************************************************************

From: Randy Brukardt
Sent: Friday, April 12, 2013  10:54 PM

I was updating the test objective document for the aggregate clauses to include
all of the current rules, and I think I stumbled upon why this text is talking
about "incomplete views".

The rule 4.3.1(14) requires that the type of an aggregate be descended from a
record type through one of more record extensions. 4.3.1(5/3) is a similar rule
for extension aggregates. We want those rules to fail for cases like the one in
the example. Therefore, STT version 1.0 described that the hidden ancestor acts
like an incomplete view in this case -- which is not a record type or record
extension.

Unfortunately, this comes up in text that's supposedly redundant, and there
isn't a breath of anything about incomplete views anywhere in the normative
wording. And he failed to explain this reason in the associated AARM note.
Probably the text should say something like " In this case the derived type acts
like it is a descendant of an incomplete view of the ancestor." - the problem
being that the "considered to be" seems to suggest that that is the formal
effect as opposed to an informal way to think of the situation.

Of course, if this is an informal view, it then isn't obvious as to why this
triggers the 4.3.1(14) and 4.3.2(5/3) rules. (And it has to be informal if it is
redundant.) But it must trigger those rules -- we don't want to allow an
aggregate whose components aren't known -- that was the whole point of the AI
(being the original question).

So, probably a bit more wordsmithing is needed for 7.3.1(5.1-2/3). Hopefully STT
version 2.0 can figure it out.

****************************************************************

From: Randy Brukardt
Sent: Friday, April 12, 2013  11:30 PM

Another issue that strikes me with the wording of 7.3.1(5.2/3) is that it talks
about the "parent of the ancestor not being visibly  inherited from the
ancestor". But that's only part of the issue: we want to trigger 4.3.1(14) and
4.3.2(5/3) in any case where there are potentially components that are not
inherited from an ancestor. That can happen in cases (like the ones in the
question of AI05-0115-1) even when the derived ancestor is known; the problem is
that ancestor is a private view.

We need to use 4.3.1(14) and 4.3.2(5/3) to make these aggregates illegal because
we don't have any rules requiring components to be visible in aggregates. We
didn't want to have such rules because that would make legality depend on the
contents of the private part (if the full type is a null record, then there
aren't any hidden components in the aggregate, but we still don't want to allow
it).

In reading the normative wording in 7.3.1(5.1/3), it appears that this has the
correct effect. So the paragraph 7.3.1(5.2/3) appears to be more misleading than
illuminating.

It's worse because the AARM example doesn't illustrate the situation of that
paragraph very well: in this example, all of the ancestors are visible, but
there are characteristics that aren't visible because some of the ancestors are
partial views (via visibility). I think Tucker meant the "ancestor" that he was
thinking of in this example to be Root_Integer, but as this is implicit its
confusing to think about that, especially without it being mentioned anywhere.
(That's why he concentrates on numeric operations in the example, but it's just
as easy to think of that as a characteristic, the "ancestorness" only really
matters for literals.)

I think the AARM example needs to actually illustrate how a ancestor could be
invisible, without the crutch of Root_Integer. I can't actually make that work,
so I'd like to see such an example (maybe it needs more levels). That's
important, because if it can't be written, then I have to think that
7.3.1(5.2/3) is doing more harm than good, and an expanded AARM note would be
preferable. The text of 7.3.1(5.1/3) explains what happens with characteristics
well enough.

I hope this clarifies and does not confuse further!

****************************************************************