Re: are there implementation reasons for not providing a break statement in an imperative language?

On 2011-01-18 15:54, Richard Tobin wrote:
> A break can trivially be removed by a simple source transformation:
>
> while(condition) {
> pre;
> if(something)
> break;
> post;
> }
>
> boolean stop = false;
> while(!stop&& condition) {
> pre;
> if(something)
> stop = true;
> if(!stop)
> post;
> }


If your pre and post statements refer to a loop invariant the
precondition should be checked before the loop is entered and the
postcondition should be unconditionally checked at the end of each
turn.


> Is this easier to reason about? Not for a computer: it could do the
> transformation itself. A human doing certain particular kinds of
> reasoning might find it easier, but a human just reading the program
> is likely to find it less clear.


With a "structured" ("goto-less") loop a human only have to look at
the loop guard rather than skimming through all of its contained
statements in order to know what will hold true when the loop is
finished (if it ever finishes that is). To me that is an obvious
advantage.


I have also found that when I program with structured loops I often
have to rethink the problem, as the language prevents me from
routinely throwing in some break statement here and there, and come up
with a more elegant solution.


> A programmer may be able to find a more natural alternative than the
> one above, but even if he does the language has prevented him from
> expressing his intention in the obvious way.


The same can be said about programming without goto statements.


August


--
The competent programmer is fully aware of the limited size of his own
skull. He therefore approaches his task with full humility, and avoids
clever tricks like the plague. --Edsger Dijkstra

Return to the comp.compilers page.
Search the comp.compilers archives again.