search

pat-rogers / Ada-202x-WG9-Informal-Review

This is the place for WG 9 members to submit informal comments on the 202x source document. (This is not the formal ballot that WG 9 will hold later in the process.)
0 stars 0 forks source link

9.5 (28/5) "is nonblocking" vs "Nonblocking is True" #156

Open nholsti opened 3 years ago

nholsti commented 3 years ago

This paragraph differs from its surroundings by using the wording "subprogram is nonblocking" instead of "the Nonblocking aspect of the subprogram is True". Is this intentional, or should it be changed for uniformity and precision? In principle, the property of "being nonblocking" is not the same as having Nonblocking = True.

nholsti commented 3 years ago

Ah, it seems I had forgotten that the term "is nonblocking" is defined in RM 9.5 (21/5) as equivalent to Nonblocking = True. So there is no error, just a perhaps confusing variation in wording in adjacent paragraphs.

ARG-Editor commented 3 years ago

Seems insufficiently broken for a change at this time.

nholsti commented 3 years ago

It seems to me that the definition of "is nonblocking" in RM 9.5 (21/5) is a bad one, because the statement "the subprogram [or other entity] S is nonblocking" has an intrinsic meaning without this definition, which is that no action in S can block the task executing S (using the other RM definitions of which actions can block a task). The definition in RM 9.5 (21/5) gives this statement another meaning, which is quite likely to lead to confusion and mistakes (as evidenced by me creating this issue in the first place).

The definition "is nonblocking" in RM 9.5 (21/5) seems to be used rarely, even in this subclause. I think it should either be deleted, and all its uses changed to refer directly to the Nonblocking aspect, or it should be changed to use a term other than (just) nonblocking.

Note that the other case (Nonblocking = False) is defined in RM 9.5 (21/5) as the meaning of the two-word term "allows blocking". The term (if any) defined for Nonblocking = True should be some analogous qualification of "blocking". For example, if Nonblocking is True for an entity, we could say that the entity forbids blocking, or that the entity is denied blocking.

The definition of "nonblocking region" in RM 9.5 (43/5) also suffers from this problem -- the statement "this region (of the program) is nonblocking" has an intrinsic meaning without this definition -- but I think it is less likely to be misunderstood, so I would let it stand, although I would prefer it, too, to be changed to use a qualification such as "forbids" or "is denied", as above.

nholsti commented 3 years ago

(Sorry, I mistakenly closed this issue by a mistaken stroke of the tocuhpad.)

ARG-Editor commented 3 years ago

It's pretty standard in the RM that => True is defined to mean that the entity "is some_aspect". For instance, a package is pure, a subprogram is inlined, and a type is packed. To use some other terminology here would be unusual. It suggests that the name of the aspect is wrong. But we (the ARG) spent quite a bit of time on choosing the name of the aspect, most of the other choices conflicted more with other meanings.

It's not unusual that the formal use of a term in the RM is subtly different than an informal use. The most obvious offender is "part" (which includes the object itself formally, no one thinks that informally). Moreover, I don't believe that most people would find the difference confusing (obviously you do), that is that "is nonblocking" as a static term generally requires a declaration to that effect. Your informal use only is meaningful dynamically (you could only say that a specific execution does not block; it's undecidable in general whether any chunk of code blocks), so it's really a different use case.

Finally (and least important), changing the terminology (which necessarily would require changing the name of the aspect, see above), would almost certainly delay the RM an additional 6 months. We'd need to decide an alternative terminology and aspect naming at our upcoming meeting, then do the necessary rewording (which probably would take more than a week's work, since the aspect is so widely uses) and separately approve that at a later meeting or via letter ballot. That would certainly mean missing the deadline for the upcoming SC 22 meeting and thus add another lengthy ballot period into our schedule.

I don't think that the supposed confusion is enough here to make such a major change this late in the process. So I continue to mark this issue as "no action". (If I was going to do anything, I'd use "is nonblocking" more often in order to reduce the number of places with the lengthier wording which someone might think has a different meaning.)

If you would like to have the full ARG review this issue, please contact me (before May 28th) and I'll put it on the agenda for the upcoming meeting.

nholsti commented 3 years ago

Thanks for the long answer and explanation. I accept your conclusion and do not ask for further review by the ARG.