CVS difference for ai05s/ai05-0013-1.txt

Differences between 1.7 and version 1.8
Log of other versions for file ai05s/ai05-0013-1.txt

--- ai05s/ai05-0013-1.txt	2007/10/26 01:37:57	1.7
+++ ai05s/ai05-0013-1.txt	2007/12/13 04:39:34	1.8
@@ -1,4 +1,4 @@
-!standard 7.6(9.4/2)                                 07-10-25    AI05-0013-1/06
+!standard 7.6(9.4/2)                                 07-11-19    AI05-0013-1/07
 !standard D.7(4/2)
 !class binding interpretation 06-04-10
 !status work item 06-05-29
@@ -48,8 +48,10 @@
 
 !wording
 
-Delete 7.6(9.4/2).
+Replace 7.6(9.4/2) with:
 
+it is a class-wide type; or
+
 Replace D.7(3-10/2) with:
 
 No_Task_Hierarchy
@@ -57,9 +59,10 @@
    of the partition.
 
 No_Nested_Finalization
-   Objects of a type that needs finalization (see 7.6) shall be declared
-   only at library level. There shall be no allocators for an access type
-   whose designated type needs finalization if the access type does not have
+   Objects of a type that needs finalization (see 7.6) are declared
+   only at library level. There are no allocators where the type
+   determined by the subtype_mark of the subtype_indication or qualified_expression
+   needs finalization where the type of the allocator does not have
    library-level accessibility.
 
 No_Abort_Statements
@@ -132,9 +135,11 @@
 
 !corrigendum 7.6(9.4/2)
 
-@ddel
+@drepl
 @xbullet<it is a limited type that has an access discriminant whose designated
 type needs finalization; or>
+@dby
+@xbullet<it is a class-wide type; or>
 
 !corrigendum D.7(4/2)
 
@@ -142,10 +147,11 @@
 @xindent<Objects of a type that needs finalization (see 7.6) and access types that
 designate a type that needs finalization, shall be declared only at library level.>
 @dby
-@xindent<Objects of a type that needs finalization (see 7.6) shall be declared
-only at library level. There are no @fa<allocator>s for an access type whose
-designated type needs finalization if the access type does not have
-library-level accessibility.>
+@xindent<Objects of a type that needs finalization (see 7.6) are be declared
+only at library level. There are no @fa<allocator>s where the type
+determined by the @fa<subtype_mark> of the @fa<subtype_indication> or
+@fa<qualified_expression> needs finalization where the type of the @fa<allocator>
+does not have library-level accessibility.>
 
 !ACATS test
 
@@ -174,6 +180,397 @@
 not even be complete if it comes from a limited view).
 
 Comments?
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Monday, November 19, 2007 11:48 PM
+
+I've always been confused when reading D.7(3), even though I "know" the intent:
+
+All (nonenvironment) tasks depend directly on the environment task of the partition.
+
+This is supposed to imply some sort of check that makes programs that violates it
+illegal. But it always seems to me to be talking about some change in semantics
+instead (tasks, no matter where they are declared, depend directly on the
+environment task). [Indeed, we have a pragma with actions much like this in Annex H,
+so the idea isn't unique.]
+
+This was one of the reasons behind introducing "shall" here, which Tuck and Bob were
+so certain was incorrect. However, leaving the wording alone doesn't address the
+original problem that some of these restrictions are easy to misconstrue. (That's
+especially true as 13.12 never says anything about checking for violations of
+restrictions - it simply says that "a partition shall obey a restriction", and that
+can be accomplished in a number of ways, not all of which necessarily involve
+any checking.)
+
+It strikes me that the restrictions that make sense (mostly original ones) are
+written in the negative: "There are no <blahs>." *That* seems like a restriction.
+So I'm wondering if it would be better if restrictions like the above one were
+defined in terms of what is not allowed:
+
+    No (nonenvironment) tasks depend directly on a task other than the
+    environment task of the partition.
+
+Similar rewordings would be a good idea for D.7(10.1/2):
+
+    No protected objects are declared other than at library level.
+
+and D.7(10.2/2):
+
+    No Timing_Events are declared other that at library level.
+
+and D.7(10.8/2):
+
+    No entry barrier has a Boolean expression that is neither a static Boolean expression
+    nor a Boolean component of the enclosing protected object.
+
+This last wording is a bit of stretch.
+
+Note that these last three are the three new restrictions that use "shall", probably
+because they don't make much sense as restrictions without making it clear that a
+check is required (which is especially important for Ravenscar use).
+
+The first sentence of D.7(4/2) would need some change, too (this was the other place
+that had "shall" originally).
+
+   No objects of a type that needs finalization (see 7.6) are declared
+   other than at library level. There are no allocators where the type
+   determined by the subtype_mark of the subtype_indication or qualified_expression
+   needs finalization where the type of the allocator does not have
+   library-level accessibility.
+
+Brickbats encouraged...
+
+****************************************************************
+
+From: Tucker Taft
+Date: Tuesday, November 20, 2007  6:39 AM
+
+I see your point Randy.  I still think adding "shall"
+to these definitions is a mistake, and believe we should
+remove it where it snuck in.  On the other hand, adding
+some additional, admittedly redundant information every-
+where we define restrictions might help resolve the
+confusion.  That is, get some "shall"s or at least
+references to the fundamental "checking" aspect of
+restrictions into the wording in the close neighborhood
+of the restriction definitions as a reminder to the user
+of the purpose of these definitions.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Tuesday, November 20, 2007  7:18 AM
+
+As far as using "no" in the wording, that does
+seem to help in some cases.  Alternatively,
+we can rely on words like "each," "only," or "exclusively"
+to convey the "restrictive" intent, without having
+to reverse the sense of the sentence, and without
+having to use the word "shall."  Hence:
+
+    The only (nonenvironment) tasks are ones that depend
+    directly on the environment task of the partition.
+
+    Protected objects are declared exclusively at library level.
+
+    Timing events are declared exclusively at library level.
+
+    The Boolean expression in each entry barrier is either a
+    static Boolean expression or a Boolean component of the
+    enclosing protected object.
+
+One way to help stick to *definitional* wording (as opposed
+to slipping into "legality rule" wording) is to imagine
+each Restriction identifier as being placed in a phrase such as:
+
+  A partition satisfies the "Simple_Barriers" restriction when:
+
+    The Boolean expression in each entry barrier is either a
+    static Boolean expression or a Boolean component of the
+    enclosing protected object.
+
+****************************************************************
+
+From: Robert A. Duff
+Date: Tuesday, November 20, 2007  7:48 AM
+
+> This was one of the reasons behind introducing "shall" here, which Tuck and
+> Bob were so certain was incorrect.
+
+Not quite incorrect -- just unnecessary.  The current style is (mostly) to
+define the restrictions, and then have a single "shall" rule saying you have to
+obey.  We could have chosen a style where each restriction says "If this
+restriction applies, then Thou Shalt [Not]..."  But I don't see any reason to
+move to this other style -- if it ain't broke, don't fix it.  Yeah, I know --
+you think it IS broken.  But to me, it's like many other things, e.g. static
+expressions.  We define what they are, and then separately require their use.
+We don't say something like, "A static expression shall not contain a variable
+reference."
+
+>     No (nonenvironment) tasks depend directly on a task other than the
+>     environment task of the partition.
+
+I don't see how the negative helps.  It's still a definition, rather than a
+"shall" rule.  And it forces you into a double negative "No ... other than..."
+which is slightly less readable.
+
+****************************************************************
+
+From: Robert A. Duff
+Date: Tuesday, November 20, 2007  7:54 AM
+
+>   A partition satisfies the "Simple_Barriers" restriction when:
+
+...which makes me think perhaps we should put something like that in the
+introductory paragraphs:
+
+    The following restriction_identifiers are language defined;
+    the following definitions define how each restriction may
+    be satisfied.
+
+or:
+
+    The following restriction_identifiers are language defined;
+    a partitition satisfies the restriction as defined below.
+
+or:
+
+    The following restriction_identifiers are language defined;
+    a partitition is defined to satisfy the restriction under the
+    conditions given below.
+
+Or something.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Tuesday, November 20, 2007  2:08 PM
+
+> > This was one of the reasons behind introducing "shall" here, which Tuck and
+> > Bob were so certain was incorrect.
+>
+> Not quite incorrect -- just unnecessary.  The current style is (mostly) to
+> define the restrictions, and then have a single "shall" rule
+> saying you have to obey.
+
+But that's the problem. What does it mean to "obey" a restriction? When the
+restriction is written as a negative (There are no delay_statements.) that's
+pretty clear. But when it is written positively, it isn't so clear. The only
+reason I know what is meant is because I've talked to you guys; I can't get
+there from the normative wording. Everytime I read D.7(3), I have to
+remember that it doesn't mean what it says, it means "No nested tasks". Why
+should that be?
+
+As I previously pointed out, I can think of at least two ways to obey "All
+(nonenvironment) tasks depend directly on the environment task of the
+partition." That kind of ambiguity is not good; we ought to use wording that
+makes it clear that task objects that violate this are illegal and not that
+some semantic change is intended.
+
+Sometimes its easy to get too close to some wording, and read what you know
+is meant rather than what it actually says. I think you're doing that here.
+
+> >     No (nonenvironment) tasks depend directly on a task other than the
+> >     environment task of the partition.
+>
+> I don't see how the negative helps.  It's still a definition, rather than a
+> "shall" rule.  And it forces you into a double negative "No ... other than..."
+> which is slightly less readable.
+
+Because it is more clear that it is intended that such tasks don't exist,
+rather than that there is some semantic change. (And other restrictions do
+make semantic changes, so we must be very clear.)
+
+It probably would be even clearer if it said something like:
+
+     No object is created which creates a task that depends directly on a
+     task other than the environment task of the partition.
+
+which makes it crystal clear that the real point of the Restriction is to
+ban the creation of certain kinds of objects.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Tuesday, November 20, 2007  2:08 PM
+
+> >   A partition satisfies the "Simple_Barriers" restriction when:
+>
+> ...which makes me think perhaps we should put something like that in the
+> introductory paragraphs:
+>
+>     The following restriction_identifiers are language defined;
+>     the following definitions define how each restriction may
+>     be satisfied.
+>
+> or:
+>
+>     The following restriction_identifiers are language defined;
+>     a partitition satisfies the restriction as defined below.
+>
+> or:
+>
+>     The following restriction_identifiers are language defined;
+>     a partitition is defined to satisfy the restriction under the
+>     conditions given below.
+>
+> Or something.
+
+Any such wording should use "obey", since "obey" is what the "shall" rule
+requires. No sense in continuing to confuse the issue by using "satisfy"
+here and "obey" there.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Tuesday, November 20, 2007  5:04 PM
+
+Good point.  Hence, something like:
+
+  The following restriction_identifiers are language defined;
+  each definition given below specifies under what conditions
+  the associated restriction is *obeyed*:
+
+****************************************************************
+
+From: Robert A. Duff
+Date: Tuesday, November 20, 2007  5:12 PM
+
+I like it.
+
+****************************************************************
+
+From: Ed Schonberg
+Date: Tuesday, November 20, 2007  2:41 PM
+
+> It probably would be even clearer if it said something like:
+>
+>      No object is created which creates a task that depends  
+> directly on a
+> task other than the
+>      environment task of the partition.
+>
+> which makes it crystal clear that the real point of the Restriction  
+> is to
+> ban the creation of certain kinds of objects.
+
+Why not describe it top-down:
+
+No task other than the environment task creates other tasks.
+
+****************************************************************
+
+From: Robert A. Duff
+Date: Tuesday, November 20, 2007  4:38 PM
+
+> Why not describe it top-down:
+> 
+> No task other than the environment task creates other tasks.
+
+That's not quite right.  The issue is dependence, not creation.
+
+If we have:
+
+    type A is access Some_Task_Type;
+
+at library level, then any task can do "new Some_Task_Type" of type A -- it
+doesn't matter who creates it, it still depends on the env task.
+
+****************************************************************
+
+From: Ed Schonberg
+Date: Tuesday, November 20, 2007  4:49 PM
+
+Indeed. What about:
+   tasks can  only depend on the environment task of the partition
+
+I suppose we don't have to say anything special about the environment  
+task itself.
+
+****************************************************************
+
+From: Robert A. Duff
+Date: Tuesday, November 20, 2007  5:09 PM
+
+That works.
+
+Nitpick (which Tucker will appreciate ;-)):
+
+    tasks can depend only on the environment task of the partition
+              ^^^^^^^^^^^ I reversed these words.
+
+I'm the "only"-placement police, and I infected Tucker with this disease during
+Ada 9X.  ;-)
+
+> I suppose we don't have to say anything special about the environment  task
+> itself.
+
+Well, I think we have to, so:
+
+    tasks, other than the env task itself, can depend only on the env task of
+    the partition
+
+And while I'm at it, "of the partition" seems uselessly obvious, so:
+
+    tasks, other than the env task itself, can depend only on the env task
+
+I'd drop the "can", but then Randy will kill me.  ;-)
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Tuesday, November 20, 2007 11:48 PM
+
+...
+> Indeed. What about:
+>    tasks can  only depend on the environment task of the partition
+>
+> I suppose we don't have to say anything special about the environment
+> task itself.
+
+But that's essentially the current wording, and it does not make it clear
+how that is accomplished (that is, that something is not allowed as opposed
+to just being a semantic change). We could of course use the original
+wording if we added an additional sentence to make it clear how it is
+enforced:
+   "A partition obeys this restriction if no objects create tasks that
+violate the above."
+
+But I think it makes just as much sense to fold those into a single
+sentence, especially as we never say things like "violate the above".
+
+****************************************************************
+
+From: Robert A. Duff
+Date: Tuesday, November 20, 2007  4:54 PM
+
+> Because it is more clear that it is intended that such tasks don't exist,
+> rather than that there is some semantic change. (And other restrictions do
+> make semantic changes, so we must be very clear.)
+
+I don't see how using negative wording fixes this possible misunderstanding.
+To me, "There are no tasks that don't depend on the env task" is exactly
+equivalent to "All tasks depend on the env task".  (Of course, both need the
+"other than the env task itself" complication to muddy them up.)
+
+> It probably would be even clearer if it said something like:
+> 
+>      No object is created which creates a task that depends directly on a
+> task other than the
+>      environment task of the partition.
+> 
+> which makes it crystal clear that the real point of the Restriction is to
+> ban the creation of certain kinds of objects.
+
+I don't see how this prevents the possible confusion you're worried about.
+What if someone interprets the above to mean that the implementation should
+magically cause tasks to not depend on "a task other than..."?
+
+Having said all that, I must say: I think this issue is a storm in a coffee
+carafe (tempest in a teapot?), and I therefore have no strong objection to the
+negative wordings you suggested.  I just don't think it's necessary.
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent