Bug 20255 - Simple Loop Labeling

[Mark Waddingham]

On 2017-08-11 12:51, Lagi Pittas via use-livecode wrote:
> Hi Mark,
> 
> I Beg to Differ about Next Repeat.
> 
> "It's not wat you do it's the way that you do it" comes to mind
> 
> Someone who writes spaghetti code can do it very well in any language 
> but
> its much more difficult without the structure brought in by the
> Algol/Pascal/Modula.

I'm not sure I quite get your point here...

Pure structured control flow does not allow any exit from a loop (it's 
definition is actually related to properties of the 'control-flow graph' 
(CFG) created by what are called 'basic blocks' when you analyze code at 
a more fundamental level than the syntax - structured control-flow only 
produces 'reducible CFGs' which have nice properties).

However, there are relatively straightforward transformation you can 
apply to mostly-structured-control-flow with 'exit' to turn it into pure 
structured control flow:

   repeat while tCondition
     ... before ...

     exit repeat

     ... after ...
   end while

Can be re-written as:

   repeat while tCondition and not tExit
     ... before ...

     put true into tExit

     if not tExit then
       ... after ...
     end if
   end repeat

The latter is 'pure structured control flow' - so 'exit loop' does no 
harm; the compiler can do an 'easy' transformation on the code to make 
it work; and that transformation is something which you have to do by 
hand if 'exit loop' is not available.

The key thing here is extending 'exit loop' to allow you to exit from 
more than one loop at once - if a language does not have this ability 
directly, then you have to write code to do it yourself (which is always 
possible - by the above transformation). Needing to exit multiple loops 
is not uncommon - which is why that extension might well be useful.

Similarly, 'next repeat' is often useful at least in the current loop - 
I'm not sure how useful it is for nested loops - it might not be. 
However, there is a transformation you can do for that as well:

   repeat while tCondition
     ... before ...

     next repeat

     ... after ...
   end while

Becomes:

   repeat while tCondition
     ... before ...

     put true into tNext

     if not tNext then
       ... after ...
     end if
   end while

So, having written that, clearly it is fine (it is actually the same as 
'exit repeat'; except that the boolean flag you need to create doesn't 
become part of the loop condition).

> If you only allow GOTOS within a procedure to a NON numeric label then 
> you
> can write structured code in any language.

Not strictly true - I think the rules (in terms of the actual underlying 
definition of structured control flow) is that you must not jump into a 
block of code which has a jump from elsewhere at the top. e.g.

void func()
{
    while(condition)
    {
      ...
foo:
       if (baz)
         goto bar:
    }

    while(othercondition)
    {
      ...
bar:
      if (foobar)
        goto foo:
    }
}

This produces a non-reducible CFG if memory serves. So as soon as you 
allow general GOTO, you end up with the ability to create irksome CFGs 
from the point of view of a compiler.

> Of course if it is time critical and every millisecond saved is 
> important
> then if spaghetti code is needed to get the speed then there is no 
> "best
> way" . But as I have said I have never missed Goto in nearly 40 Years 
> of
> Coding in High level languages (you can't not use them in Machine code
> which Dijkstra was acknowledging in his "Goto Considered Harmful"  
> article).

Indeed - the ability for a compiler to analyse code is the thing which 
makes it potentially run faster. With GOTO you can do the optimizations 
yourself; however, in almost all cases if you can only produce 
structured control flow, then a suitable competent compiler can do the 
work for you - making your code easier to read and maintain, whilst 
still not loosing performance.

Warmest Regards,

Mark.

P.S. I should point out that LCS is not a 'suitably competent compiler' 
as yet - however, that does not mean we should introduce language 
features which make it much harder for it to be given greater 
competence.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps