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

"1Z" <pdjpurchase@googlemail.com> wrote in message
> On Jan 13, 6:09 pm, noitalmost <noitalm...@cox.net> wrote:
>> 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]
>
> A compromise would be to allow only one "middle exit" per loop, and
> to have it clearly indicated in the syntax rather than looking like
> any old statement.
>
> do{
> resource= getResource(counter);
> }
> exitwhen (resource.isOk());
> {
> releaseResource(resource);
> counter.increment();
> }


Another alternative, much better IMHO, is labelled-block exits.
Blocks may have labels. An exit <label> is allowed anywhere inside
the block, and passes control to statement following the end. The
above block would be recoded as:


      x: do {
            resource = getResource(counter);
            if (resource.isOk())
                    exit x;
            releaseResource(resource);
          counter.increment();
        }


This allows exits anywhere they are needed, (unlike
you-only-have-one-choice) nor is the block that one is exiting
ambiguous. The C break statement is infamous for causing the
Northeast Blackout some 20(?) years ago, when some bright soul wrapped
the construct containg the break inside another block, and thus the
break went to to wrong ("innermost containing") block exit.


while, if, exit are control-flow complete and never need extra boolean
flags as the Bohm-Jacopinin scheme requires. You don't need goto,
either.


--
Ira Baxter, CTO
www.semanticdesigns.com

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