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

Hans-Peter Diettrich <DrDiettrich1@aol.com>
Fri, 14 Jan 2011 10:44:26 +0100

          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)
Re: are there implementation reasons for not providing a break stateme fusionfile@gmail.com (August Karlstrom) (2011-01-18)
[8 later articles]
| List of all articles for this month |

From: Hans-Peter Diettrich <DrDiettrich1@aol.com>
Newsgroups: comp.compilers
Date: Fri, 14 Jan 2011 10:44:26 +0100
Organization: Compilers Central
References: 11-01-043
Keywords: syntax, design
Posted-Date: 15 Jan 2011 00:23:08 EST

noitalmost schrieb:
> 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.


IMO the omission of breaks simplifies proofs of correctness, in
extension of the ban of goto's.


Both automated and manual verification BTW.


Similar considerations apply to the compiler itself. Wirth's LL(1)
languages result in simple (short) top-down parsers, which can not only
be written and understood easily by students, but which also leave not
much room for obscure grammar and inobvious compiler implementation
errors, and finally for cryptic compiler error messages. The latter is
the most important argument to me, considering the otherwise required
intensive error analysis in bottom-up parsers, with often questionable
results.


Code optimization IMO doesn't deserve more than the mere availability
of structured conditional and loop statements. Of course a "break" is
easy to implement, but it may prevent more important loop
optimizations.


But there exist cases where loop optimization is less important, and
even a simple "break" is not sufficient. In such cases even I prefer
direct jumps out of a loop or complex conditional code, to the code
section that handles specific states or errors. Kind of "come from"
instead of "go to" ;-)


DoDi


Post a followup to this message

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