Bug 20255 - Simple Loop Labeling

Lagi Pittas iphonelagi at gmail.com
Fri Aug 11 06:51:06 EDT 2017

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

I have not used a Goto Since I used Fortran, Basic  and Cobol at Uni  they
introduced Pascal later and it was a breath of fresh air.
If you really want to be pedantic down at the assembler and machine code
level it's Gotos all the way BNE,  BCC, BEQ anyone?

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

What is EXIT to Top if not a GOTO so rules are always there to be broken in
certain  cases - a simple comment next to the "NEXT REPEAT"  and all is

The problem arises when procedure with "jumps" in (EXIT, NEXT REPEAT, LOOP
etc are too big to fit on a page.

Personally I hate too many if then else's and many a time code the "If
then" inline because the second one will never be executed - the amount of
extra time in execution is minimal.  I don't do it too often but usually if
the routine starts to get too wide for the screen, but then I might break
each one up into its own Procedure and use a switch statement to call them.

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).

Regards Lagi

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

> On 2017-08-10 21:33, Dr. Hawkins via use-livecode wrote:
>> In fact, what I would *like* is modern Fortran style labelling or
>> something
>> like that, and the ability to the those labels to controls like next and
>> exit.  This, however, would accomplish so much with so little.
> Thinking out loud here and taking into account suggestions people have
> made in the past...
> Naming loops in a syntactic way certainly sounds like a useful thing to do:
> repeat for each line tLine in tContainer named LineLoop
>   repeat for each item tItem in tLine named ItemLoop
>     if some complicated condition then
>       exit repeat ItemLoop
>     else if some other complicated condition then
>       exit repeat LineLoop
>     end if
>     -- do other stuff
>     if some even more complicated condition then
>       next repeat LineLoop
>     end if
>   end repeat ItemLoop
> end repeat LineLoop
> Certainly 'exit repeat ...' would not be harmful, 'next repeat ...' I'd
> have to analyze more deeply.
> The main problem with GOTO (apart from the ability to create very hard to
> understand code) is that it allows creation of what is called 'unstructured
> control-flow'. Basically that means that you have to work *exceptionally*
> hard to untangle it in a compile to perform any sort of reasonable
> optimization.
> At present LiveCode only allows you to produce 'structured control flow'.
> Adding 'next repeat ...', doesn't change that... However, 'next repeat ...'
> is not so clear (I think it is probably fine, but need to check some
> algorithmics).
> The only other issue with the above (beyond implementing it) is the
> syntax... It would reserve 'named' as a non-operator in this context. If we
> did ever have reason to have 'X named Y' then in repeats you'd have to do:
>   repeat for each line tLine in (tContainer named ...) named ...
> Although - without knowing what 'named' might do as an operator, or being
> able to think of anything it could do - that is probably a safe addition
> from that point of view.
> (Of course we could use 'labelled' instead of 'named' in the repeat
> context - 'labelled' seems for some reason less likely to be leveragable as
> a binary operator!)
> Warmest Regards,
> Mark.
> --
> 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

More information about the Use-livecode mailing list