Version 1.4 of ai12s/ai12-0104-1.txt

Unformatted version of ai12s/ai12-0104-1.txt version 1.4
Other versions for file ai12s/ai12-0104-1.txt

!standard 4.1.6(4/3)          14-10-02 AI05-0104-1/02
!standard 4.1.6(17/3)
!class presentation 14-05-13
!status Corrigendum 2015 14-07-23
!status WG9 Approved 14-10-20
!status ARG Approved 7-0-0 14-06-28
!status work item 14-05-13
!status received 14-05-07
!priority Low
!difficulty Easy
!qualifier Clarification
!subject Overriding an aspect is undefined
!summary
A confusing sentence regarding changing aspects is replaced by a user note.
!question
4.1.6(4/3) uses some terminology that's not defined:
These aspects are inherited by descendants of T (including the class-wide type T'Class). The aspects shall not be overridden, but the functions they denote may be.
There is no such thing as overriding an aspect. It's probable that this was intended informally, but then we have an informal use and a formal use of the same term in the same sentence (the formal use is implicit in this wording, but it surely is there).
Should this be changed? (Yes.)
!recommendation
(See Summary.)
!wording
Modify 4.1.6(4/3):
These aspects are inherited by descendants of @i<T> (including the class-wide type @I<T>'Class). [The aspects shall not be overridden, but the functions they denote may be.]
Add after 4.1.6(7/3):
AARM Reason: This rule allows the replacement of the implementation of an indexing function and the addition of a new indexing function for a derived type, but not the removal of an indexing function. This is necessary so that indexing can be used on objects of T'Class. So long as the tag of O is that of its nominal subtype, we do not want T'Class(O)(I) to mean something different than O(I). Thus we cannot allow a change in the function identified. As T'Class(O)(I) expands into a dispatching call, we need to ensure that there is a body for each such function -- but it is OK for that body to be changed from the original body (that's just normal dispatching).
[Editor's note: I added this AARM note because the original mail thread saw some confusion over the reason for this rule. I'm not sure if there is a better way to describe that we don't want dynamically and statically tagged indexing doing different things when they both identify the same type.]
Add after 4.1.6(17/3):
Notes: 6 The Constant_Indexing and Variable_Indexing aspects cannot be redefined when inherited for a derived type, but the functions that they denote can be modified by overriding or overloading.
!discussion
The original text here is marked as redundant; the actual rule is given in 4.1.6(7/3). As such, it's obvious that this was intended to be explanatory text. But, as it's given in the normative rules, it's easy to wonder what it means formally. Moreover, as it is a forward reference, a reader may not realize that it isn't normative and try to figure out what rules it implies. By replacing it by a user note, we eliminate any confusion, and we can clarify the sentence so we're not mixing formal and informal uses of the same term.
!corrigendum 4.1.6(4/3)
Replace the paragraph:
These aspects are inherited by descendants of T (including the class-wide type T'Class). The aspects shall not be overridden, but the functions they denote may be.
by:
These aspects are inherited by descendants of T (including the class-wide type T'Class).
!corrigendum 4.1.6(17/3)
Insert after the paragraph:
When a generalized_indexing is interpreted as a constant (or variable) indexing, it is equivalent to a call on a prefixed view of one of the functions named by the Constant_Indexing (or Variable_Indexing) aspect of the type of the indexable_container_object_prefix with the given actual_parameter_part, and with the indexable_container_object_prefix as the prefix of the prefixed view.
the new paragraph:
NOTES
6 The Constant_Indexing and Variable_Indexing aspects cannot be redefined when inherited for a derived type, but the functions that they denote can be modified by overriding or overloading.
!ASIS
No changes needed.
!ACATS test
No test needed.
!appendix

From: Randy Brukardt
Sent: Wednesday, May 7, 2014 12:20 PM

Ed points out that 4.1.6(4/3) uses some terminology that's not defined:

"These aspects are inherited by descendants of T (including the class-wide type
T'Class). The aspects shall not be overridden, but the functions they denote
may be."

There is no such thing as overriding an aspect.

The second sentence here is intended to be an explanation of the intent of
following rules, and is marked as "redundant" in the AARM.

Still, we probably ought to use a different word than "overridden", which
appears to have a technical meaning when it does not.

I think "replaced" or "redefined" would be better. If it's confusing Ed, what
chance do ordinary readers have?

"The aspects shall not be {redefined}[overridden], but the functions they
denote may be {overridden}."

In the absence of objections, I'll just put this into the presentation AI.

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

From: Bob Duff
Sent: Wednesday, May 7, 2014 12:53 PM

> In the absence of objections, I'll just put this into the presentation AI.

I think I object.  I think "overridden" (in it's plain English,
not-defined-by-RM sense) is clearer than "redefined".  And even if that weren't
so, it seems like a gratuitous change.

I guess I'd like to hear from Ed what the real confusion is.
I mean, are there two possible interpretations of that rule, such that
different compilers might behave differently?  Example? If not, then "If it
ain't broke, don't fix it, and don't even spend time talking about fixing
it!"  ;-)

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

From: Ed Schonberg
Sent: Wednesday, May 7, 2014  1:01 PM

I was trying to understand the exact rule for inheritance of indexing aspects
for derived container types, and I found that statement curious, because it
says that you are not allowed to write the aspect but can still change its
meaning by overriding the named subprogram.
Excuse my density if I found that less than obvious. Overriding has otherwise
a precise meaning, so i wanted to know if there was some indication of what it
means for an aspect, but no such luck. Thatís why I asked.

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

From: Bob Duff
Sent: Wednesday, May 7, 2014  2:02 PM

To me, it seems clear from the words that if T has "with Constant_Indexing =>
Mumble", then types derived from T cannot have "with Constant_Indexing => ...",
but you can override Mumble.

You went one step further to wonder what the rationale for that rule is, and I
agree with you there, it's kind of curious. It's also curious that the sentence
is in [...], meaning it's implied by other rules -- I wonder what those rules
are.

I suggest a compromise: AARM annotations, giving an example, and the rationale
(if anybody remembers the rationale), and which rules imply it (if anybody
knows).

I still don't think changing the informal use of "overridden"
to "redefined" is an improvement.  I'd be inclined to think it's forbidding:

    type T is ... 
              with Constant_Indexing => This,
              with Constant_Indexing => That; -- redefined from This to That.

which is forbidden by other rules, and it's not the point of this rule.

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

From: Ed Schonberg
Sent: Wednesday, May 7, 2014  2:13 PM

> You went one step further to wonder what the rationale for that rule 
> is, and I agree with you there, it's kind of curious.
> It's also curious that the sentence is in [...], meaning it's implied 
> by other rules -- I wonder what those rules are.

The rationale is buried in the discussion section of AI05-0139, and has to
do with iterations over a class-wide object initialized with a derived
container. Would be helpful if that was in the AARM.

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

From: Randy Brukardt
Sent: Wednesday, May 7, 2014  2:27 PM

> I was trying to understand the exact rule for inheritance of indexing 
> aspects for derived container types, and I found that statement 
> curious, because it says that you are not allowed to write the aspect 
> but can still change its meaning by overriding the named subprogram.
> Excuse my density if I found that less than obvious. 
> Overriding has otherwise a precise meaning, so i wanted to know if 
> there was some indication of what it means for an aspect, but no such 
> luck. That's why I asked.

Right. The reason that I brought this up is that it is very curious to use a
term informally and formally in the same sentence. (I realize that the formal
use is implicit in the original sentence, but it surely is there.) That's
confusing to me; it's fine to use the term informally if that's the only way
it's used, but that's not the case here.

Bob writes:

> You went one step further to wonder what the rationale for that rule is,
> and I agree with you there, it's kind of curious. It's also curious that the
> sentence is in [...], meaning it's implied by other rules -- I wonder what
> those rules are.

None of this is curious at all. We want indexing to work on T'Class, and for
that, the call is dispatching, and it better be the same slot in the tag for
all types. Thus changing the name of the subprogram isn't sensible. OTOH,
allowing overriding is perfectly OK (as well as new overloadings for the new
type), as those fall out of the existing dispatching mechanism.

The part of the sentence that forbids changing the aspect is covered formally
by 4.1.6(7/3). The rest of the sentence is just standard subprogram rules for
type extensions, which (hopefully) don't need to be formally referenced.

My first suggestion was just to totally remove the sentence, but upon
reflection I think that the point that you can change the meaning of indexing
for a type extension by overriding or overloading the subprogram (but not by
using a different subprogram with a different name) is one that ought to be
mentioned.

> I suggest a compromise: AARM annotations, giving an example, and the rationale
> (if anybody remembers the rationale), and which rules imply it (if anybody knows).

There already is such an AARM note:

Ramification: Indexing can be provided for multiple index types by overloading
routines with different parameter profiles. For instance, the map containers
provide indexing on both cursors and keys by providing pairs of overloaded
routines to the Constant_Indexing and Variable_Indexing aspects. 

Normally, I would also have put a "The Proof" here, but since the actual rule
is a whopping 3 paragraphs away, it didn't seem necessary. Maybe I should have
simply because it's a forward reference.

Why you (Bob) find this so mysterious is odd to me. The objection boils down to
using a formal term ("overriding") informally in the same sentence where it is
also used formally (implicitly). That's almost certainly going to continue to
confuse, since looking up "overriding" in the index is not going to find any
references to aspects.

As to the exact wording change, there may be a better idea than the one I
suggested. Please fire away. Since this is "redundant" text, I didn't want
to go through the process of a full AI on the topic (that's clearly overkill).
But just putting in an AARM note to explain our poor wording is not much of an
answer, since so many people don't read the AARM regularly (from Robert Dewar
on down).

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

From: Randy Brukardt
Sent: Wednesday, May 7, 2014  2:33 PM

> The rationale is buried in the discussion section of AI05-0139, and 
> has to do with iterations over a class-wide object initialized with a 
> derived container.  Would be helpful if that was in the AARM.

It's much simpler than that. We define indexing on objects of T'Class, and that
better have a sensible meaning for derived types in that case.

    procedure P (Obj : in T'Class) is
    begin
       Obj(I) := ...;
    end P;

Obj(I) is a variable indexing, and it will expand into a dispatching call.
It better be the case that the dispatching call does the same thing as a
statically bound call for a type derived from T. The easiest way to ensure
that is to not allow the dispatching slot to be changed (that is, the
subprogram name and profile remains the same for all derivations, but of
course there can be a new body). This is pretty standard stuff for anything
that might dispatch (we don't allow deleting subprograms from a derived type
for similar reasons), but perhaps it isn't obvious enough.

Iteration (in particular) doesn't enter into the reasons; it shows the problems
but you can do that with any object of a class-wide type.

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

From: Bob Duff
Sent: Wednesday, May 7, 2014  2:57 PM

> My first suggestion was just to totally remove the sentence, ...

Well, if a sentence is both redundant and confusing, removing it makes good
sense. And could be considered "editorial", I suppose.

> Why you (Bob) find this so mysterious is odd to me.

Thanks for the explanations; I get it now.

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

Questions? Ask the ACAA Technical Agent