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

August Karlstrom <fusionfile@gmail.com>
Tue, 18 Jan 2011 20:01:16 +0100

          From comp.compilers

Related articles
[2 earlier articles]
Re: are there implementation reasons for not providing a break stateme fusionfile@gmail.com (August Karlstrom) (2011-01-14)
Re: are there implementation reasons for not providing a break stateme anton@mips.complang.tuwien.ac.at (2011-01-15)
Re: are there implementation reasons for not providing a break stateme bc@freeuk.com (BartC) (2011-01-16)
Re: are there implementation reasons for not providing a break stateme Pidgeot18@verizon.net (Joshua Cranmer) (2011-01-16)
Re: are there implementation reasons for not providing a break stateme richard@cogsci.ed.ac.uk (2011-01-18)
Re: are there implementation reasons for not providing a break stateme fusionfile@gmail.com (August Karlstrom) (2011-01-18)
Re: are there implementation reasons for not providing a break stateme fusionfile@gmail.com (August Karlstrom) (2011-01-18)
Re: are there implementation reasons for not providing a break stateme richard@cogsci.ed.ac.uk (2011-01-19)
Re: are there implementation reasons for not providing a break stateme bc@freeuk.com (Bartc) (2011-01-20)
Re: are there implementation reasons for not providing a break stateme pdjpurchase@googlemail.com (1Z) (2011-02-13)
Re: are there implementation reasons for not providing a break stateme thomas.mertes@gmx.at (tm) (2011-02-17)
Re: are there implementation reasons for not providing a break stateme idbaxter@semdesigns.com (Ira Baxter) (2011-03-07)
Re: are there implementation reasons for not providing a break stateme gah@ugcs.caltech.edu (glen herrmannsfeldt) (2011-03-08)
[1 later articles]
| List of all articles for this month |

From: August Karlstrom <fusionfile@gmail.com>
Newsgroups: comp.compilers
Date: Tue, 18 Jan 2011 20:01:16 +0100
Organization: A noiseless patient Spider
References: 11-01-043 11-01-055 11-01-078
Keywords: syntax, optimize
Posted-Date: 18 Jan 2011 23:33:07 EST

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



Post a followup to this message

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