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

"Bartc" <bc@freeuk.com>
Thu, 20 Jan 2011 16:28:00 -0000

          From comp.compilers

Related articles
[4 earlier articles]
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)
Re: are there implementation reasons for not providing a break stateme robin51@dodo.com.au (robin) (2011-03-11)
| List of all articles for this month |

From: "Bartc" <bc@freeuk.com>
Newsgroups: comp.compilers
Date: Thu, 20 Jan 2011 16:28:00 -0000
Organization: A noiseless patient Spider
References: 11-01-043 11-01-055 11-01-078
Keywords: syntax, design, optimize
Posted-Date: 21 Jan 2011 22:10:59 EST

"Richard Tobin" <richard@cogsci.ed.ac.uk> wrote in message
> August Karlstrom <fusionfile@gmail.com> wrote:
>
>>With no break statements you will know that the loop condition will be
>>false when the loop has finished. This makes it easier to reason about
>>the correctness of a program.


(I admit I know nothing about proving correctness of programs. How
exactly do you go about it? Who or what is to judge whether a program
is correct; is there some sort of specification to compare against?
And if so, how do you know the specification is correct...?)


> 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;
> }


This is trivial if the conditional break statement is at the top
level. If the breaks are deeper down then it's not so simple.


--
Bartc



Post a followup to this message

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