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@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 ~ m...@livecode.com ~ http://www.livecode.com/ > LiveCode: Everyone can create apps > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode