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

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

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