Version 1.2 of ai05s/ai05-0216-1.txt

Unformatted version of ai05s/ai05-0216-1.txt version 1.2
Other versions for file ai05s/ai05-0216-1.txt

!standard D.7(3/3)          10-08-10 AI05-0216-1/02
!class binding interpretation 10-06-12
!status Amendment 2012 10-08-10
!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
Reword No_Task_Hierarchy to say what we meant.
!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) 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 doesn't want to depend on a subprogram -- that's precisely what this restriction is intended to prevent.
!corrigendum D.7(3)
Replace the paragraph:
All (nonenvironment) tasks depend directly on the environment task of the partition.
by:
No task depends on a master other than the library-level master.
!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).

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


Questions? Ask the ACAA Technical Agent