Re: Bug 20255 - Simple Loop Labeling

[Bob Sneidar via use-livecode]

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

[Bob Sneidar via use-livecode]

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

[Bob Sneidar via use-livecode]

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

[Mark Wieder via use-livecode]

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

[Dr. Hawkins via use-livecode]

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

[Mark Waddingham via use-livecode]

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

[Mark Wieder via use-livecode]

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

[Ralph DiMola via use-livecode]

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

[Mark Waddingham via use-livecode]

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

[Lagi Pittas via use-livecode]

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 

Re: Bug 20255 - Simple Loop Labeling

[Mark Waddingham via use-livecode]

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

[Lagi Pittas via use-livecode]

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

[Mark Waddingham via use-livecode]

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

[Lagi Pittas via use-livecode]

+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

[Mike Kerner via use-livecode]

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

[Monte Goulding via use-livecode]

> 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

[Mark Wieder via use-livecode]

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

[Monte Goulding via use-livecode]

> 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

[Mark Wieder via use-livecode]

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

[Monte Goulding via use-livecode]

> 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

[Dr. Hawkins via use-livecode]

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

[J. Landman Gay via use-livecode]

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

[Richard Gaskin via use-livecode]

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

[J. Landman Gay via use-livecode]

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

[Mike Kerner via use-livecode]

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

[Bob Sneidar via use-livecode]

+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

[Mark Wieder via use-livecode]

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

[Mike Kerner via use-livecode]

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

[Monte Goulding via use-livecode]

> 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

[panagiotis merakos via use-livecode]

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

[Mark Wieder via use-livecode]

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

Bug 20255 - Simple Loop Labeling

[Dr. Hawkins via use-livecode]

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.


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