Re: Question about the need for requeue as described in Rationale

["James A. Squire" <m193884@CSEHP3.MDC.COM>]

Robert Dewar wrote:
>
> James Squire said
>
> ""Indeed, the very astute reader might care to note that we can
> actually program this example in Ada 95 without using requeue
> at all." - Great! So why was it used if it wasn't needed?  For
> that matter, how can I do it in Ada 95 without requeue?"
>
> That strikes me as a bit odd. You often use features in programming
> languages that are not "needed", to improve the efficiency, readability,
> implementability, or simplicity of your code. After all it is obvious
> that the assignment statement in Ada is redundant in that any code you
> write using assignments could be written in an applicative style without
> assignments, but that's no reason to avoid assignments.

This is getting to be such a common occurrence that I wonder if I'm to
blame for being obscure.

My question was:  Why was this example used to illustrate in this
portion of the Rationale to illustrate why the requeue statement was
invented, if the example could also be done without using the requeue?
That struck me as a poor use of an example.

Someone else has since pointed out that a later section is the Rationale
was intended to serve that purpose and that this section (up front) was
simply meant to illustrate HOW it can be used.  I would nevertheless
argue that the text in this section (on Protected Types) does bring up a
limitation with tasking in Ada83 and then introduces the requeue
statement.  It seems quite logical to expect that the example would
clarify the need for the statement by showing something that could not
be done without it.  The example here didn't do that.

> A complex feature like requeue is never essential from a functionality
> point of view (though it might be critical on a given implementation
> from a performance point of view). Clearly anything in Ada 95 that can
> be written with requeue can be written without, but possibly at the
> expense of clarity and efficiency.

Then the Rationale should have made that clear.  I would have
understood.
--
James Squire
MDA Avionics Tools & Processes
ja_squire@csehp3.mdc.com
Opinions expressed here are my own and NOT my company's
"one of these days I'm going to better myself by going to Knight school"
"You'll be a web knight instead of a web page!"