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

noitalmost <noitalmost@cox.net>
Thu, 13 Jan 2011 13:09:29 -0500

          From comp.compilers

Related articles
are there implementation reasons for not providing a break statement i noitalmost@cox.net (noitalmost) (2011-01-13)
Re: are there implementation reasons for not providing a break stateme DrDiettrich1@aol.com (Hans-Peter Diettrich) (2011-01-14)
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)
[9 later articles]
| List of all articles for this month |

From: noitalmost <noitalmost@cox.net>
Newsgroups: comp.compilers
Date: Thu, 13 Jan 2011 13:09:29 -0500
Organization: Compilers Central
Keywords: design, question, comment

I've noticed that Wirth has continually rejected the idea of a break
statement and I was wonder why. Is this purely philosophical, or are
there code optimization reasons? Naive code for a break is trivial to
implement.


Is it easier to optimize loops with no break? That is, is the cost of
having extra booleans to control the loop less than the cost of
messing up the basic blocks with break?
[It's a little easy to optimize single-exit loops, but my impression is
that the motivation was more like salvation through suffering. -John]


Post a followup to this message

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