Version 1.7 of ai12s/ai12-0138-1.txt

Unformatted version of ai12s/ai12-0138-1.txt version 1.7
Other versions for file ai12s/ai12-0138-1.txt

!standard 13.1.1(34/3)          15-03-24 AI05-0138-1/06
!standard 4.1.5(5/3)
!standard 4.1.6(5/3)
!standard 4.1.6(6/3)
!standard 4.1.6(7/3)
!standard 4.1.6(8/3)
!standard 5.5.1(11/3)
!class binding interpretation 14-10-13
!status work item 14-10-13
!status received 14-06-26
!priority Low
!difficulty Medium
!qualifier Omission
!subject Iterators of formal derived types
!summary
We define the notion of "nonoverridable" aspects, and declare Default_Iterator, Iterator_Element, Implicit_Dereference, Constant_Indexing, and Variable_Indexing to be nonoverridable aspects. The value of these aspects are names which must not be changed for a derived type (their value can be confirmed), though in each type it is expected that the name might denote different subprograms, types, or discriminants.
!question
Consider a root type T that has a reversible iterator, and a derivation NT of that type that has only a forward iterator. Then for a generic
generic type FT is new T with private; package G is ...
In the generic body we could write an iterator using "reverse" for type FT. We would want an instance using NT to fail (since there is no reverse available), but of course there is no recheck in a generic body.
There is a contract problem here.
!recommendation
(See Summary.)
!wording
Insert after 13.1.1(34/3) (and perhaps add "Legality Rules" in front of 34/3):
Certain type-related aspects are defined to be nonoverridable; all such aspects are specified using an ASPECT_DEFINITION that is a NAME.
If a nonoverridable aspect is directly specified for a type T, then any explicit specification of that aspect for any other descendant of T shall be confirming; that is, the specified NAME shall match the inherited aspect, meaning that the specified NAME shall denote the same entities as would the inherited NAME.
If a full type has a partial view, and a given nonoverridable aspect is allowed for both the full view and the partial view, then the given aspect for the partial view and the full view shall be the same: the aspect shall be directly specified only on the partial view; if the full type inherits the aspect, then a matching definition shall be specified (directly or by inheritance) for the partial view.
In addition to the places where Legality Rules normally apply (see 12.3), these rules about nonoverridable aspects apply also in the private part of an instance of a generic unit.
Redundant: [The Default_Iterator, Iterator_Element, Implicit_Dereference, Constant_Indexing, and Variable_Indexing aspects are nonoverridable.]
----
Add to the Static Semantics section of 4.1.5 (before 4.1.5(6/3)):
The Implicit_Dereference aspect is nonoverridable (see 13.1.1).
----
Delete 4.1.6(6-8/3):
The Constant_Indexing or Variable_Indexing aspect shall not be specified:
- on a derived type if the parent type has the corresponding
aspect specified or inherited; or
- on a full_type_declaration if the type has a tagged partial
view.
Add after 4.1.6(5/3):
The Constant_Indexing and Variable_Indexing aspects are nonoverridable (see 13.1.1).
----
Add at the end of the Static Semantics section of 5.5.1 (after 5.5.1(11/3):
The Default_Iterator and Iterator_Element aspects are nonoverridable (see 13.1.1).
!discussion
In 4.1.5, no need to eliminate "if not overridden" wording. It is fine as is because of the possibility of a confirming aspect specification. [But that is not the way we describe aspect inheritance! - Editor.]
Similarly, the note in 4.1.6
[The aspects shall not be overridden, but the functions they denote
may be.]
is fine as it stands. [Editor's note: AI12-0104-1 removed the above wording and replaced it by a User Note, which is OK.]
The rules about partial views in the definition of nonoverridable aspects are needed so that privacy is not compromised.
The first new rule on partial views (which was originally in 4.1.6) is needed to prevent problems like this one:
package Pkg1 is type Rec is record Int : Integer; end record; R1, R2 : aliased Rec;
type T1 (D1, D2 : access Rec) is private;
generic type Descendant is new T1; package G is X : Descendant (R1'access, R2'access); function F return Integer; end; private type T1 (D1, D2 : access Rec) is null record with Implicit_Dereference => D1; -- Illegal by new rule. end;
package body Pkg1 is package body G is function F return Integer is (X.Int); end G; end;
with Pkg1; package Pkg2 is use Pkg1; type T2 is new T1 with Implicit_Dereference => D2; -- No check here. package I is new G (T2); -- Trouble here if T1 was legal. end;
The second new partial-view rule is needed to prevent hidden inheritance.
package Pkg3 is type Parent is tagged null record; type Child (D : access Integer) is new Parent with null record with Implicit_Dereference => D; end Pkg3;
with Pkg3; package Pkg4 is type Priv is Pkg3.Parent with private; private type Priv is Pkg3.Child with null record; -- Illegal by new rule: Priv would have hidden Implicit_Dereference. end Pkg4;
with Pkg1; package Pkg4.Child is use Pkg4; type T3 (D2 : access Integer) is new Priv with Implicit_Dereference => D2; -- No check possible here. end Pkg4.Child;
Type T3 would have two Implicit_Dereferences, both visible in the body of Pkg4.Child, for different discriminants.
!ASIS
No ASIS effect.
!ACATS test
We need an ACATS B-Test to verify that the new rule(s) are enforced.
!appendix

From: Tucker Taft
Sent: Tuesday, February 24, 2015  4:07 PM

Here is my take on consolidating the rules relating to "immutable" aspects.

[ASIDE: I will say I am not thrilled with the use of the term "immutable."
 Perhaps "inalterable"?  "Immutable" to me implies it doesn't change, even
by itself, when in fact it can potentially change interpretation if we
override the denoted subprogram(s). "Inalterable" to me means that we can't
change it, but it might still change interpretation on its own.  Also,
"immutable" already is associated with "immutably limited," which feels to
me like a different sense of the word.]

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

From: Jeff Cousins
Sent: Tuesday, February 24, 2015  4:16 PM

Or even unalterable, which would be more a common term (at least in in
English English).

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

From: Jean-Pierre Rosen
Sent: Tuesday, February 24, 2015  4:25 PM

> [ASIDE: I will say I am not thrilled with the use of the term "immutable." ....

Agreed. Why not use "final", like Java final methods that can't be redefined?

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

From: Tucker Taft
Sent: Tuesday, February 24, 2015  4:33 PM

I do not find the term "final" much clearer, unfortunately.  Is that your
"final aspect"? This is my final aspect!  Sounds like a game show... ;-)

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

From: Tucker Taft
Sent: Tuesday, February 24, 2015  4:27 PM

> Here is my take on consolidating the rules relating to "immutable" aspects. ...

Oops, noticed some sloppy wording.  Here are replacements for two of the
critical paragraphs:

   An immutable aspect shall not be directly specified on a
   full_type_declaration if the type has a partial view that would allow
   the specification of the same aspect. If a type with a partial view
   inherits an immutable aspect, then a matching definition shall be
   specified for this immutable aspect of the partial view.

   In addition to the places where Legality Rules normally apply (see
   12.3), these rules apply also in the private part of an instance of a
   generic unit.

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

From: Randy Brukardt
Sent: Tuesday, February 24, 2015  5:24 PM

> Here is my take on consolidating the rules relating to "immutable"
> aspects.

A quick glance at this suggests that you didn't update the discussion, which
is talking about "new legality rules added to 4.1.5, 4.1.6, and 5.5.1", and
then talks about the "first" and "second" new rule. (With your wording, there
is only one rule in each subclause.) I suspect that the discussion is really
now about the rules in the new blanket definition.

> [ASIDE: I will say I am not thrilled with the use of the term
> "immutable."  Perhaps "inalterable"?  "Immutable" to me implies it
> doesn't change, even by itself, when in fact it can potentially change
> interpretation if we override the denoted subprogram(s).
> "Inalterable" to me means that we can't change it, but it might still
> change interpretation on its own.  Also, "immutable" already is
> associated with "immutably limited,"
> which feels to me like a different sense of the word.]

I'm not wedded to any specific term here. "Inalterable" or "unalterable" is OK
by me. I'm not sure that either is really better, I do agree that there's some
possible confusion with "immutably limited", which is more important of a
concept.

My (lousy) thesaurus gives: "immutable, permanent, changeless, eternal" for
opposites of "mutable". For "alteration" (the closest to "alter" that it comes),
I get forms of fixed, stable, and identity as well as some of the above.

"Permanent aspect" might work; "eternal aspect" maybe not. ;-)

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

From: Randy Brukardt
Sent: Tuesday, February 24, 2015  5:42 PM

Another oddity: you removed the generic boilerplate from the new text in 4.1.5,
because you included it in the definition of "immutable aspect". But you left
it in the new text for 5.5.1. I would have expected 4.1.5 and 5.5.1 to be
treated the same.

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

From: Randy Brukardt
Sent: Tuesday, February 24, 2015  5:58 PM

Humm. You have (I suspect that Steve had originally) placed the definition of
"immutable aspect" into 13.1.1(34), followed by a bunch of Legality Rules,
including the boilerplate. But this is a "Static Semantics" section; there
aren't any "Legality Rules" here; so the boilerplate does have any effect. Not
what we want. This text should go in the Legality Rules section.

And the generic boilerplate here probably needs to make clear that the Legality
Rules its talking about are those for "immutable aspects" and not (necessarily)
all of the other rules in this clause. (That's always a problem when one uses
"these rules", but here it seems acute. Of course, the question arises whether
in fact the rest of these rules need the boilerplate as well, since about 98%
of the time that's true, but I don't want to make my head hurt. :-) So how
about:

  In addition to the places where Legality Rules normally apply (see
  12.3), these rules {for immutable aspects} apply also in the private
  part of an instance of a generic unit.

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

From: Bob Duff
Sent: Tuesday, February 24, 2015  6:03 PM

> [ASIDE: I will say I am not thrilled with the use of the term
> "immutable."

I agree with your reasons for being unthrilled.

> ...Perhaps
> "inalterable"?

I don't think that's a word.  "unalterable", perhaps.
Or "static" (inspired by J-P's suggestion of "final").  ;-) Or
"unutterable"?  ;-)  ;-)

More seriously, do we really need yet more magic words?  Can't we just say
"Blah shall not be redefined..." or some such?

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

From: Randy Brukardt
Sent: Tuesday, February 24, 2015  6:25 PM

I don't think that would work. Tucker wants to move this bunch of rules into
13.1.1 rather than repeating them in each place (three places currently, but
it's easy to imagine more in future aspects). In order for that to make any
sense at all, we need some sort of term so the reader knows that the rules are
incomplete at the point of definition and that they need to look in 13.1.1 to
find the rest.

In the absence of such a term, I'd rather just duplicate the rules as Steve
originally had done rather than to put some of the rules somewhere that no one
would look naturally. But I agree that's a future maintenance hazard.

More generally, blanket rules really only work when they apply to everything (as
in the resolution of aspect specifications), not as well in cases like this when
they apply to a narrowly defined subset of something. I'm rather dubious that
the blanket rules proposed in AI12-0153-1 are worth the effort, for example; if
we did make the changes, a term would make the fact that they apply clearer.
(Not that I want to come up with such a term.) We'll probably discuss this more
on Thursday.

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

From: Vincent Celier
Sent: Tuesday, February 24, 2015  6:56 PM

>> ...Perhaps
>> >"inalterable"?
> I don't think that's a word.  "unalterable", perhaps.

I believe inalterable is a word, bot in French and in English.

http://en.wiktionary.org/wiki/inalterable

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

From: Dr. Joyce L Tokar
Sent: Tuesday, February 24, 2015  8:20 PM

Both are words....inalterable is the older version (1535-45) whereas unalterable
is from 1610-1615.  They have the same meaning and both are found in common
usage in the English language today.

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

From: Tucker Taft
Sent: Tuesday, February 24, 2015  9:25 PM

>> Here is my take on consolidating the rules relating to "immutable"
>> aspects.
>
> A quick glance at this suggests that you didn't update the discussion,
> which is talking about "new legality rules added to 4.1.5, 4.1.6, and
> 5.5.1", and then talks about the "first" and "second" new rule. (With
> your wording, there is only one rule in each subclause.) I suspect
> that the discussion is really now about the rules in the new blanket
> definition.

Yes, sorry about that.  Without looking I presumed the discussion didn't need
change, since I was just moving the rules around.  But clearly I was wrong!

>> [ASIDE: I will say I am not thrilled with the use of the term
>> "immutable."  Perhaps "inalterable"?

> ... I get forms of fixed ...

How about fixed and floating aspects? ;-)

> "Permanent aspect" might work; "eternal aspect" maybe not. ;-)

"Permanent" isn't too bad, but the opposite of "permanent" is typically
"temporary," and that doesn't really make sense.

So I think I would still suggest "inalterable."  Reminds one a bit of
"inalienable" ... [actually, an interesting side story there -- Thomas Jefferson
wrote "inalienable" in his original version of the Declaration of Independence,
but John Adams changed it to "unalienable" when he copied it over for the final
printing -- tnx to ushistory.org].

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

From: Tucker Taft
Sent: Tuesday, February 24, 2015  9:27 PM

>> Here is my take on consolidating the rules relating to "immutable"
>> aspects.
>
> Another oddity: you removed the generic boilerplate from the new text
> in 4.1.5, because you included it in the definition of "immutable
> aspect". But you left it in the new text for 5.5.1. I would have
> expected 4.1.5 and 5.5.1 to be treated the same.

Oops again!

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

From: Robert Dewar
Sent: Wednesday, February 25, 2015  4:28 AM

> Both are words....inalterable is the older version (1535-45) whereas
> unalterable is from 1610-1615.  They have the same meaning and both
> are found in common usage in the English language today.

To my british ear, unalterable sounds much preferable, though inalterable wins
the google race by a factor of 9.

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

From: John Barnes
Sent: Wednesday, February 25, 2015  5:52 AM

Oxford seems to suggest that unalterable is preferrred in that it defines
inalterable as unalterable.

It also notes that unaltered means not castrated!

Fowler is not much help. It says that historically one would expect un with
English words and in with Latin words but then says it's a mess. Note assymetric
pairs such as unstable and instability.

I would go for un I think.  Hmm. Not sure.

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

From: Brad Moore
Sent: Wednesday, February 25, 2015  9:11 AM

Would one normally alter their aspects? Maybe its just me, but I find this to be
a somewhat odd thing to say. I had to alter the Pre'Class aspect of my derived
class. I think one would normally speak of either replacing or modifying an
aspect, so irreplaceable or unmodifiable seems a closer fit.

How important is it to be a word that you can find in the dictionary?

This property is tied to derivation so it seems it might be clearer and more
precise to say unsupersedable, however that does not appear to be a word even
though its base, supersede is an English word.

In any case, I am not married to any of these choices, so I suppose one might
say I am unaltarable to any of these choices.

If I had to choose though, I think I would go with irreplaceable.

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

From: Tucker Taft
Sent: Wednesday, February 25, 2015  1:44 PM

Here is an update to AI12-0138, switching to "unalterable" term, and fixing the
discussion.  I also changed the statements about "blah is an unalterable aspect"
to be Static Semantics, as the legality rules have moved to 13.1.1.

By the way, another possible alternative I thought of to "unalterable" is
"stable."

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

From: Steve Baird
Sent: Wednesday, February 25, 2015  3:09 PM

> Here is an update to AI12-0138, switching to "unalterable" term,

We could also consider "irrevocable ", "irrevocably specified", or "binding".

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

From: Tucker Taft
Sent: Wednesday, February 25, 2015  3:49 PM

I like "irrevocable."  Alternatively, given the definition of "overridden" given
in 13.1(15/3) for aspects, I think "non-overridable" would convey exactly the
correct semantics.  Is there some reason we didn't like that term?  It seems
sort of obviously correct in hindsight.

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

From: Steve Baird
Sent: Wednesday, February 25, 2015  4:04 PM

I agree, "non-overridable" is clearer than anything else we've discussed.

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

From: Robert Dewar
Sent: Wednesday, February 25, 2015  4:07 PM

Especially if this is all about overriding, rather than altering per se! I like
this suggestion.

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

From: Randy Brukardt
Sent: Wednesday, February 25, 2015  4:11 PM

> >> Here is an update to AI12-0138, switching to "unalterable" term,
> >
> > We could also consider "irrevocable ", "irrevocably specified", or
> > "binding".
>
> I like "irrevocable."  Alternatively, given the definition of
> "overridden" given in
> 13.1(15/3) for aspects, I think "non-overridable" would convey exactly
> the correct semantics.  Is there some reason we didn't like that term?
> It seems sort of obviously correct in hindsight.

Probably because 13.1(15) is not intended to define a term "overridden"; it's
not in italics, it's not indexed, etc. I thought that was an "English" use of
"overridden". (Or perhaps I never thought of it at all.)

Indeed, we had an entire AI on this topic: "AI12-0104-1  Overriding an aspect is
undefined", where we got rid of wording that talked about "overriding" an
aspect, because no such thing was thought to be defined.

Either we didn't think 13.1(15) defined the term, or no one even found that
reference.

To change course yet again would require changing 13.1(15) to italicize the
term, and then revisiting the various AIs (I think there may have been more) to
determine what changes need to be made to them. Certainly not something that we
should do tonight nor during tomorrow's meeting [we could decide intent at
most]. We'd have to have either an additional phone meeting or a bunch of letter
ballots to deal with that afterwards.

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

From: Randy Brukardt
Sent: Wednesday, February 25, 2015  4:21 PM

> > Alternatively, given the definition of "overridden" given in
> > 13.1(15/3) for aspects, I think "non-overridable" would convey
> > exactly the correct semantics.  Is there some reason we didn't like
> > that term? It seems sort of obviously correct in hindsight.
>
> I agree, "non-overridable" is clearer than anything else we've
> discussed.

[I want to scream, but I'm afraid that it might bother my neighbors in this
office building. :-)]

Surely it's "clearer". If we thought it meant anything, we never would have had
any of these AIs in the first place, because the original Ada 2012 wording said
that most of these aspects were not overriddable (without explaining the
consequences).

But Ed asked what that meant, since "overriding an aspect" isn't defined.

So we got rid of that wording, especially as it was marked as redundant.

But that caused Steve to ask one of his typical questions about generic derived
types and these aspects. Which I noted was more general than the obscure case he
asked about.

Thus some wording was proposed to plug the hole.

Which led to an argument about the term to use.

Which now seems to have settled on virtually the original wording (with some
additional rules to back it up).

Once we adopt that, we can start the whole chain over again. "There's a hole in
the bucket, a hole!!!" - Ancient folk song.

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

From: Tucker Taft
Sent: Wednesday, February 25, 2015  4:26 PM

>> ... Alternatively, given the definition of "overridden" given in
>> 13.1(15/3) for aspects, I think "non-overridable" would convey
>> exactly the correct semantics.  Is there some reason we didn't like
>> that term?  It seems sort of obviously correct in hindsight.
>
> Probably because 13.1(15) is not intended to define a term
> "overridden"; it's not in italics, it's not indexed, etc. I thought that was
> an "English" use of "overridden". (Or perhaps I never thought of it at all.)
>
> Indeed, we had an entire AI on this topic: "AI12-0104-1  Overriding an
> aspect is undefined", where we got rid of wording that talked about
> "overriding" an aspect, because no such thing was thought to be defined.

Interesting!  A bit of history my brain conveniently forgot.

> Either we didn't think 13.1(15) defined the term, or no one even found
> that reference.
>
> To change course yet again would require changing 13.1(15) to
> italicize the term, and then revisiting the various AIs (I think there
> may have been more) to determine what changes need to be made to them.
> Certainly not something that we should do tonight nor during
> tomorrow's meeting [we could decide intent at most]. We'd have to have
> either an additional phone meeting or a bunch of letter ballots to deal with
> that afterwards.

I think the term "overriding" for aspects is intuitive, and I can't remember why
we chose to abandon it.  So I would be in favor of enshrining "overriding an
aspect" as an official term, and then use it where appropriate.

And yes, I can sympathize with your desire to scream... ;-)

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

From: Randy Brukardt
Sent: Wednesday, February 25, 2015  4:28 PM

> > I agree, "non-overridable" is clearer than anything else we've
> > discussed.
>
> Especially if this is all about overriding, rather than altering per
> se! I like this suggestion.

To turn to a technical objection, it seems to me that that could be confusing.
After all, the entity designated by the aspect can be overridden or overloaded
(for Constant_Indexing/Variable_Indexing in particular), what you can't do is
change (alter?) the entity designated. We've generally not used the term
"override" with aspects (other than the one sentence Tuck dug up); they are
outright replaced.

Perhaps that is something that we should rethink, but I don't think it's a good
idea to do that at 23:58 in this particular process.

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

From: Tucker Taft
Sent: Wednesday, February 25, 2015  4:35 PM

> To turn to a technical objection, it seems to me that that could be
> confusing. After all, the entity designated by the aspect can be
> overridden or overloaded (for Constant_Indexing/Variable_Indexing in
> particular), what you can't do is change (alter?) the entity
> designated. We've generally not used the term "override" with aspects
> (other than the one sentence Tuck dug up); they are outright replaced.

Actually, the term "overridden" appears in 13.1(15.1/3) as well, and in AARM
paragraphs 13.1(15.a, 15.b.1/3).

> Perhaps that is something that we should rethink, but I don't think
> it's a good idea to do that at 23:58 in this particular process.

Not sure I agree.  If we are introducing a new term at 23:58, that seems worse
to me. Straightening out the usage of a term that already appears in the
standard makes perfect sense in a corrigendum, especially if it makes intuitive
sense to most folks.

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

From: Randy Brukardt
Sent: Wednesday, February 25, 2015  4:53 PM

...
> > Perhaps that is something that we should rethink, but I don't think
> > it's a good idea to do that at 23:58 in this particular process.
>
> Not sure I agree.  If we are introducing a new term at 23:58, that
> seems worse to me.
> Straightening out the usage of a term that already appears in the
> standard makes perfect sense in a corrigendum, especially if it makes
> intuitive sense to most folks.

I'm mostly against re-introducing a term that was thought not to be defined at
23:58, with an unspecified scope of changes to accommodate that. (That is,
voting tomorrow to have the editor straighten it out without an additional
vote.) That's something we should think through carefully to ensure that we
haven't introduced additional problems, not do as a rush.

If you had made this suggestion on Friday, I still would have screamed, but
there would have been time to deal with it. As it is, I need to post the agenda
in the next couple of hours (and I still have to finish AI12-0152-1) so that our
west coast members have a chance to read the AIs before tomorrow's meeting. (I
don't think anyone should be forced to get up at 6 am their time to be prepared
for an ARG meeting.)

I still think we'll need to introduce "nonoverriddable aspect" as a term, since
there is a bunch of specific Legality Rules triggered. (Note: I don't think
there is a hyphen in here, as this is a new term and the anti-hyphen forces won
that debate -- we only use hyphens after "non" in words already extensive used
in the Standard.) That's not something we would want to have people figure out
by guessing what the consequences are. :-)

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

From: Tucker Taft
Sent: Wednesday, February 25, 2015  5:15 PM

...
> If you had made this suggestion on Friday, I still would have
> screamed, but there would have been time to deal with it. As it is, I
> need to post the agenda in the next couple of hours (and I still have
> to finish AI12-0152-1) so that our west coast members have a chance to
> read the AIs before tomorrow's meeting. (I don't think anyone should
> be forced to get up at 6 am their time to be prepared for an ARG
> meeting.)

I agree we should not try to solve this entire problem tomorrow.  But I do think
we should address it in the upcoming Corrigendum.

> I still think we'll need to introduce "nonoverriddable aspect" as a
> term, since there is a bunch of specific Legality Rules triggered.

Yes, I agree with that.

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

From: Randy Brukardt
Sent: Wednesday, February 25, 2015  5:38 PM

> Actually, the term "overridden" appears in 13.1(15.1/3) as well, and
> in AARM paragraphs 13.1(15.a, 15.b.1/3).

True enough, but the other normative paragraph is a mirror of 13.1(15/3), and
the appearance in the associated notes isn't very compelling, either.

I probably should have said that we don't use "overriding an aspect" in any
language rules, so far as I can remember; that's probably why we never defined
it as a term.

> > Perhaps that is something that we should rethink, but I don't think
> > it's a good idea to do that at 23:58 in this particular process.
>
> Not sure I agree.  If we are introducing a new term at 23:58, that
> seems worse to me.
> Straightening out the usage of a term that already appears in the
> standard makes perfect sense in a corrigendum, especially if it makes
> intuitive sense to most folks.

I think I prefer "irrevocable" as Steve suggested, because it has the closest
connotation to the intended meaning (you can specify it once but not change it).
I think "nonoverridable aspect" is likely to be confused with not being able to
override the specified subprogram, which is definitely not what we mean.

But I don't think the exact term matters that much; making sure that the rules
are well-defined matters more.

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

From: Tucker Taft
Sent: Tuesday, March 24, 2015  2:27 PM

I believe this is the only "corrigendum" AI still outstanding.
[This is version /06 of the AI - Editor.]  I tried to make
the wording easier to understand, with the rationale implicit in the wording
itself.  I also indicated that nonoverridable aspects are always specified by
NAMEs, so it makes sense to talk about what they "denote."  I hope this will
also make it clearer that we are saying that the NAME is inherited, even if the
denoted entities might not be.

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

Questions? Ask the ACAA Technical Agent