Re: Bug 20255 - Simple Loop Labeling
Why not? It's in the dictionary! au·to·mag·ic·al·ly ˌôdəˈmajək(ə)lē/ adverbinformal adverb: automagically • (especially in relation to the operation of a computer process) automatically and in a way that seems ingenious, inexplicable, or magical. "just type in the name of what you want to listen to, and it automagically appears on your computer" Bob S > On Aug 11, 2017, at 09:12 , Dr. Hawkins via use-livecode > wrote: > > Oooh, yes; automagical maintenance would be wonderful! (really? my > spellchecker recognizes "automagical" as a word?) ___ 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
Re: Bug 20255 - Simple Loop Labeling
Ehm... some complicated condition might be 5 lines of code. Bob S > On Aug 10, 2017, at 18:38 , Mark Wieder via use-livecode > wrote: > >> if some complicated condition then # I’m a makin’ spaghetti >>— spaghetti >> end if # I’m a makin' spaghetti > > I would actually argue against this. For me, the useful part would be > > end if # some complicated condition > > Otherwise, making the user come up with a comment that basically says "some > complicated condition" anyway, and doing all the maintentance you've > described above sounds like a lot of work for very little gain. > > -- > Mark Wieder > ahsoftw...@gmail.com ___ 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
Re: Bug 20255 - Simple Loop Labeling
Wait, you're saying that this is a win win, where everybody... WINS??? BAN it! ;-) Bob S > On Aug 10, 2017, at 11:55 , J. Landman Gay via use-livecode > wrote: > > Well, you don't actually have to use the tooltip. It wouldn't interfere with > your current method and would enhance the editor for those who don't want the > clutter. > > Best of both worlds. > -- > Jacqueline Landman Gay | jac...@hyperactivesw.com > HyperActive Software | http://www.hyperactivesw.com ___ 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
Re: Bug 20255 - Simple Loop Labeling
On 08/11/2017 08:50 AM, Mark Waddingham via use-livecode wrote: > they aren't likely to happen until someone actually has some 'time' to do the necessary thinking Um. Yes. That would be you. -- Mark Wieder ahsoftw...@gmail.com ___ 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
Re: Bug 20255 - Simple Loop Labeling
On Thu, Aug 10, 2017 at 6:24 PM, Monte Goulding via use-livecode < use-livecode@lists.runrev.com> wrote: > > 2. automagical maintenance if the comments exist and you change the > conditio > Oooh, yes; automagical maintenance would be wonderful! (really? my spellchecker recognizes "automagical" as a word?) And to be clear, I am *NOT* suggesting in any way that Livecode get a GOTO; I was suggesting that there are *very* rare cases where they are useful. (I can probably count the number I have *ever* used on my fingers, possibly of one hand [unless you count the ones driven by performance and how memory was accessed in interpreters, but that still gave you two per program {jump to high/slow area for onetime setup, then to mid-memory main loop above time critical subroutines, and possibly a third from the end of the main loop to the beginning if the language couldn't loop forever}]). (and as dust drifts about the cobwebs of my memory, I think that on what I think of as "my goto" was used instead of putting the common section into another routine to avoid the computational cost of that context switch; this was in the recursive core routine that was called zillions of times in the program which ran for a couple of days [initially more than that]. If you need that kind of optimization/performance, livecode will be fairly low on your list of choices . . .) -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ 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
Re: Bug 20255 - Simple Loop Labeling
On 2017-08-11 17:40, Mark Wieder via use-livecode wrote: On 08/11/2017 02:51 AM, Mark Waddingham via use-livecode wrote: Naming loops in a syntactic way certainly sounds like a useful thing to do: I should point out here that Robert Cailliau has complained about the lack of named loops as one of the main deficiencies of LiveCode for some ten years now. I know - it has come up numerous times. I wasn't presenting it as a new idea - because it most certainly isn't (although it isn't all that common, when you look across the vast range of programming languages which do exist...) Robert has also suggested a 'with' construct, allowing quotes in quoted strings (I think his suggestion is "") and probably many other things (he did a talk many years ago which listed quite a few...) The reality is though, as there has never been a truly concrete proposal for any of those which take into account all the constraints of the current implementation - they aren't likely to happen until someone actually has some 'time' to do the necessary thinking that is required to turn them from a theoretical notion, to an implementable specification aligned with what could actually be done. As the topic of naming of loops came up (admittedly from a different point of view) it seemed useful to garner some more detail on the idea - since it was on quite a few people's minds :) Warmest Regards, Mark. -- 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
Re: Bug 20255 - Simple Loop Labeling
On 08/11/2017 02:51 AM, Mark Waddingham via use-livecode wrote: Naming loops in a syntactic way certainly sounds like a useful thing to do: I should point out here that Robert Cailliau has complained about the lack of named loops as one of the main deficiencies of LiveCode for some ten years now. -- Mark Wieder ahsoftw...@gmail.com ___ 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
RE: Bug 20255 - Simple Loop Labeling
I did not want to be the one to rehash this again but I would love to have this as I do it manually all the time with comments. +1 Ralph DiMola IT Director Evergreen Information Services rdim...@evergreeninfo.net -Original Message- From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of Mark Waddingham via use-livecode Sent: Friday, August 11, 2017 5:51 AM To: How to use LiveCode Cc: Mark Waddingham Subject: Re: Bug 20255 - Simple Loop Labeling 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 ~ 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
Re: Bug 20255 - Simple Loop Labeling
On 2017-08-11 14:56, Lagi Pittas via use-livecode wrote: 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. Sorry - I should have made that more clear - 'next repeat' and 'exit repeat' are definitely immeasurably better than GOTO or hand-coded bools. Just to clarify - I meant 'harmful with respect analyses the compiler might want to do in the future' when not tied to the directly enclosing loop. I answered my own question by responding to you though - it is almost the same transform required as for 'exit repeat' :) Warmest Regards, Mark. -- 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
Re: Bug 20255 - Simple Loop Labeling
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 s
Re: Bug 20255 - Simple Loop Labeling
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
Re: Bug 20255 - Simple Loop Labeling
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 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 good. 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@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 ~ 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
Re: Bug 20255 - Simple Loop Labeling
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 ~ 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
Re: Bug 20255 - Simple Loop Labeling
+100 To Mark for that one In fact it could copy the complicated condition AND any comment after it - best of all possible worlds Lagi On 11 August 2017 at 02:38, Mark Wieder via use-livecode < use-livecode@lists.runrev.com> wrote: > On 08/10/2017 06:24 PM, Monte Goulding via use-livecode wrote: > > So we need: >> >> 1. an optional way to add such comments (even users that want them might >> not want them unless they are making spaghetti) >> 2. automagical maintenance if the comments exist and you change the >> condition >> 3. work out whether tags rather than the actual condition is what people >> really want because the condition might add too much clutter: >> >> if some complicated condition then # I’m a makin’ spaghetti >> — spaghetti >> end if # I’m a makin' spaghetti >> > > I would actually argue against this. For me, the useful part would be > > end if # some complicated condition > > Otherwise, making the user come up with a comment that basically says > "some complicated condition" anyway, and doing all the maintentance you've > described above sounds like a lot of work for very little gain. > > -- > Mark Wieder > ahsoftw...@gmail.com > > > ___ > 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
Re: Bug 20255 - Simple Loop Labeling
I like and use end if #some complicated condition On Thu, Aug 10, 2017 at 10:02 PM, Monte Goulding via use-livecode < use-livecode@lists.runrev.com> wrote: > > > On 11 Aug 2017, at 11:54 am, Mark Wieder via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > > What would you put as a comment after the 'end if' using your proposed > approach? The original comment for the 'if' statement or something else? > Would you force the user to create comments for each 'else if' as well? > > I’m not sure if I proposed anything… was just wondering out loud… but yes > I think if a tag approach is used then > > if some complicated condition then # commontag > > else if some other complicated condition then # commontag > > else if some yet again complicated condition then # commontag > > else # commontag > > end if # commontag > > Now you would know no matter how much spaghetti you write or how > complicated your conditions are which control structure each if/else > if/else/end if belongs to. > > Cheers > > Monte > ___ > 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 > -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, "This is good." ___ 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
Re: Bug 20255 - Simple Loop Labeling
> On 11 Aug 2017, at 11:54 am, Mark Wieder via use-livecode > wrote: > > What would you put as a comment after the 'end if' using your proposed > approach? The original comment for the 'if' statement or something else? > Would you force the user to create comments for each 'else if' as well? I’m not sure if I proposed anything… was just wondering out loud… but yes I think if a tag approach is used then if some complicated condition then # commontag else if some other complicated condition then # commontag else if some yet again complicated condition then # commontag else # commontag end if # commontag Now you would know no matter how much spaghetti you write or how complicated your conditions are which control structure each if/else if/else/end if belongs to. Cheers Monte ___ 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
Re: Bug 20255 - Simple Loop Labeling
On 08/10/2017 06:40 PM, Monte Goulding via use-livecode wrote: On 11 Aug 2017, at 11:38 am, Mark Wieder via use-livecode wrote: I would actually argue against this. For me, the useful part would be end if # some complicated condition Otherwise, making the user come up with a comment that basically says "some complicated condition" anyway, and doing all the maintentance you've described above sounds like a lot of work for very little gain. OK but: if some complicated condition then else if some other complicated condition then else if some yet again complicated condition then else end if # what do you put here? I would code that as switch someRelatedVariable case someComplicatedCondition break case someOtherComplicatedCondition break case someYetAgainComplicatedCondition break default end switch -- someRelatedVariable but otherwise, I assume the 'end if' is attached to the 'if' and use that condition as the comment. The whole point of this isn't to create useless comments, but to ensure that a large structure can still be parsed visually. By the time I get to an 'end if' statement a few screens down I'll want to know what the original 'if' statement was, and with two spaces of indentation that's often hard to grok. What would you put as a comment after the 'end if' using your proposed approach? The original comment for the 'if' statement or something else? Would you force the user to create comments for each 'else if' as well? -- Mark Wieder ahsoftw...@gmail.com ___ 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
Re: Bug 20255 - Simple Loop Labeling
> On 11 Aug 2017, at 11:38 am, Mark Wieder via use-livecode > wrote: > > I would actually argue against this. For me, the useful part would be > > end if # some complicated condition > > Otherwise, making the user come up with a comment that basically says "some > complicated condition" anyway, and doing all the maintentance you've > described above sounds like a lot of work for very little gain. OK but: if some complicated condition then else if some other complicated condition then else if some yet again complicated condition then else end if # what do you put here? ___ 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
Re: Bug 20255 - Simple Loop Labeling
On 08/10/2017 06:24 PM, Monte Goulding via use-livecode wrote: So we need: 1. an optional way to add such comments (even users that want them might not want them unless they are making spaghetti) 2. automagical maintenance if the comments exist and you change the condition 3. work out whether tags rather than the actual condition is what people really want because the condition might add too much clutter: if some complicated condition then # I’m a makin’ spaghetti — spaghetti end if # I’m a makin' spaghetti I would actually argue against this. For me, the useful part would be end if # some complicated condition Otherwise, making the user come up with a comment that basically says "some complicated condition" anyway, and doing all the maintentance you've described above sounds like a lot of work for very little gain. -- Mark Wieder ahsoftw...@gmail.com ___ 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
Re: Bug 20255 - Simple Loop Labeling
> On 11 Aug 2017, at 4:55 am, J. Landman Gay via use-livecode > wrote: > > Well, you don't actually have to use the tooltip. It wouldn't interfere with > your current method and would enhance the editor for those who don't want the > clutter. Having thought about this a bit I think the issue with the tooltip is if it is worked out dynamically then if you’ve done something to stuff up your control structures then it won’t work out the right thing anyway… when the comments are most useful is in exactly that scenario so perhaps comments is the way to go for those that wan them. So we need: 1. an optional way to add such comments (even users that want them might not want them unless they are making spaghetti) 2. automagical maintenance if the comments exist and you change the condition 3. work out whether tags rather than the actual condition is what people really want because the condition might add too much clutter: if some complicated condition then # I’m a makin’ spaghetti — spaghetti end if # I’m a makin' spaghetti Cheers Monte ___ 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
Re: Bug 20255 - Simple Loop Labeling
On Thu, Aug 10, 2017 at 1:02 AM, panagiotis merakos via use-livecode < use-livecode@lists.runrev.com> wrote: > > I personally like this idea, and I find it pretty useful. And this does not > sound too difficult to implement. > That was the flash of insight that triggered me: something was *already* happening that could bee piggy-backed. > > But I am not sure if everyone will like it, so if we do it, we should > probably add a pref to turn it on/off. > That makes sense--but in my narrow proposal, it would only happen if someone added the comment. 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. In fact, I think I like Mark's labeling even better, if the preference could be set to always include that moment on the terminating statement. And Monte's mouseover tooltip, and the ability to jump to the matching end, would be great . . . While such things are being discussed, everyone realizes that indenting is horribly broken in 8.x, don't they? -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ 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
Re: Bug 20255 - Simple Loop Labeling
Well, you don't actually have to use the tooltip. It wouldn't interfere with your current method and would enhance the editor for those who don't want the clutter. Best of both worlds. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On August 10, 2017 1:22:44 PM Richard Gaskin via use-livecode wrote: If we're taking votes, respectfully count mine as -1 on using tooltips for this. Labels within code are most useful when visible. If we need to read the code carefully enough to figure out where we should aim the mouse, then aim the mouse, then pause waiting for the tooltip to appear, the benefit of labels is diminished. I use comments, as most others here seem to do too. Quite happy to just keep doing that - it only costs two extra characters ("--"), is simple and flexible, and immediately self-evident when skimming code. -- Richard Gaskin Fourth World Systems Bob Sneidar wrote: +1 on the tooltip. I also comment end statements in nested loops or control structures, but it gets cluttery when trying to read through the script. Bob S On Aug 10, 2017, at 08:28 , Mark Wieder via use-livecode lists.runrev.com> wrote: On 08/10/2017 03:00 AM, Monte Goulding via use-livecode wrote: I wonder whether a mouse over tooltip would work just as well. Is this something you want to be able to see _all_ the time or just if you get confused about where you are? Hmmm... I think a tooltip could be especially useful for exit and break statements in nested conditionals where it's not always obvious at first glance. -- Mark Wieder ___ 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
Re: Bug 20255 - Simple Loop Labeling
If we're taking votes, respectfully count mine as -1 on using tooltips for this. Labels within code are most useful when visible. If we need to read the code carefully enough to figure out where we should aim the mouse, then aim the mouse, then pause waiting for the tooltip to appear, the benefit of labels is diminished. I use comments, as most others here seem to do too. Quite happy to just keep doing that - it only costs two extra characters ("--"), is simple and flexible, and immediately self-evident when skimming code. -- Richard Gaskin Fourth World Systems Bob Sneidar wrote: +1 on the tooltip. I also comment end statements in nested loops or control structures, but it gets cluttery when trying to read through the script. Bob S On Aug 10, 2017, at 08:28 , Mark Wieder via use-livecode wrote: On 08/10/2017 03:00 AM, Monte Goulding via use-livecode wrote: I wonder whether a mouse over tooltip would work just as well. Is this something you want to be able to see _all_ the time or just if you get confused about where you are? Hmmm... I think a tooltip could be especially useful for exit and break statements in nested conditionals where it's not always obvious at first glance. -- Mark Wieder ___ 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
Re: Bug 20255 - Simple Loop Labeling
I like the tooltip idea. It's less invasive than altering the script itself, yet still easy to access. Variable values work the same way and I find that to be a good balance between accessibility and convenience. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On August 10, 2017 10:53:34 AM Mike Kerner via use-livecode wrote: It can, but as of now we don't have another good way of matching structures on a permanent basis so that if you, for instance, remove the "if" or "repeat" on the top, the "end if" or "end repeat" on the bottom goes away, too, or if you change the condition the label on the end changes. On Thu, Aug 10, 2017 at 11:39 AM, Bob Sneidar via use-livecode < use-livecode@lists.runrev.com> wrote: +1 on the tooltip. I also comment end statements in nested loops or control structures, but it gets cluttery when trying to read through the script. Bob S > On Aug 10, 2017, at 08:28 , Mark Wieder via use-livecode < use-livecode@lists.runrev.com> wrote: > > On 08/10/2017 03:00 AM, Monte Goulding via use-livecode wrote: > >> I wonder whether a mouse over tooltip would work just as well. Is this something you want to be able to see _all_ the time or just if you get confused about where you are? > > Hmmm... I think a tooltip could be especially useful for exit and break statements in nested conditionals where it's not always obvious at first glance. > > -- > Mark Wieder > ahsoftw...@gmail.com ___ 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 -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, "This is good." ___ 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
Re: Bug 20255 - Simple Loop Labeling
It can, but as of now we don't have another good way of matching structures on a permanent basis so that if you, for instance, remove the "if" or "repeat" on the top, the "end if" or "end repeat" on the bottom goes away, too, or if you change the condition the label on the end changes. On Thu, Aug 10, 2017 at 11:39 AM, Bob Sneidar via use-livecode < use-livecode@lists.runrev.com> wrote: > +1 on the tooltip. I also comment end statements in nested loops or > control structures, but it gets cluttery when trying to read through the > script. > > Bob S > > > > On Aug 10, 2017, at 08:28 , Mark Wieder via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > > On 08/10/2017 03:00 AM, Monte Goulding via use-livecode wrote: > > > >> I wonder whether a mouse over tooltip would work just as well. Is this > something you want to be able to see _all_ the time or just if you get > confused about where you are? > > > > Hmmm... I think a tooltip could be especially useful for exit and break > statements in nested conditionals where it's not always obvious at first > glance. > > > > -- > > Mark Wieder > > ahsoftw...@gmail.com > > > ___ > 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 > -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, "This is good." ___ 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
Re: Bug 20255 - Simple Loop Labeling
+1 on the tooltip. I also comment end statements in nested loops or control structures, but it gets cluttery when trying to read through the script. Bob S > On Aug 10, 2017, at 08:28 , Mark Wieder via use-livecode > wrote: > > On 08/10/2017 03:00 AM, Monte Goulding via use-livecode wrote: > >> I wonder whether a mouse over tooltip would work just as well. Is this >> something you want to be able to see _all_ the time or just if you get >> confused about where you are? > > Hmmm... I think a tooltip could be especially useful for exit and break > statements in nested conditionals where it's not always obvious at first > glance. > > -- > Mark Wieder > ahsoftw...@gmail.com ___ 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
Re: Bug 20255 - Simple Loop Labeling
On 08/10/2017 03:00 AM, Monte Goulding via use-livecode wrote: I wonder whether a mouse over tooltip would work just as well. Is this something you want to be able to see _all_ the time or just if you get confused about where you are? Hmmm... I think a tooltip could be especially useful for exit and break statements in nested conditionals where it's not always obvious at first glance. -- Mark Wieder ahsoftw...@gmail.com ___ 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
Re: Bug 20255 - Simple Loop Labeling
I do this, in my code, too. I also label my else's (with the opposite of the condition, of course) 4D's macros have a cool way of making this happen. for example, to make a labeled if type the text of the condition Select the text Insert the if macro The condition is replaced with if condition then end if #condition That's not entirely correct, because 4D uses the ` as the comment symbol, but you get the idea. If you use Levure, Trevor foolishly accepted my indent rules for sublimeText. I added an indent rule for blocks labeled like this # # The code in such a block will be indented another level, which means I get visual separation within the block, and I can fold it. On Thu, Aug 10, 2017 at 6:00 AM, Monte Goulding via use-livecode < use-livecode@lists.runrev.com> wrote: > > > On 10 Aug 2017, at 6:02 pm, panagiotis merakos via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > > I personally like this idea, and I find it pretty useful. And this does > not > > sound too difficult to implement. > > > > But I am not sure if everyone will like it, so if we do it, we should > > probably add a pref to turn it on/off. > > > > The good news is that Ali has been doing some work on scriptifying the > > Prefs stack, so in the future it will be easier to add Prefs for such > > features. > > I wonder whether a mouse over tooltip would work just as well. Is this > something you want to be able to see _all_ the time or just if you get > confused about where you are? > > Cheers > > Monte > ___ > 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 > -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, "This is good." ___ 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
Re: Bug 20255 - Simple Loop Labeling
> On 10 Aug 2017, at 6:02 pm, panagiotis merakos via use-livecode > wrote: > > I personally like this idea, and I find it pretty useful. And this does not > sound too difficult to implement. > > But I am not sure if everyone will like it, so if we do it, we should > probably add a pref to turn it on/off. > > The good news is that Ali has been doing some work on scriptifying the > Prefs stack, so in the future it will be easier to add Prefs for such > features. I wonder whether a mouse over tooltip would work just as well. Is this something you want to be able to see _all_ the time or just if you get confused about where you are? Cheers Monte ___ 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
Re: Bug 20255 - Simple Loop Labeling
Hi all, I personally like this idea, and I find it pretty useful. And this does not sound too difficult to implement. But I am not sure if everyone will like it, so if we do it, we should probably add a pref to turn it on/off. The good news is that Ali has been doing some work on scriptifying the Prefs stack, so in the future it will be easier to add Prefs for such features. Best, Panos On 10 Aug 2017 02:53, "Mark Wieder via use-livecode" < use-livecode@lists.runrev.com> wrote: > On 08/09/2017 01:39 PM, Dr. Hawkins via use-livecode wrote: > >> Eureka! >> >> I don't know why I didn't think of this earlier, but . . . >> >> A simple way to get *some* level of control structure labeling . . . >> >> >> So when finding the structure typed in the id of >> >> switch -- myLoop >> >> instead of simply adding an end switch, the comment could be copied >> >> end switch -- myLoop >> >> >> Better yet, perhaps, would be to insert "end " before the first word >> of the comment. >> >> >> > I do this regularly with repeat statements and if/endif statments as well, > in fact the glx2 script editor does this automatically for me. It helps > keep me more or less sane, especially when dealing with nested structures. > Instead of a comment like "myLoop" I use the parameters to the switch or > repeat or if statement, so I end up with > > switch word 1 of tLine > ... > end switch -- word 1 of tLine > > repeat for each item tItem in tList > ... > end repeat -- for each item tItem in tList > > if tVariable is not empty then > ... > end if -- tVariable is not empty > > -- > Mark Wieder > ahsoftw...@gmail.com > > ___ > 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
Re: Bug 20255 - Simple Loop Labeling
On 08/09/2017 01:39 PM, Dr. Hawkins via use-livecode wrote: Eureka! I don't know why I didn't think of this earlier, but . . . A simple way to get *some* level of control structure labeling . . . So when finding the structure typed in the id of switch -- myLoop instead of simply adding an end switch, the comment could be copied end switch -- myLoop Better yet, perhaps, would be to insert "end " before the first word of the comment. I do this regularly with repeat statements and if/endif statments as well, in fact the glx2 script editor does this automatically for me. It helps keep me more or less sane, especially when dealing with nested structures. Instead of a comment like "myLoop" I use the parameters to the switch or repeat or if statement, so I end up with switch word 1 of tLine ... end switch -- word 1 of tLine repeat for each item tItem in tList ... end repeat -- for each item tItem in tList if tVariable is not empty then ... end if -- tVariable is not empty -- Mark Wieder ahsoftw...@gmail.com ___ 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