Bug 20255 - Simple Loop Labeling

[Lagi Pittas]

HI Mark,

I was probably reading more into this ...

"Certainly 'exit repeat ...' would not be harmful, 'next repeat ...' I'd
have to analyze more deeply"

I thought you didn't agree with USING next repeat as a structured way of
programming - Reading and understanding before my Brain was in gear.

But if nothing else we got another erudite exposition about programming
methodology (and I am being sincere here lest you think I'm yanking your
chain).

We could do a "Mark On Software"  a bit like "Joel on Software" - always
readable and you learn something - even if it's about Baking Bread (look it
up).

I think these threads in the mailing list with the engineers such as
yourself, Monte, Ali and Panos  is something I don't think any other
development system has - I might be wrong - and such a great way of honing
the system that I would like to thank you all again for LC (Other than the
 dot notation, the open language  .......
https://www.youtube.com/watch?v=Y7tvauOJMHo  ;-) )

Kindest Regards Lagi



On 11 August 2017 at 12:16, Mark Waddingham via use-livecode <
use-livecode at lists.runrev.com> wrote:

> 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
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>