!standard D.7(3/3) 10-10-07 AI05-0216-1/03 !class binding interpretation 10-06-12 !status Amendment 2012 10-08-10 !status WG9 Approved 10-10-28 !status ARG Approved 8-0-1 10-06-19 !status work item 10-06-12 !status received 10-03-12 !priority Low !difficulty Easy !qualifier Error !subject No_Task_Hierarchy is still wrong !summary The Restriction No_Task_Hierarchy is reworded. !question AARM D.7(3.a/3) says that a function cannot return an object with a task part. But that doesn't seem to follow from the actual wording. D.7(3/3) [from AI05-0013-1] says "No task depends on a task...", not "No task depends on a nested master...". If a function is called at the library level, the only *task* on which the task created by the return statement depends is the environment task (see 9.3(4)), so the restriction wouldn't be violated. What is the intent? !recommendation (See Summary.) !wording Replace D.7(3/3) by: No task depends on a master other than the library-level master. Add to the AARM Ramification: This is equivalent to saying "no task depends on a master other than the master that is the execution of the body of the environment task of the partition", but it is much easier to understand. This is a post-compilation check, which can be checked at compile-time. !discussion The old wording talked about depending on tasks, but there are many masters that are not tasks (such as subprograms). And we definitely don't want to depend on a subprogram -- that's precisely what this restriction is intended to prevent. !corrigendum D.7(3) @drepl @xindent @dby @xindent !ACATS Test No ACATS test change ought to be needed. !appendix !topic Error in AI05-13? !reference AI05-13, RM D.7(3/3), AARM D.7(3.a/3) !from Adam Beneschan 10-03-12 !discussion I'm having a lot of trouble understanding the AARM paragraph following D.7(3), and I wonder if there's a typo or something. D.7(3) says, "No task depends on a task other than the environment task of the partition". The Ramification says: "This disallows any function returning an object with a task part or coextension, even if called at the library level, as such a task would temporarily depend on a nested master (the master of the return statement), which is disallowed by this restriction." Why is it disallowed? D.7(3) says "No task depends on a task...", not "No task depends on a nested master...". If a function is called at the library level, the only *task* on which the task created by the return statement depends is the environment task (see 9.3(4)), so the restriction wouldn't be violated, right? I'm confused... **************************************************************** From: Randy Brukardt Sent: Friday, March 12, 2010 9:44 PM I guess you're right, in that AI05-0013-1 dropped the "directly" wording of the original Ada 83 text. The effect is that it doesn't disallow anything that is supposed to be illegal. I don't think this restriction intends to allow tasks declared in subprograms, either, yet the current wording would allow that as well (at least the way you are interpreting it). As the AI notes, this restriction is an important part of the Ravenscar profile. I'm certain that Ravenscar has no intention of allowing a local task to be declared. But even the original wording is dubious as to whether that is accomplished (it's surely not that clear as to what a "direct" dependence is). So the AARM note is right, but the wording is wrong (and arguably always has been wrong). P.S. I see you've reached the annexes. I'm looking forward to all of the bug reports on Annex F. ;-) **************************************************************** From: Bob Duff Sent: Saturday, March 13, 2010 12:41 PM > I guess you're right, in that AI05-0013-1 dropped the "directly" > wording of the original Ada 83 text. The effect is that it doesn't > disallow anything 95, you mean > that is supposed to be illegal. > > I don't think this restriction intends to allow tasks declared in > subprograms, either, ... I agree. >...yet the current wording would allow that as well (at least the way >you are interpreting it). As the AI notes, this restriction is an >important part of the Ravenscar profile. I'm certain that Ravenscar has >no intention of allowing a local task to be declared. But even the >original wording is dubious as to whether that is accomplished (it's >surely not that clear as to what a "direct" dependence is). > > So the AARM note is right, but the wording is wrong (and arguably > always has been wrong). I think the old wording, "All (nonenvironment) tasks depend directly on the environment task of the partition." is pretty clear. Even though "depend directly" is not formally defined, what else could it mean than the innermost master upon which something depends? It's requiring that master to be the (body of the) environment task. The new wording is clearly wrong. It's not clear to me why it was changed. The rationale seems to be, "We are fixing all of the restrictions that use "shall", and some that need clearer wording." Lesson: ARG should be wary of "clarifying" things that nobody would misinterpret, for fear of breaking things. GNAT's interpretation agrees with Randy's. The following: pragma Restrictions (No_Task_Hierarchy); procedure Tasks is task T; task body T is begin null; end; begin null; end Tasks; gets this error: violation of restriction "No_Task_Hierarchy" at line 1 **************************************************************** From: Randy Brukardt Sent: Monday, March 15, 2010 11:44 PM ... > I think the old wording, "All (nonenvironment) tasks depend directly > on the environment task of the partition." is pretty clear. Even > though "depend directly" is not formally defined, what else could it > mean than the innermost master upon which something depends? It's > requiring that master to be the (body of the) environment task. "What else could it mean?" is hardly a good reason to justify wording. We have lots of people around here that have no problem determining other possible meanings! Indeed, it isn't at all clear that this old wording is intended to be a compile-time restriction. It could easily be taken to mean that all tasks depend on the environment task no matter where they are declared. > The new wording is clearly wrong. It's not clear to me why it was changed. > The rationale seems to be, "We are fixing all of the restrictions that > use "shall", and some that need clearer wording." Lesson: ARG should > be wary of "clarifying" things that nobody would misinterpret, for > fear of breaking things. We needed to clearly describe that this is a compile-time restriction (since there are several restrictions which are *not* compile-time restrictions - another thing that was screwed up.). > GNAT's interpretation agrees with Randy's. I'm pretty sure that the intent was understood, but the wording didn't get within a country mile of explaining that intent. The new wording doesn't help though, because it is wrong, even though it is a direct inversion of the old wording. Which ought to make it clear that the old wording wasn't any good, either. (It should be noted that my original suggestion for changing this wording was "No (nonenvironment) tasks depend directly on a task other than the environment task of the partition." which more closely echoes the original wording. But it still is unclear, given that there is no meaning to "directly". See my e-mail of November 19, 2007. Of course there is a Bob Duff reply that this is not broken -- which just goes to show you are consistent!) I suspect that we need to say something about masters here, in order to avoid the undefined "directly": "No task depends on a master other than the master of the environment task of the partition." This would seem to disallow all forms of nested tasks, which is the point. (I think there also should be an AARM note that this, and all of the other restriction identifiers defined in "static semantics", are intended to be checked at compile time. That's still not crystal-clear.) **************************************************************** From: Bob Duff Sent: Tuesday, March 16, 2010 9:51 AM > ... > > I think the old wording, "All (nonenvironment) tasks depend directly > > on the environment task of the partition." is pretty clear. Even > > though "depend directly" is not formally defined, what else could it > > mean than the innermost master upon which something depends? It's > > requiring that master to be the (body of the) environment task. > > "What else could it mean?" is hardly a good reason to justify wording. > We have lots of people around here that have no problem determining > other possible meanings! Indeed, it isn't at all clear that this old > wording is intended to be a compile-time restriction. It could easily > be taken to mean that all tasks depend on the environment task no > matter where they are declared. But that interpretation makes no sense, so it can't be right. That interpretation would mean that a nested task keeps running after the procedure it's nested in returns. So it's looking at and modifying variables in the nested procedure that no longer exist. > > The new wording is clearly wrong. It's not clear to me why it was changed. > > The rationale seems to be, "We are fixing all of the restrictions > > that use "shall", and some that need clearer wording." Lesson: ARG > > should be wary of "clarifying" things that nobody would > > misinterpret, for fear of breaking things. > > We needed to clearly describe that this is a compile-time restriction > (since there are several restrictions which are *not* compile-time > restrictions - another thing that was screwed up.). I don't think it was ever intended that these be compile-time restrictions. The current wording seems to say that they are Post Comp rules, which may be checked at compile time or at link time, "unless otherwise specified". I understand that the "otherwise specified" was missing from some of them, but this particular restriction doesn't need that, so it's a Post Comp check. > > GNAT's interpretation agrees with Randy's. > > I'm pretty sure that the intent was understood, but the wording didn't > get within a country mile of explaining that intent. The new wording > doesn't help though, because it is wrong, even though it is a direct > inversion of the old wording. Which ought to make it clear that the > old wording wasn't any good, either. The new wording is not a direct inversion -- it's just wrong, because it loses the "directly". (Yes, I know "directly" is not formally defined. But I still claim it's meaning is obvious.) > (It should be noted that my original suggestion for changing this > wording was "No (nonenvironment) tasks depend directly on a task other > than the environment task of the partition." which more closely echoes > the original wording. No, that's wrong because it talks about tasks, not masters. >... But it still is unclear, given that there is no meaning to >"directly". See my e-mail of November 19, 2007. Of course there is a > Bob Duff reply that this is not broken -- which just goes to show you are > consistent!) > > I suspect that we need to say something about masters here, in order > to avoid the undefined "directly": Exactly. The problem with the current wording is that it says "task" which leaves out all the other kinds of masters. > "No task depends on a master other than the master of the environment > task of the partition." Closer... But "master of the environment task" would seem to mean the thing that the env task is declared in -- there is no such thing. We want to talk about the master that _is_ the env task (or more precisely, the master that is the execution of the body of the env task). And "of the partition" can be deleted; it's just noise. So: No task depends on a master other than the environment task. I'm leaving out "execution of the body of", because that's just overly pedantic. Or, we could define "direct" to be what it obviously ought to me -- a task depends directly on the innermost master that it depends upon. And then put back the original wording. Or, we could say that every task object and every access type whose designated type contains tasks is declared at library level. > This would seem to disallow all forms of nested tasks, which is the point. Right. > (I think there also should be an AARM note that this, and all of the > other restriction identifiers defined in "static semantics", are > intended to be checked at compile time. That's still not > crystal-clear.) No, that would be a language change. **************************************************************** From: Randy Brukardt Sent: Tuesday, March 16, 2010 1:21 PM > > We needed to clearly describe that this is a compile-time > > restriction (since there are several restrictions which are *not* > > compile-time restrictions - another thing that was screwed up.). > > I don't think it was ever intended that these be compile-time > restrictions. > The current wording seems to say that they are Post Comp rules, which > may be checked at compile time or at link time, "unless otherwise > specified". Sorry, "post-compilation checks". This one has no reason to be done at link-time (it doesn't depend on any other unit), but formally you are right. ... > > I suspect that we need to say something about masters here, in order > > to avoid the undefined "directly": > > Exactly. The problem with the current wording is that it says "task" > which leaves out all the other kinds of masters. > > > "No task depends on a master other than the master of the > > environment task of the partition." > > Closer... > > But "master of the environment task" would seem to mean the thing that > the env task is declared in -- there is no such thing. We want to > talk about the master that _is_ the env task (or more precisely, the > master that is the execution of the body of the env task). > > And "of the partition" can be deleted; it's just noise. > > So: > > No task depends on a master other than the environment task. > > I'm leaving out "execution of the body of", because that's just overly > pedantic. This doesn't make sense, "environment task" is not a master. I think you left too much out. We could say: "No task depends on a master other than that of the environment task." But that has the same problem as my original suggestion. Let's try it with all of the noise in and then see what we can leave out: "No task depends on a master other than the master of the execution of the body of the environment task of the partition." OK, "of the partition" is noise. "of the body" is more pedantic than necessary (or is "of the execution"?). So now we have: "No task depends on a master other than the master of the execution of the environment task." If we leave out "of the execution", then we have the wording I originally suggested, which you disliked (for good reason). We could change "execution" to "body" (effectively leaving out "of the execution"): "No task depends on a master other than the master of the body of the environment task." I think the above is about as simple as we can make it without introducing an ambiguity. > > This would seem to disallow all forms of nested tasks, > which is the point. > > Right. > > > (I think there also should be an AARM note that this, and all of the > > other restriction identifiers defined in "static semantics", are > > intended to be checked at compile time. That's still not > > crystal-clear.) > > No, that would be a language change. Sorry, my bad. The note should say that these are all intended to be post compilation checks, and that implementations are "encouraged" to check these at compile-time when possible. Note that Steve's redo of the Restrictions text allows restrictions that are just runtime restrictions (and not usually checked anywhere). So there is a bit of value explaining which these are. **************************************************************** From: Bob Duff Sent: Tuesday, March 16, 2010 4:28 PM > Sorry, "post-compilation checks". This one has no reason to be done at > link-time (it doesn't depend on any other unit), but formally you are right. Right. I think the idea (during Ada 9X) was that compilers would naturally check these at compile time whenever it makes sense. We made sure to say that Post Comp rules can always be checked early, if possible. And it simplifies the wording if we don't have to worry about which ones are compile time and which ones are link time. > > No task depends on a master other than the environment task. > > > > I'm leaving out "execution of the body of", because that's just > > overly pedantic. > > This doesn't make sense, "environment task" is not a master. The execution of its body is a master. And that's the master we're talking about. >...I think you > left too much out. We could say: > > "No task depends on a master other than that of the environment task." > > But that has the same problem as my original suggestion. > > Let's try it with all of the noise in and then see what we can leave out: > > "No task depends on a master other than the master of the execution of > the body of the environment task of the partition." Same problem. You want "the master that IS the execution of the body of the env task". Not the master of that master. Start with that, and then do your "leaving out" experiment. > "No task depends on a master other than the master of the body of the > environment task." > > I think the above is about as simple as we can make it without > introducing an ambiguity. Change "master of" to "master that is", and I'd say it's correct. I'd also tolerate: "No task depends on a master other than the master that is environment task." **************************************************************** From: Randy Brukardt Sent: Tuesday, March 16, 2010 5:07 PM ... > > > No task depends on a master other than the environment task. > > > > > > I'm leaving out "execution of the body of", because that's just > > > overly pedantic. > > > > This doesn't make sense, "environment task" is not a master. > > The execution of its body is a master. And that's the master we're > talking about. And that doesn't make sense -- even though it's what the language actually says (I had to look it up). Can't we make this clearer? > >...I think you > > left too much out. We could say: > > > > "No task depends on a master other than that of the environment task." > > > > But that has the same problem as my original suggestion. > > > > Let's try it with all of the noise in and then see what we can leave out: > > > > "No task depends on a master other than the master of the execution of > > the body of the environment task of the partition." > > Same problem. You want "the master that IS the execution of the body > of the env task". Not the master of that master. > Start with that, and then do your "leaving out" experiment. Ugh. After looking up the exact definition of "master", I see that you are right. But the whole thing (including the language definition) makes no sense. "is" just can't be true, because "master" is a noun and "execution" is a verb. There is no way that a "noun is a verb"! No wonder this stuff is so hard to make sense of. The natural meaning for master (a stack of boxes created/destroyed with the start/end of execution of various constructs) is far from the way its actual definition is worded. I'd be much happier if the wording used "master created by the execution of ..." instead of "master is the execution of ...", since that's much closer to the meaning. I suppose it is too late for this now. (In the case of Janus/Ada, there actually is a task master object that gets created and finalized; and when I get a round tuit, there will be one for objects as well [to fix various memory allocation issues]. I'm sure that colors my thinking somewhat.) > > "No task depends on a master other than the master of the body of > > the environment task." > > > > I think the above is about as simple as we can make it without > > introducing an ambiguity. > > Change "master of" to "master that is", and I'd say it's correct. "No task depends on a master other than the master that is the body of the environment task." Yuck. The "is" problem strikes again. A master "is" an execution by definition (no matter how much I hate that definition). But a master is *not* a task or subprogram -- those are static entities. A master might be created by a task (which makes it clear that execution is involved), or it "is" an execution (no matter how nonsensical that sounds), but it isn't a body of a task. So I'd really prefer: "No task depends on a master other than the master that created by the body of the environment task." But wording pedants probably would prefer: "No task depends on a master other than the master that is the execution of the body of the environment task." I don't think we can leave anything out here, if we're going to use "is". > I'd also tolerate: > > "No task depends on a master other than the master that is environment > task." Maybe, but I doubt the grammar police would. At least you need a "the" somewhere. "No task depends on a master other than the master that is {the} environment task." Again, I think this is a bit over-simplified, because of the "is" problem noted above. I'd rather one of the two mentioned previously. **************************************************************** From: Bob Duff Sent: Tuesday, March 16, 2010 5:53 PM > ... > > > > No task depends on a master other than the environment task. > > > > > > > > I'm leaving out "execution of the body of", because that's just > > > > overly pedantic. > > > > > > This doesn't make sense, "environment task" is not a master. > > > > The execution of its body is a master. And that's the master we're > > talking about. > > And that doesn't make sense -- even though it's what the language > actually says (I had to look it up). Can't we make this clearer? No, we can't make it clearer without rewriting a whole lot of verbiage. "If it ain't broke, don't fix it." ;-) By the way, I take a different attitude toward software: if it ain't broke, I'm still often willing to fix it to be more readable/maintainable/whatever-able. That's because I have things like full-coverage rules in case statements, to catch my mistakes. And regression test suites to catch my mistakes. But the RM is written in (a strange dialect of) English, and we have no compiler and no regression tests for it, so I think we should be rather more reluctant to fix things for aesthetic reasons. I also admit I've changed my attitude over the years. Anyway, fixing a bug in some obscure Restriction is not a good excuse to change fundamental terminology. > Ugh. After looking up the exact definition of "master", I see that you > are right. But the whole thing (including the language definition) > makes no sense. "is" just can't be true, because "master" is a noun and "execution" > is a verb. There is no way that a "noun is a verb"! "Execute" is a verb, but "execution" is a noun. (Well, I think it's a gerund, which is a verb form that behaves grammatically as a noun. I'm an Ada language lawyer, not an English language lawyer. ;-)) "The execution was slow." and "The apple is red." are grammatically similar. The definition of "master" as being "the execution of a construct" is my handiwork, so if it's unclear it's my fault. It was an attempt to correct the Ada 83 definition, which defines it as the "construct" itself, which is clearly wrong -- if procedure P is called recursively, then there are many masters, but only one procedure body. > No wonder this stuff is so hard to make sense of. The natural meaning > for master (a stack of boxes created/destroyed with the start/end of > execution of various constructs) is far from the way its actual definition is worded. Perhaps. It seems rather implementation oriented. In GNAT, a master is just an integer -- some sort of unique Id thingy (which surprised me when I learned that!). > I'd be much happier if the wording used "master created by the > execution of ..." instead of "master is the execution of ...", since > that's much closer to the meaning. I suppose it is too late for this now. Yes, too late. > (In the case of Janus/Ada, there actually is a task master object that > gets created and finalized; and when I get a round tuit, there will be > one for objects as well [to fix various memory allocation issues]. I'm > sure that colors my thinking somewhat.) > > > > "No task depends on a master other than the master of the body of > > > the environment task." > > > > > > I think the above is about as simple as we can make it without > > > introducing an ambiguity. > > > > Change "master of" to "master that is", and I'd say it's correct. > > "No task depends on a master other than the master that is the body of > the environment task." > > Yuck. The "is" problem strikes again. A master "is" an execution by > definition (no matter how much I hate that definition). But a master > is > *not* a task or subprogram -- those are static entities. A master > might be created by a task (which makes it clear that execution is > involved), or it "is" an execution (no matter how nonsensical that > sounds), but it isn't a body of a task. > > So I'd really prefer: > > "No task depends on a master other than the master that created by the > body of the environment task." > > But wording pedants probably would prefer: > > "No task depends on a master other than the master that is the > execution of the body of the environment task." Exactly! That's the one true correct wording. I could live with it. All the others are attempts to make it less pedantic and more readable, by assuming that when we say "env task" we assume people understand "execution of" and "body of" implicitly. > I don't think we can leave anything out here, if we're going to use "is". > > > I'd also tolerate: > > > > "No task depends on a master other than the master that is > > environment task." > > Maybe, but I doubt the grammar police would. At least you need a "the" > somewhere. > > "No task depends on a master other than the master that is {the} > environment task." Right, leaving out "the" was a typo. > Again, I think this is a bit over-simplified, because of the "is" > problem noted above. I'd rather one of the two mentioned previously. P.S. Take a look at the Ada 83 definition of "master" and dependence thereon. I just looked, and it defines "direct" dependence (in the obvious way). ****************************************************************