CVS difference for ais/ai-00397.txt

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

--- ais/ai-00397.txt	2005/08/21 06:00:39	1.8
+++ ais/ai-00397.txt	2005/10/31 05:18:41	1.9
@@ -1,4 +1,4 @@
-!standard 6.3.1(24)                                    05-08-07  AI95-00397/07
+!standard 6.3.1(24)                                    05-09-20  AI95-00397/08
 !standard 8.3.1(1)
 !standard 9.1(9.1)
 !standard 9.4(11)
@@ -138,13 +138,14 @@
 
 Add after the last paragraph inserted by AI95-00345 after 9.4(11):
 
-If a protected subprogram declaration has an overriding_indicator, then:
+If a protected subprogram declaration has an overriding_indicator, then at
+the point of declaration:
 
 o if the overriding_indicator is *overriding*, then the subprogram shall
-  implement an inherited subprogram, at the point of the declaration;
+  implement an inherited subprogram;
 
 o if the overriding_indicator is *not overriding*, then the subprogram shall
-  not implement any inherited subprogram (at any point).
+  not implement any inherited subprogram.
 
 In addition to the places where Legality Rules normally apply (see 12.3), these
 rules also apply in the private part of an instance of a generic unit.
@@ -162,13 +163,14 @@
 
 Add after 9.5.2(13):
 
-If an entry_declaration has an overriding_indicator, then:
+If an entry_declaration has an overriding_indicator, then at the point of
+declaration:
 
 o if the overriding_indicator is *overriding*, then the entry shall implement
   an inherited subprogram, at the point of the declaration;
 
-o if the overriding_indicator is *not overriding*, then the operation shall not
-  implement any inherited subprogram (at any point).
+o if the overriding_indicator is *not overriding*, then the entry shall not
+  implement any inherited subprogram.
 
 In addition to the places where Legality Rules normally apply (see 12.3), these
 rules also apply in the private part of an instance of a generic unit.
@@ -342,13 +344,14 @@
 an entry, then the first parameter of the inherited subprogram shall be
 of mode @b<out> or @b<in out>, or an access-to-variable parameter.
 
-If a protected subprogram declaration has an @fa<overriding_indicator>, then:
+If a protected subprogram declaration has an @fa<overriding_indicator>, then at
+the point of the declaration:
 
 @xbullet<if the @fa<overriding_indicator> is @b<overriding>, then the subprogram shall
-implement an inherited subprogram, at the point of the declaration;>
+implement an inherited subprogram;>
 
 @xbullet<if the @fa<overriding_indicator> is @b<not overriding>, then the subprogram shall
-not implement any inherited subprogram (at any point).>
+not implement any inherited subprogram.>
 
 In addition to the places where Legality Rules normally apply (see 12.3), these
 rules also apply in the private part of an instance of a generic unit.
@@ -376,13 +379,14 @@
 @dinsa
 An @fa<entry_declaration> in a task declaration shall not contain a specification for an access parameter (see 3.10).
 @dinss
-If an @fa<entry_declaration> has an @fa<overriding_indicator>, then:
+If an @fa<entry_declaration> has an @fa<overriding_indicator>, then at the
+point of the declaration:
 
-@xbullet<if the @fa<overriding_indicator> is @b<overriding>, then the entry shall implement
-an inherited subprogram, at the point of the declaration;>
+@xbullet<if the @fa<overriding_indicator> is @b<overriding>, then the entry
+shall implement an inherited subprogram;>
 
-@xbullet<if the @fa<overriding_indicator> is @b<not overriding>, then the operation shall not
-implement any inherited subprogram (at any point).>
+@xbullet<if the @fa<overriding_indicator> is @b<not overriding>, then the entry
+shall not implement any inherited subprogram.>
 
 In addition to the places where Legality Rules normally apply (see 12.3), these
 rules also apply in the private part of an instance of a generic unit.
@@ -393,7 +397,7 @@
 @xcode<@fa<parent_unit_name ::= name>>
 @dinst
 An @fa<overriding_indicator> is not allowed in a @fa<subprogram_declaration>,
-@fa<generic_instantiation>, or @fa<subprogram_renaming_declaration> which
+@fa<generic_instantiation>, or @fa<subprogram_renaming_declaration> that
 declares a library unit.
 
 
@@ -404,4 +408,187 @@
 
 !appendix
 
+From: Bob Duff
+Sent: Monday, June 6, 2005  12:40 PM
+
+I'm using draft 11.8 of the [A]ARM.
+
+6.3.1(24.1/2):
+
+24.1/2 {AI95-00345-01} {AI95-00397-01} {prefixed view profile} The prefixed
+view profile of a subprogram is the profile obtained by omitting the first
+parameter of that subprogram. There is no prefixed view profile for a
+parameterless subprogram. For the purposes of defining subtype and mode
+conformance, the convention of a prefixed view profile is considered to match
+that of either an entry or a protected operation.
+
+I find this wording confusing.  Does it mean that it can't match a
+run-of-the-mill subprogram?  Would it be clearer to delete that last sentence,
+and add something to the definition of subtype conformance?  Like,
+"However, the associated calling conventions need not be the same in the case
+of a prefixed view profile."  Or add "(unless one or both are prefixed view
+profiles)"  before "the associated calling conventions are the same"
+in:
+
+17    {subtype conformance} {profile (subtype conformant)} Two profiles are
+subtype conformant if they are mode-conformant, corresponding subtypes of the
+profile statically match, and the associated calling conventions are the same.
+The profile of a generic formal subprogram is not subtype-conformant with any
+other profile. {statically matching (required) [partial]}
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, June 6, 2005  7:33 PM
+
+I agree this wording should be improved.  I believe it
+used to say that the prefixed-view profile was
+considered to be of an intrinsic convention.  It was
+changed to help simplify the rules for what it means
+for a primitive to be "implemented by" a protected
+operation or a task entry, but it seems harder to
+understand as a result.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, June 6, 2005  9:11 PM
+
+> I agree this wording should be improved.
+
+Please suggest something!
+
+> I believe it
+> used to say that the prefixed-view profile was
+> considered to be of an intrinsic convention.
+
+No, you're confusing a "prefixed view" (which is a @fa<name>) and a
+"prefixed view profile".
+
+> It was
+> changed to help simplify the rules for what it means
+> for a primitive to be "implemented by" a protected
+> operation or a task entry, but it seems harder to
+> understand as a result.
+
+No, it never existed before. It was *created* to do what you explain.
+
+> Bob Duff wrote:
+> > 6.3.1(24.1/2):
+> >
+> > 24.1/2 {AI95-00345-01} {AI95-00397-01} {prefixed view profile} The
+prefixed
+> > view profile of a subprogram is the profile obtained by omitting the
+first
+> > parameter of that subprogram. There is no prefixed view profile for a
+> > parameterless subprogram. For the purposes of defining subtype and mode
+> > conformance, the convention of a prefixed view profile is considered to
+match
+> > that of either an entry or a protected operation.
+> >
+> > I find this wording confusing.  Does it mean that it can't match a
+> > run-of-the-mill subprogram?
+
+Right, because this is only used for "implemented by" subprograms for tasks
+and protected types with interfaces. I don't know of any uses for it
+otherwise.
+
+> Would it be clearer to delete that last sentence,
+> > and add something to the definition of subtype conformance?  Like,
+> > "However, the associated calling conventions need not be the same in the
+> > case of a prefixed view profile."  Or add "(unless one or both are
+> > prefixed view profiles)"  before "the associated calling conventions
+> > are the same"
+
+I don't know quite how that would work. Every subprogram has a prefixed view
+profile, but we're only interested in them in a few cases. This difference
+only applies when we're explicitly matching a prefixed view profile to
+something, not any time that a prefixed view profile might be around (which
+is almost always). It seems better to me to keep it localized. But feel free
+to suggest something that has the right effect.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, June 6, 2005  9:17 PM
+
+> I don't know quite how that would work. Every subprogram has a prefixed view
+> profile, ...
+
+unless it has zero parameters.
+
+>...but we're only interested in them in a few cases. This difference
+> only applies when we're explicitly matching a prefixed view profile to
+> something, not any time that a prefixed view profile might be around (which
+> is almost always). It seems better to me to keep it localized. But feel free
+> to suggest something that has the right effect.
+
+Sorry, I don't understand the issue well enough to propose any more
+suggested wordings.  Maybe after I've read up through chapter 9?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, June 6, 2005  11:08 PM
+
+Perhaps. Or maybe I'm just too close to understand the global implications
+(that's why you're reviewing this, after all).
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, June 7, 2005  3:38 AM
+
+> I find this wording confusing.  Does it mean that it can't
+> match a run-of-the-mill subprogram?
+
+Yes.
+
+>  Would it be clearer to
+> delete that last sentence, and add something to the
+> definition of subtype conformance?  Like,
+> "However, the associated calling conventions need not be the
+> same in the case of a prefixed view profile."
+
+I'm not sure if it would be clearer, but it would be incorrect, because we
+strictly want to restrict ourselves to entry and protected.
+
+This is wording that has been very carefully crafted, and we went through
+numerous iterations where the conformance rules for "implemented by"
+subprograms were just plain wrong.  The wording may be confusing, but as
+far as I know it is correct.  Feel free to propose improvements to the
+English, but make sure you don't break anything.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, June 7, 2005  3:44 AM
+
+> I agree this wording should be improved.  I believe it
+> used to say that the prefixed-view profile was
+> considered to be of an intrinsic convention.  It was
+> changed to help simplify the rules for what it means
+> for a primitive to be "implemented by" a protected
+> operation or a task entry, but it seems harder to
+> understand as a result.
+
+You are confused my friend.  You are mixing "prefixed view" with "prefixed
+view profile".  Anyway, if you think the wording should be improved,
+propose something...
+
 ****************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, June 7, 2005  4:02 AM
+
+> > I don't know quite how that would work. Every subprogram has a
+> > prefixed view profile, ...
+>
+> unless it has zero parameters.
+
+And that's OK: since it has no prefixed view profile, surely this profile
+doesn't conform to anything, and therefore cannot be "implemented by"
+anything, which is just what we want.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent