At 10:02 AM 3/20/98 -0600, Samuel Mize wrote:
>Greetings,
>
>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
"goto".
>
>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.
>
>
>Best,
>Sam Mize

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