At 10:02 AM 3/20/98 -0600, Samuel Mize wrote:
>Concerning the loop "continue" statement:
>In June of 1997 I put on comp.lang.ada the second draft of a paper
>titled "Goto Considered Necessary." The overall point of the paper
>was that gotos are sometimes needed in Ada, and one of the reasons was
>loop "continue" logic.
>If you want to see the paper, search c.l.a with Deja News, searching
>for "goto considered necessary" on Jun 11 1997. There was significant
>follow-up discussion, you can read the thread that this post started.
>One point in that paper is: "if your code needs a "goto" to work
>efficiently (or at all), you may have overlooked a simpler, better
>design." This includes loop "continue" statements. Sometimes they're
>the best structure, but they can often be designed around.
>The paper includes an example of code from Knuth's article about gotos
>in the December 1974 Computing Surveys. Now, this is an excellent
>article, and I recommend it. However, the particular code was cited
>as an example of a case where a "continue" is the best, clearest
>structure. It took me maybe 15 minutes to rework it without the
>"continue," resulting in a clearer and equally-efficient design. This
>does not prove that "continue"s are always less desireable, but it does
>show the benefit of considering them a candidate for re-structuring.
>One point that was brought up in the discussion about the paper was
>that using a "goto" prevents a common maintenance error. If some code
>must be added to the end of the loop to set up for the next iteration,
>a "continue" will skip that code. With the goto/label approach, there
>is a clear place at the end of the loop for any such set-up code.
>Here's a much-cut-down version of the paper's summary:
>a) In general, "goto" statements should be avoided.
>b) As a rule of thumb, if your code needs a "goto" to work efficiently
> (or at all), you may have overlooked a simpler, better design.
>c) Exceptions to "goto" avoidance:
> c1) a well-defined code structure that is not supported in the language.
> c2) machine-generated code
> c3) Finite State Machines (FMSs)
> c4) Other usages are suspect, but may be OK.
>d) an extraneous state variable or other kludge is no improvement on a
>e) Norm Cohen recommended Knuth's article in the December 1974 Computing
> Surveys as "the best discussion I've ever seen of the goto issue."
> Other respected Ada developers have concurred.
>f) The shared Ada culture avoids "goto" statements.
Thanks, Sam, for the reference to your message and to Knuth's article. I
have read Knuth's paper years ago and it is excellent.
Let me remind folks that my message was motivated to understand why
continue was not included and not to start a ground swell for change...mike
Mike Kamrad [log in to unmask]
BlazeNet 1.508.370.4343 x139
Suite 300 1.508.370.4344 FAX
1671 Worcester Road
Framingham MA 01701