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

"noitalmost" <noitalmost@cox.net> wrote in message
> 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?


I've no idea, except bloody-mindedness on the part of the language designer.


Because in theory it is possible to program with no goto statements,
no multilevel breaks, no multiple returns (even no variables, and no
statements probably, just functions), some designers think it makes
their language elegant and clean.


That's in theory. In practice, you need all this stuff to get the job
done quickly and simply. And if you don't overdo the gotos and breaks,
I can't see that it's a problem.


> Naive code for a break is trivial to implement.


Many syntax features *are* often trivial to code, which is why it's
surprising languages such as C-derivatives stick with the original
crude statements (such as the C for-statement), rather than introduce
more powerful constructs.


(My designs have goto, multiple, multi-level breaks (in fact four
varieties of loop control: restart, redo, next and exit(break)), and
multiple returns. Why not? The goto doesn't get used much, until
perhaps the day you have to translate from a language which *does* use
it; or use this language as the target of another language with
radically different constructs. So it's there just in case.)


> 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?


Just a week ago I translated a benchmark using loops with breaks, into
a language without breaks. So I was writing stuff like:
loop1cond:=TRUE; while loop1cond do... together with more convoluted,
more deeply indented code. What a complete waste of time!


And as you say, it was likely no more efficient either. If having a
break statement really is a little less efficient, than that's the
programmer's choice to use it or not.


> [It's a little easy to optimize single-exit loops, but


It's possible also to have a single exit loop that is in the middle
(or anyway in the loop body), rather that at just one end.


> my impression is that the motivation was more like salvation through
> suffering. -John]


Exactly.


--
Bartc

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