OpenEuphoria

1. New keyword added: continue

• Posted by Jeremy Cowgar <jeremy at ?owgar.com> May 11, 2008
• 877 views

Continue has been added to Euphoria SVN. Continue is Exit's sibling.

for i = 1 to length(lines) do
    if length(lines[i]) = 0 or lines[i][1] = '#' then 
        continue -- start loop at next iteration
    end if

    -- You know the line has data and is not a comment line
    -- process the line
end for

--
Jeremy Cowgar
http://jeremy.cowgar.com

3. Re: New keyword added: continue

• Posted by Derek Parnell <ddparnell at bi?pond?com> May 11, 2008
• 807 views

Jeremy Cowgar wrote:
> 
> Continue has been added to Euphoria SVN. Continue is Exit's sibling.


But I seriously hope it is going to be renamed to something a lot more natural
such as 'next'.


-- 
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell

5. Re: New keyword added: continue

• Posted by CChris <christian.cuvier at agric?lt?re.gouv.fr> May 11, 2008
• 808 views

Salix wrote:
> 
> > Jeremy Cowgar wrote:
> > > Continue has been added to Euphoria SVN. Continue is Exit's sibling.
> 
> Oh, at last! Thanks!
> 
> But I agree with Derek and I'd prefer a more natural such as 'next'.
> 
> Regards,
> 
> Salix

Me too, antd that's how it's named in Æ.

But naming discussions are so ... , well, that I won't care how it gets
eventually named, as long as it stays in the language.

CChris

7. Re: New keyword added: continue

• Posted by Arthur Crump <arthur.crump at ?tlw?rld.com> May 11, 2008
• 821 views

Just another vote for 'next' rather than 'continue' in a for statement.

I am old enough to remember when 'next' was the end of a for statement
instead of the much better 'end for' used now, but I think the proposal
is a better use of .next'

Arthur Crump, Cheshire, UK.

----------------------------
Derek Parnell wrote:
> 
> Jeremy Cowgar wrote:
> > 
> > Continue has been added to Euphoria SVN. Continue is Exit's sibling.
> 
> 
> But I seriously hope it is going to be renamed to something a lot more natural
> such as 'next'.
> 
> 
> -- 
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell

9. Re: New keyword added: continue

• Posted by Jeremy Cowgar <jeremy at cowgar.??m> May 11, 2008
• 815 views

Mike Sywensky wrote:
>  
> Although it may not make as much sense for someone learing euphoria as a first
> language, I imagine most people are not using it as a first language.  
> 
> My guess is most people are coming from other languages such as VB or C. 
> 'continue'
> is what is used by both languages.  That is my vote.

I just went to the computer language shootout and looked at the more popular
languages there. I suppose a more detailed study could be done via the TIBOE
language index, but here are my findings:

python = continue
c = continue
vb = continue
d = continue
basic = continue
pascal = continue
php = continue
perl = next
javascript = continue
tcl = continue

I agree after conversations here, looking in dictionary and comparing to other
devices, that next makes sense, but most people who program do not program in one
language, thus, similarity to a degree is good.

But the choice between continue, next, repeat, again or whatever else may come
up is not a huge deal to me personally. I am forced to use a few different
languages and have to adapt to minor nuances like this all the time, so... before
making any changes to the naming, I would like to hear more feedback from others
who have not spoken yet about the topic.

For me to change continue to next or whatever is about a 10-15 minute job for
me, not a big deal and can be done at any time, so I am going to no act quickly,
but let there be some more discussion.

--
Jeremy Cowgar
http://jeremy.cowgar.com

11. Re: New keyword added: continue

• Posted by c.k.lester <euphoric at ckl??ter.com> May 11, 2008
• 818 views

Jeremy Cowgar wrote:
> 
> I agree after conversations here, looking in dictionary and comparing to other
> devices, that next makes sense, but most people who program do not program in
> one language, thus, similarity to a degree is good.

I vote for 'next.' I think VBA uses next and I use VBA at work.

13. Re: New keyword added: continue

• Posted by c.k.lester <euphoric at ckleste??com> May 11, 2008
• 820 views

Jeremy Cowgar wrote:
> c.k.lester wrote:
> > I vote for 'next.' I think VBA uses next and I use VBA at work.
> VBA does not use next as a continue. It uses next as a end for...

Well, you can see I never use a continue construct. :D

I still like 'next' better because it's more appropriate and I only have to
type 4 letters instead of 8. That's a 50% increase in efficiency.

15. Re: New keyword added: continue

• Posted by Matt Lewis <matthewwalkerlewis at gmai?.?om> May 11, 2008
• 757 views

Mike Sywensky wrote:
> 
> Although it may not make as much sense for someone learing euphoria as a first
> language, I imagine most people are not using it as a first language.  
> 
> My guess is most people are coming from other languages such as VB or C. 
> 'continue'
> is what is used by both languages.  That is my vote.

I've used both 'continue' and 'next'.  Either one is fine by me.

Matt

17. Re: New keyword added: continue

• Posted by Jason Gade <jaygade at y?hoo.c?m> May 11, 2008
• 816 views

Matt Lewis wrote:
> 
> Mike Sywensky wrote:
> > 
> > Although it may not make as much sense for someone learing euphoria as a
> > first
> > language, I imagine most people are not using it as a first language.  
> > 
> > My guess is most people are coming from other languages such as VB or C. 
> > 'continue'
> > is what is used by both languages.  That is my vote.
> 
> I've used both 'continue' and 'next'.  Either one is fine by me.
> 
> Matt

I prefer continue, I think, for reasons that others have mentioned -- existing
use of "next" as an identifier.

--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.

"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare

j.

19. Re: New keyword added: continue

• Posted by Derek Parnell <ddparnell at bigpo?d.com> May 11, 2008
• 826 views
• Last edited May 12, 2008

Mike Sywensky wrote:

> Although it may not make as much sense for someone
> learing euphoria as a first language,

 ... or still make sense after years of usage.

>  I imagine most people are not using it as a first language.  

... and yet there are a lot of people who are actually using Eu as a first-ish
language.

> My guess is most people are coming from other languages such as VB or C.  

What is this 'C' thing you speak of and what has Victoria Bitter got to do with
programming?  


-- 
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell

21. Re: New keyword added: continue

• Posted by Derek Parnell <ddparnell at b?gp?nd.com> May 11, 2008
• 774 views
• Last edited May 12, 2008

Jeremy Cowgar wrote:
 I suppose a more detailed study could be done via the TIBOE
> language index, but here are my findings:
> 
> python = continue
> c = continue
> vb = continue
> d = continue
> basic = continue
> pascal = continue
> php = continue
> perl = next
> javascript = continue
> tcl = continue

But aren't we supposed to be learning from the mistakes of the past?

-- 
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell

23. Re: New keyword added: continue

• Posted by Kat <KAT12 at coosahs.n??> May 12, 2008
• 785 views

Derek Parnell wrote:
> 
> Jeremy Cowgar wrote:
>  I suppose a more detailed study could be done via the TIBOE
> > language index, but here are my findings:
> > 
> > python = continue
> > c = continue
> > vb = continue
> > d = continue
> > basic = continue
> > pascal = continue
> > php = continue
> > perl = next
> > javascript = continue
> > tcl = continue
> 
> But aren't we supposed to be learning from the mistakes of the past?

Yeas, all these extra words, meaning different things to different people, when
"goto" is so clear and direct and simple. <sigh>


Kat

25. Re: New keyword added: continue

• Posted by CChris <christian.cuvier at agricultur?.?ouv.fr> May 12, 2008
• 817 views

Add to the pros for next that it is shorter to type.
Symmetrically, a con for continue is its being longer.

CChris

27. Re: New keyword added: continue

• Posted by Kat <KAT12 at coo?a?s.net> May 12, 2008
• 783 views

Why? 
Here's how you use one keyword instead of six:

--repeat until
:repeat
x -= 1  
if x > 12 then goto repeat end if


-- case
atom fred, a, d
fred = 45
a = 1
d = 44

goto x
 puts(1,x&" is not covered") goto caseend
   :1 puts(1,"it's 1!") goto caseend
   :34 puts(1,"wow, 34!")
   :"Sam" puts(1,"you got Sam!" goto caseend
   :a+d puts(1,"Yep, fred is 45!") goto caseend
:caseend

-- continue, retry, restart, and next
  :restart
for loop = 1 to 12 do
  :retry
  -- code    
    if test = failed then goto retry end if
    if thistest = failed then goto restart end if
    if bored = true then goto next end if
    if done then goto demoend end if
  -- code
  :next
end for
:demoend

You know exactly where each "goto" lands, each :target can be in your own native
language, and OOEU prooves it can be done. It's ONE word. It's so SIMPLE.

Kat

29. Re: New keyword added: continue

• Posted by Jeremy Cowgar <jeremy at cowgar.c?m> May 12, 2008
• 773 views

Kat wrote:
> 
> Why? 
> Here's how you use one keyword instead of six:
> 
> }}}
<eucode>
> 
> --repeat until
> :repeat
> x -= 1  
> if x > 12 then goto repeat end if
> 
> 
> -- case
> atom fred, a, d
> fred = 45
> a = 1
> d = 44
> 
> goto x
>  puts(1,x&" is not covered") goto caseend
>    :1 puts(1,"it's 1!") goto caseend
>    :34 puts(1,"wow, 34!")
>    :"Sam" puts(1,"you got Sam!" goto caseend
>    :a+d puts(1,"Yep, fred is 45!") goto caseend
> :caseend
>
> -- continue, retry, restart, and next
>   :restart
> for loop = 1 to 12 do
>   :retry
>   -- code    
>     if test = failed then goto retry end if
>     if thistest = failed then goto restart end if
>     if bored = true then goto next end if
>     if done then goto demoend end if
>   -- code
>   :next
> end for
> :demoend
> 
> </eucode>
{{{


The above code is not entirely correct or as simple as it seems. Let's start
with the case statement. I think a case statement would a much better choice.
Why? What if you want two case statements, either nested or in the same function
in different sections that answer both to the integer 1 ?

goto x
  :1 puts "One!\n"
  :2 puts "Two!\n"
:caseend

goto y
  :1 puts "One!\n" -- invalid already used
  :2 puts "Two!\n" -- invalid already used
:caseend -- invalid already used

The for loop with next, retry, exit, restart, etc... First to program might be a
bit of a chore because on the keywords "end for" the stack is cleaned up, temp
variables cleared, etc... A direct goto out of the for loop w/o hitting an end
for would leave the internals dirty. It should be able to detect that it went out
of the loop and then clean up, but it's not as easy as pushing adding a label and
going to a label in the backend as you would think.

#2 with the for loop, it suffers the same fate as the case statement. Sure, on
the first for loop you can use :retry, :end, :next, :restart, but then on
subsequent for loops in the same context (in top level or inside a function), you
would have to get creative in your naming... :end2, :next2, :restart2, etc...
Then have 1 for loop that is nested in another, and then later in the function
you add a new for loop. Then, as time goes on, you add a for loop at the
beginning of the function. Now, your first for loop is named :end3, :restart3,
and your second is just :end, :restart, etc... and an inner is :restart3, etc...
It begins to get pretty confusing.

So, while I personally think a goto statement is a good thing, I do not think it
is a replacement for exit, continue and a case statement.

--
Jeremy Cowgar
http://jeremy.cowgar.com

31. Re: New keyword added: continue

• Posted by Kat <KAT12 at coosahs??et> May 12, 2008
• 808 views

Jeremy Cowgar wrote:
> 
> Kat wrote:
> > 
> > Why? 
> > Here's how you use one keyword instead of six:
> > 
> > }}}
<eucode>
> > 
> > --repeat until
> > :repeat
> > x -= 1  
> > if x > 12 then goto repeat end if
> > 
> > 
> > -- case
> > atom fred, a, d
> > fred = 45
> > a = 1
> > d = 44
> > 
> > goto x
> >  puts(1,x&" is not covered") goto caseend
> >    :1 puts(1,"it's 1!") goto caseend
> >    :34 puts(1,"wow, 34!")
> >    :"Sam" puts(1,"you got Sam!" goto caseend
> >    :a+d puts(1,"Yep, fred is 45!") goto caseend
> > :caseend
> >
> > -- continue, retry, restart, and next
> >   :restart
> > for loop = 1 to 12 do
> >   :retry
> >   -- code    
> >     if test = failed then goto retry end if
> >     if thistest = failed then goto restart end if
> >     if bored = true then goto next end if
> >     if done then goto demoend end if
> >   -- code
> >   :next
> > end for
> > :demoend
> > 
> > </eucode>
{{{

> 
> The above code is not entirely correct or as simple as it seems. Let's start
> with the case statement. I think a case statement would a much better choice.
> Why? What if you want two case statements, either nested or in the same
> function
> in different sections that answer both to the integer 1 ?
> 
> }}}
<eucode>
> goto x
>   :1 puts "One!\n"
>   :2 puts "Two!\n"
> :caseend
> 
> goto y
>   :1 puts "One!\n" -- invalid already used
>   :2 puts "Two!\n" -- invalid already used
> :caseend -- invalid already used
> </eucode>
{{{


I wasn't arguing against the case, i have been in favor of case before, and
would use it if it existed. I mentioned that in #Euphoria even. Before i left the
channel. If you do make a case for case in Eu, please look at how nicely Matt did
the case/goto targets in OOEU. I suspect even those could be made more versatile.

> The for loop with next, retry, exit, restart, etc... First to program might
> be a bit of a chore because on the keywords "end for" the stack is cleaned up,
> temp variables cleared, etc... A direct goto out of the for loop w/o hitting
> an end for would leave the internals dirty. It should be able to detect that
> it went out of the loop and then clean up, but it's not as easy as pushing
> adding
> a label and going to a label in the backend as you would think.

Depends on how it's done. In some languages, the loop is nearly a second
program, and leaving it's code space clears everything that's not in the
proc/funct it's nested in. Such "nearly a 2nd program" also justified nesting
functions and procedures inside other functions of procedures, making the
internal proc/func local to the proc/func it was nested in. I don't know how Eu
does it.
 
> #2 with the for loop, it suffers the same fate as the case statement. Sure,
> on the first for loop you can use :retry, :end, :next, :restart, but then on
> subsequent for loops in the same context (in top level or inside a function),
> you would have to get creative in your naming... :end2, :next2, :restart2,
> etc...
> Then have 1 for loop that is nested in another, and then later in the function
> you add a new for loop. Then, as time goes on, you add a for loop at the
> beginning
> of the function. Now, your first for loop is named :end3, :restart3, and your
> second is just :end, :restart, etc... and an inner is :restart3, etc... It
> begins
> to get pretty confusing.

OMGess, do you really program like that?
 
> So, while I personally think a goto statement is a good thing, I do not think
> it is a replacement for exit, continue and a case statement.

I nominate it again for exit, continue, restart, next, retry (not the error
handling retry), or any other keyword where the purpose is to get around
intervening code. In your example of nested loops, i have no clue where an exit
would goto, and in most cases i bet it would not goto where i wanted. There's
been numerous posts showing an exit not traveling far enough, leading to more
flag tests to see if it's necessary to exit some more. One goto would have been
enough, and quite clear, mentioning a descriptive target at both ends of the
jump, and easy to find with text search in an editor.

While i am at this example of nested loops, that's about the only reason i use
goto, the others being to simulate case i don't have, hop some debug code, or get
right to the end of a procedure (tis easy to exit a function, you can return from
anywhere inside it)(altho i have often put cleanup code at the bottoms of
proc/func and goto that code before leaving).

Case is a clear goto, but without a scope limit at the bottom (</case> ?), your
objection to using goto for case is almost correct. I think Matt considered a
goto switch that prohibited reverse :target lookups, which would have partly
solved your case objection. In any case, i believe it looked for the next :target
down the code that was in scope, and on not finding one, then looked down from
the beginning of the scope. I can still see gotchas, and am not against case to
solve those.

Kat

33. Re: New keyword added: continue

• Posted by CChris <christian.cuvier at agri?ulture.gouv.?r> May 12, 2008
• 807 views
• Last edited May 13, 2008

Kat wrote:
> 
> 
> Why? 
> Here's how you use one keyword instead of six:
> 
> }}}
<eucode>
> 
> --repeat until
> :repeat
> x -= 1  
> if x > 12 then goto repeat end if
> 
> 
> -- case
> atom fred, a, d
> fred = 45
> a = 1
> d = 44
> 
> goto x
>  puts(1,x&" is not covered") goto caseend
>    :1 puts(1,"it's 1!") goto caseend
>    :34 puts(1,"wow, 34!")
>    :"Sam" puts(1,"you got Sam!" goto caseend
>    :a+d puts(1,"Yep, fred is 45!") goto caseend
> :caseend
> 
> -- continue, retry, restart, and next
>   :restart
> for loop = 1 to 12 do
>   :retry
>   -- code    
>     if test = failed then goto retry end if
>     if thistest = failed then goto restart end if
>     if bored = true then goto next end if
>     if done then goto demoend end if
>   -- code
>   :next
> end for
> :demoend
> 
> </eucode>
{{{

> 
> You know exactly where each "goto" lands, each :target can be in your own
> native
> language, and OOEU prooves it can be done. It's ONE word. It's so SIMPLE.
> 
> Kat

You know where each goto lands, granted.
But you don't know where you land from, as any label can be targeted from
scarrered places. And that's why soem people are downright against it, and why I
don't like using it.

I had found out this: when you start writing code, and it is naive an simple,
then goto are as easy to read as anything, and perhaps easier.

Then, the code becomes more complex because there's a handful of special cases,
and you now have to guarantee that it hardly matters, when you reach a label,
what was the program state just before. It simply doesn't work. You can always
set up flags, but then tell me that you never make mistakes updating them...

I tried to implement goto in Æ. It works. But I added a twist: all goto
statements must have a label, and there is another builtin, come_from(), which
retrieves the last goto label you jumped from. Otherwise, I'd say: goto is nice,
it's one keyword instead of 6, is not hard to type, but it makes maintaining code
so much trickier.

Pascal compilers didn't recognise goto, unless a specific option was turned on.
Perhaps that would be the way to go: if you want goto, have it, but know that you
are doing things the hard way. I still think some equivalent of come_from() is
necessary to make goto usable in the Euphoria framework - you know, that world
where raw pointers are considered unsafe -.

CChris

35. Re: New keyword added: continue

• Posted by Kat <KAT12 at coosahs.n?t> May 12, 2008
• 766 views
• Last edited May 13, 2008

Jeremy Cowgar wrote:
> 
> CChris wrote:
> > 
> > Pascal compilers didn't recognise goto, unless a specific option was turned
> > on. Perhaps that would be the way to go: if you want goto, have it, but know
> > that you are doing things the hard way. I still think some equivalent of
> > come_from()
> > is necessary to make goto usable in the Euphoria framework - you know, that
> > world where raw pointers are considered unsafe -.
> > 
> 
> I do not think this is a viable option as it would introduce code
> incompatabilities.
> Say, John likes goto's and writes a library but Joe does not like goto's. He
> downloads John's library and cannot use it because he will not enable gotos.
> Then, John will start declaring "goto must be enabled", etc... I think that
> one Euphoria programmer should be able to run another Euphoria application in
> the same version w/o incompatibilities.
> 
> Along the lines of one of the requirements for the standard library... no
> external
> dependencies. This is so if Jane writes a program, she knows it will run on
> Jim's install of Euphoria.

Ok, don't turn off goto, and then Jane's code can run on Jim's computer.

Kat

37. Re: New keyword added: continue

• Posted by ken mortenson <kenneth_john at ?aho?.com> May 27, 2008
• 815 views

Derek Parnell wrote:
> 
> Jeremy Cowgar wrote:
>  I suppose a more detailed study could be done via the TIBOE
> > language index, but here are my findings:
> > 
> > python = continue
> > c = continue
> > vb = continue
> > d = continue
> > basic = continue
> > pascal = continue
> > php = continue
> > perl = next
> > javascript = continue
> > tcl = continue
> 
> But aren't we supposed to be learning from the mistakes of the past?
> 
> -- 
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell


Next def: Immediately following in time, ORDER, importance, etc.
Cont def: To go on after suspension or interruption.
Cont def: To go on with or persist in.

I think you can make a case for either word, but because next implies
an iteration I would prefer it.  The truth is, I don't have a dog in
this hunt, because it doesn't really provide new capability.

loop
  if true next
  code skipped here. 
end loop

or

loop
  if false
    code skipped here.
  end if
end loop

The results are the same.  I also prefer type 4 letters to 8.
NEXT is preferable to CONT for you wiseguys that say both can be 4. 

39. Re: New keyword added: continue

• Posted by Jason Gade <jaygade at yahoo?co?> May 27, 2008
• 798 views

I don't usually like to save typing at the expense of clarity.

C is pretty good at that, though...



--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.

"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare

j.

41. Re: New keyword added: continue

• Posted by c.k.lester <euphoric at ?klester.?om> May 27, 2008
• 798 views

Kat wrote:
> ken mortenson wrote:
> > skip def: To jump lightly over.
> > ...for those leaning whimsically (also 4 letters.)
> goto def: to continue or next or resume or retry or restart or exit or entry
> at another location

How do you get next/continue or restart with goto (using only 4 letters?)? I
don't see a way to iterate using just goto. You'd have to do all sorts of
other stuff, methinks, to emulate these easier-to-use terms.

43. Re: New keyword added: continue

• Posted by Kat <KAT12 at coos?hs.?et> May 27, 2008
• 799 views
• Last edited May 28, 2008

c.k.lester wrote:
> 
> Kat wrote:
> > ken mortenson wrote:
> > > skip def: To jump lightly over.
> > > ...for those leaning whimsically (also 4 letters.)
> > goto def: to continue or next or resume or retry or restart or exit or entry
> > at another location
> 
> How do you get next/continue or restart with goto (using only 4 letters?)? I
> don't see a way to iterate using just goto. You'd have to do all sorts of
> other stuff, methinks, to emulate these easier-to-use terms.


I have already given examples.

Early mirc had no loop constructs, and for years had only if-then construct. All
other loops, including case, were built with goto. I am NOT recommending this as
good coding style in any language that has the appropriate loop devices.....


set -u0 %loop 0 -- going to use "loop"
:startofloop
-- code
-- note i can modify the loop var
inc -u0 %loop
if ( %loop != %y ) { goto startofloop }
-- %loop is still valid here if i want to use it


Bare-bones basic stuff. But getting good loops (if-then, while-do,
repeat-until<cough>) in modern languages, and then adding 4 or more keywords to
jump around *inside* a loop smells like nuts to me.

:restart
for loop = 1 to 12 do
:retry
 -- code
 if blah then goto restart end if
 if blorg then goto retry end if
 if not x then goto exit end if
 if CK then goto next end if
 if worstcase then goto cleanup&return end if
 -- code
 :next
end for
:exit

Not only is it crystal clear (flat panel, no cuts, colors, or occlusions) that
it's going to change program flow, but the places it is going to are plainly and
unambiguously labeled in the language of your choice, and it's pretty darned well
self explainitory. I don't want to be programming along, then stop and wonder if
the language will allow me to do something, and if so, which keyword do i want,
and just where will it land? And then will it keep landing there if i later add
some code to debug something else? Or what if i remove some debug code? etc etc
etc.

Kat

45. Re: New keyword added: continue

• Posted by ken mortenson <kenneth_john at yahoo.c??> May 27, 2008
• 786 views
• Last edited May 28, 2008

Kat wrote:
> Bare-bones basic stuff. But getting good loops (if-then, while-do,
> repeat-until<cough>)
> in modern languages, and then adding 4 or more keywords to jump around
> *inside*
> a loop smells like nuts to me.

A programmer after my own heart (soon you will achieve oneness...)

I'm even weirder in my thinking (you guys already figured that one out didn't
ya?  But here's some confirmation...)

All code written anywhere by anyone (quantum computing may make this statement
untrue) have only three structures (sequence, branch, loop)

I'd like to get rid of ALL the various flavors of loops
(while, for, for each, etc.) and replace it with the pseudo code I've
always used.

Loop
  ...
End Loop

You do all your initialization before the loop.  The loop creates Index
which starts with a value of zero and increments once each iteration.

The scope of Index is limited to the last declaration so for nested loops...

Loop
  x = Index
  Loop
    y = Index
    array(x,y)=whatever.
    if (y>9) exit
  End Loop
  if (x>12) exit
End Loop

...but I'm a dreamer.  Am I not the only one?

Note that all loops are infinite and require an explicit exit.  Programmers
with bad habits will be spanked enough to learn good habits in very
short order.

47. Re: New keyword added: continue

• Posted by c.k.lester <euphoric at ckl?ster.?om> May 27, 2008
• 793 views
• Last edited May 28, 2008

ken mortenson wrote:
> 
> Loop
>   x = Index
>   Loop
>     y = Index
>     array(x,y)=whatever.
>     if (y>9) exit
>   End Loop
>   if (x>12) exit
> End Loop

I'm... strangely... attracted to it. 8|

49. Re: New keyword added: continue

• Posted by c.k.lester <euphoric at ckl??ter.com> May 27, 2008
• 803 views
• Last edited May 28, 2008

Matt Lewis wrote:
> c.k.lester wrote:
> > Ah, I see how next/continue would work there, and retry. But restart-
> > jumping OUT of a loop and then going back into it- looks like it might
> > cause interpreter pains (memory leaks, etc.). And jumping out of the loop?
> > Dunno. Maybe an interpreter modifier can speak to that.
> You're probably afraid of 'exit', too.  :P
> Seriously, exit is just a goto to the end of the loop.  It doesn't do any 
> clean up or anything.  There isn't any needed.

You'd know.

I'm curious that there's no clean up necessary. It looks like there'd be a
dangling variable. Eeeewwwwwww!!! :D

(I admit I've never used exit. I'm not a sloppy enough coder. HAHAHAHA. Just
kidding. I might've used it once. Well, I just checked bbcmf-system. Out of
about 8.6KLOC, exit appears 0 times. So, I probably never have used it.)

51. Re: New keyword added: continue

• Posted by ken mortenson <kenneth_john at y?hoo?com> May 27, 2008
• 775 views
• Last edited May 28, 2008

c.k.lester wrote:
> 
> ken mortenson wrote:
> > 
> > Loop
> >   x = Index
> >   Loop
> >     y = Index
> >     array(x,y)=whatever.
> >     if (y>9) exit
> >   End Loop
> >   if (x>12) exit
> > End Loop
> 
> I'm... strangely... attracted to it. 8|

Medic!  Medic!  Get the tranquilizers, we've got another one!

53. Re: New keyword added: continue

• Posted by ken mortenson <kenneth_john at yahoo??om> May 27, 2008
• 774 views
• Last edited May 28, 2008

Jeremy Cowgar wrote:

> I was thinking we have:
> 
> loop do
> 
> until ... 
> 
> Why not
> 
> loop do
> ...
> again or repeat
> 
> However, I'd use a while loop or until loop for examples such as if (x>12)
> exit. 

The only difference between a do while or do until is where the test is made.
In my construct there is no difference, you just put it where you want (or
at multiple points if that's your style or need.

do, again and repeat are all extraneous.  In my view all structures
would consistantly end with end (followed by the name of the structure:
if, loop, procedure, etc.)

Also you are assigning y = Index, x = Index, therefore, those are probably
> being incremented somewhere that you are not showing making the above loop
> probably
> more suited to a for loop?

Exactly, they are incremented under the covers for each iteration of the loop
starting at zero.  This doesn't mean the programmer is limited in any way.

A for loop simply has it's initialize as part of it's syntax.  Initialize
before the loop in all cases creates a simple habit.  It may even teach
those that initialize IN loops that, that is not a good idea.

For loops also have an implicit increment by which I'm just suggesting is
better being explicit.

The real advantage is only one loop structure wich reduces stress on the
humble programmer.  Need a loop?  Use Loop.

55. Re: New keyword added: continue

• Posted by c.k.lester <euphoric at ckles?er.com> May 27, 2008
• 782 views
• Last edited May 28, 2008

Matt Lewis wrote:
> c.k.lester wrote:
> > (I admit I've never used exit. I'm not a sloppy enough coder. HAHAHAHA. Just
> > kidding. I might've used it once. Well, I just checked bbcmf-system. Out of
> > about 8.6KLOC, exit appears 0 times. So, I probably never have used i
> >grep -c exit eusql.e
> 21
> Maybe it's not in bbcmf, but you depend upon it. :)

heheh... Yeah, I saw some in Tommy Carlier's kanarie, too, which is a
significant part of BBCMF. So, I guess I've gotta cut off EuSQL and
kanarie... LOL! RIGHT!!!11!!1!!111!

57. Re: New keyword added: continue

• Posted by Derek Parnell <ddparnell at bigpon?.?om> May 27, 2008
• 800 views
• Last edited May 28, 2008

Kat wrote:
> }}}
<eucode>
> :restart
> for loop = 1 to 12 do
> :retry
>  -- code
>  if blah then goto restart end if
>  if blorg then goto retry end if
>  if not x then goto exit end if
>  if CK then goto next end if
>  if worstcase then goto cleanup&return end if
>  -- code
>  :next
> end for
> :exit
> </eucode>
{{{


Hi Kat,
just a few of quick questions ...

** How, as a maintainer of the code above, can I be sure that process flow only
gets to the "restart:" label from either the statement immediately preceding it
or the 'goto' inside the loop? In other words, how can I be sure that there is
not another 'goto restart' elsewhere in the code?

** If I have to place another looping construct within the same scope as the one
above, what should I call the labels?

** Under what circumstanes might I have to rename the labels?

-- 
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell

59. Re: New keyword added: continue

• Posted by gshingles <gshingles at gmai?.c?m> May 27, 2008
• 796 views
• Last edited May 28, 2008

ken mortenson wrote:
> 
> I guaranty the soon nobody would miss, while, for, for each, repeat until,
> do while, do until, rinse, lather, soap...  oops!  Got ahead of myself on
> those last few.

Maybe I'm just lazy, but I really miss foreach in Euphoria, especially since it
has native sequences. I suspect sequence operations make it fairly redundant
though.

If all the work is being done by the interpreter then I would rather write
something that looks like English, so I like having while and for.

It's more natural to think (in my view) "count to 10 and for each number do
something with it" (for..end for) than to think "LOOP,ADD,DO,TEST,END"
(loop..loop end)

or "while I haven't found it get the next one and have a look". (while)

I'm actually really starting to admire Python. You say what you mean and don't
have to dress everything up again to carry on with your code. I often sit there
thinking "Is that it?" when I've iterated over an array in three lines of code
and don't have to type '}' or 'end for' or count brackets etc 

Anyway, whatever language Euphoria uses I'm sure we'll all get used to it. It's
all the same as far as the CPU is concerned :)

Gary

61. Re: New keyword added: continue

• Posted by Kat <KAT12 at coos?hs?net> May 27, 2008
• 772 views
• Last edited May 28, 2008

Derek Parnell wrote:
> 
> Kat wrote:
> > }}}
<eucode>
> > :restart
> > for loop = 1 to 12 do
> > :retry
> >  -- code
> >  if blah then goto restart end if
> >  if blorg then goto retry end if
> >  if not x then goto exit end if
> >  if CK then goto next end if
> >  if worstcase then goto cleanup&return end if
> >  -- code
> >  :next
> > end for
> > :exit
> > </eucode>
{{{

> 
> Hi Kat,
> just a few of quick questions ...
> 
> ** How, as a maintainer of the code above, can I be sure that process flow
> only
> gets to the "restart:" label from either the statement immediately preceding
> it or the 'goto' inside the loop? In other words, how can I be sure that there
> is not another 'goto restart' elsewhere in the code?

You can't. You read the code to see if there is another "goto" that label. The
same with "exit", "return", etc.. I have a fair amount of code that has "return"
sprinkled around, and no one has ever complained about more than one place
leaving the function. One way to restrict the "where from" is to localise all
"goto" to procedure/function blocks, and not allow it in top level code. Exactly
like in OOEU.

> ** If I have to place another looping construct within the same scope as the
> one above, what should I call the labels?

Umm, how about "loop2" ? Or you mean the targets for more "goto" of the same
umm, form? Pick a name. You have the freedom to restart the inner loop, the outer
loop, the nested while loop in there which you added later, etc.. I tend to give
my nested loop names some description, even if it's just "index1", so i could
have a "goto restart_index1", which sorta reads easily, and i know just where
it's going, and i can get there with the one "goto" keyword from any depth of
nested loops. The target being present alerts me, as i am reading down the code,
that i may be going back to that point from somewhere.
 
> ** Under what circumstanes might I have to rename the labels?

Never, i believe. If you add loops, or other code, you do not need to change
anything, assuming your intent to goto the :target is the same. If you wish to
add a target, choose another name. Like i said, i tend to use the loop name as
part of the target, and/or/as well as the purpose, if i need any clairification,
rather insuring unique target names. This way i can wrap or unwrap nested loops,
and not have a problem, as well as skip blocks during debug.

With goto scope restricted to proc/funct blocks, it makes some code even easier,
such as "goto cleanup&return", which i know has the local scope of variables, is
at the bottom of the block where code will fall thru to anyhow, and execute the
"cleanup&return". With Eu the way it is now, i have hunks of code copy/pasted
thruout which does the cleanup with local vars and returns, and those hunks are a
nightmare to keep identical. Just as an aside, one other cure for that would be
nested procedures, which could be called inside the nesting procedure, and the
nested one have the scope of the nesting one's vars, i did this in Turbo Pascal a
*lot*.

I believe Matt scored 100 with the way he did goto in OOEU, and i reiterate my
suggestion all of OOEU be merged into Eu v4.

Kat

63. Re: New keyword added: continue

• Posted by c.k.lester <euphoric at cklester?co?> May 27, 2008
• 786 views
• Last edited May 28, 2008

Kat wrote:
> c.k.lester wrote:
> > Derek Parnell wrote:
> > > just a few of quick questions ...
> > Thus, goto is destroyed in one fell swoop.
> I don't see why.

Maintainability of code is of utmost importance. Using goto is dangerous! :)

65. Re: New keyword added: continue

• Posted by Kat <KAT12 at c?osahs?net> May 27, 2008
• 758 views
• Last edited May 28, 2008

c.k.lester wrote:
> 
> Kat wrote:
> > c.k.lester wrote:
> > > Derek Parnell wrote:
> > > > just a few of quick questions ...
> > > Thus, goto is destroyed in one fell swoop.
> > I don't see why.
> 
> Maintainability of code is of utmost importance. Using goto is dangerous! :)

Why are these two blocks so different that you call the 2nd one "dangerous" ?

for loop = 1 to x do
  -- code
  if x = blah then goto next end if
  -- code
  :next
end for

for loop = 1 to x do
  -- code
  if x = blah then next end if
  -- code
end for

And ye who didn't know you were using code containing "exit", how were you
"maintaining" that code? And how would you know how many places called "exit" to
make the code flow change?

Kat

67. Re: New keyword added: continue

• Posted by Derek Parnell <ddparnell at big?ond.?om> May 27, 2008
• 775 views
• Last edited May 28, 2008

Kat wrote:

Thanks Kat. 

> Derek Parnell wrote:
>> ... how can I be sure that there is not another 'goto restart'
>> elsewhere in the code?
> 
> You can't. You read the code to see if there is another "goto" that label. 

How likely would this requirement increase the cost of maintenance?

> The same with "exit", "return", etc.. I have a fair amount
> of code that has "return" sprinkled around, and no one has
> ever complained about more than one place leaving
> the function.

I see this as a different issue. With 'goto' the question I raise deals with how
ones arrives at the label and has nothing to do with the 'goto' statement itself,
but with 'exit' and 'return', the process flow to arrive at that statement is
clear and local.

> One way to restrict the "where from" is to localise all "goto"
> to procedure/function blocks, and not allow it in top level code.
> Exactly like in OOEU.

Does the number of statements in a routine affect this position?

>> ** If I have to place another looping construct within the same
>> scope as the one above, what should I call the labels?
> 
> Umm, how about "loop2" ?

Does the requirement that a 'goto' needs a (unique within the scope) label,
reduce the amount of code that has to be read by maintainers? To me it seems that
using the combination of 'label xyz' and 'goto xyz' contains a lot more redundant
content than 'next' does.

If such a loop containing labels, needs to be later nested inside another loop,
what is the suggested naming convention, if any?

e.g. We start with ...
  restart1:
  loop
     -- some code --
     goto restart1
     -- some more code ---
     restart2:
     loop
       -- some code ---
       goto restart2:
       -- some code --
       goto restart1
       -- some code
     end loop
  end loop

But later this needs to be nested, such as ...

 restart3:
 loop
    -- some code ---
    restart1:
    loop
       -- some code --
       goto restart1
       -- some more code ---
       restart2:
       loop
         -- some code ---
         goto restart2:
         -- some code --
         goto restart1
         -- some code --
       end loop
    end loop
    -- some code --
    goto restart3
    -- some code --
 end loop

Would it be better to keep the existing label names as above, or is it better to
rename them to keep the implied nesting level obvious?

>> ** Under what circumstanes might I have to rename the labels?
 
> Never, i believe. 

See above.

> Just as an aside, one other cure for that
> would be nested procedures, which could be
> called inside the nesting procedure, and the
> nested one have the scope of the nesting one's
> vars 

Yes, nested routines would be very very nice. I suspect that we will have this
ability soon, but not for v4.0

-- 
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell

69. Re: New keyword added: continue

• Posted by c.k.lester <euphoric at c??ester.com> May 28, 2008
• 794 views

Kat wrote:
> c.k.lester wrote:
> > Maintainability of code is of utmost importance. Using goto is dangerous! :)
> Why are these two blocks so different that you call the 2nd one "dangerous"
> ?
> for loop = 1 to x do
>   -- code
>   if x = blah then goto next end if
>   -- code
>   :next
> end for
> 
> for loop = 1 to x do
>   -- code
>   if x = blah then next end if
>   -- code
> end for

Because adding loops therein could be problematic.

> And ye who didn't know you were using code containing "exit",
> how were you "maintaining" that code?

I'm not maintaining that code (they are in libraries I am including), so
I don't care. :)

71. Re: New keyword added: continue

• Posted by Matt Lewis <matthewwalkerlewis at gm?il.co?> May 28, 2008
• 783 views

ken mortenson wrote:
> 
> I wouldn't be adverse to an optional from/by
> 
> Loop from 7 by -1.2
>   if (Index<-14.2) exit
> End Loop

That's good to know.  I think.

Matt

73. Re: New keyword added: continue

• Posted by ken mortenson <kenneth_john at yahoo??om> May 28, 2008
• 762 views

Kat wrote:

> And without rounding, i am over 50.

Now I understand your loyalty to spaghetti.

somewhere you've got a program running...

:49
GOTO 49

ps: half italian and a quarter swede, so I like spaghetti too, just not
in my code.  I once had a boss in NYC that used to say he was 80% finished
and hand me a plate of spaghetti it fix.  He's also the guy that wrote
self modifying code in BAL.  That was quite the experience.

75. Re: New keyword added: continue

• Posted by Kat <KAT12 at ?oos?hs.net> May 28, 2008
• 768 views

Derek Parnell wrote:
> 
> Kat wrote:
> 
> Thanks Kat. 
> 
> > Derek Parnell wrote:
> >> ... how can I be sure that there is not another 'goto restart'
> >> elsewhere in the code?
> > 
> > You can't. You read the code to see if there is another "goto" that label. 
> 
> How likely would this requirement increase the cost of maintenance?

In Textpad, drag the cursor over the label, and keypress for search. You could,
i suppose, add a "came_from" var you interrogate in some way.

> > The same with "exit", "return", etc.. I have a fair amount
> > of code that has "return" sprinkled around, and no one has
> > ever complained about more than one place leaving
> > the function.
> 
> I see this as a different issue. With 'goto' the question I raise deals with
> how ones arrives at the label and has nothing to do with the 'goto' statement
> itself, but with 'exit' and 'return', the process flow to arrive at that
> statement
> is clear and local.

It is as clear as goto, i think. If i have a function, and i can return from it
in several points, how do you know which return got you back out of the function?
 
> > One way to restrict the "where from" is to localise all "goto"
> > to procedure/function blocks, and not allow it in top level code.
> > Exactly like in OOEU.
> 
> Does the number of statements in a routine affect this position?

What?  I don't see the connection between statement count and use of any
keyword.

> >> ** If I have to place another looping construct within the same
> >> scope as the one above, what should I call the labels?
> > 
> > Umm, how about "loop2" ?
> 
> Does the requirement that a 'goto' needs a (unique within the scope) label,
> reduce the amount of code that has to be read by maintainers? To me it seems
> that using the combination of 'label xyz' and 'goto xyz' contains a lot more
> redundant content than 'next' does.

But you *know* where goto will goto, and across languages, you haveto remember
where each language differs, as well as how each human language interprets each
of those other keywords, such as "next", "continue", etc.

> If such a loop containing labels, needs to be later nested inside another
> loop,
> what is the suggested naming convention, if any?
> 
> e.g. We start with ...
>   restart1:
>   loop
>      -- some code --
>      goto restart1
>      -- some more code ---
>      restart2:
>      loop
>        -- some code ---
>        goto restart2:
>        -- some code --
>        goto restart1
>        -- some code
>      end loop
>   end loop
> 
> But later this needs to be nested, such as ...
> 
>  restart3:
>  loop
>     -- some code ---
>     restart1:
>     loop
>        -- some code --
>        goto restart1
>        -- some more code ---
>        restart2:
>        loop
>          -- some code ---
>          goto restart2:
>          -- some code --
>          goto restart1
>          -- some code --
>        end loop
>     end loop
>     -- some code --
>     goto restart3
>     -- some code --
>  end loop
> 
> Would it be better to keep the existing label names as above, or is it better
> to rename them to keep the implied nesting level obvious?

Better to find a better way to code that. I would keep the labels more
descriptive of what they do, and then not change them if you are wrapping or
inserting new code that describes another function.

> >> ** Under what circumstanes might I have to rename the labels?
>  
> > Never, i believe. 
> 
> See above.

Did.
 
> > Just as an aside, one other cure for that
> > would be nested procedures, which could be
> > called inside the nesting procedure, and the
> > nested one have the scope of the nesting one's
> > vars 
> 
> Yes, nested routines would be very very nice. I suspect that we will have this
> ability soon, but not for v4.0

Cool.

Kat

77. Re: New keyword added: continue

• Posted by ken mortenson <kenneth_john at yah?o?com> May 28, 2008
• 774 views

Kat wrote:

> for loop1 = 1 to 12 do
>   -- code
>   goto next1
>   -- code
>   for loop2 = 1 to 12 do
>     -- code
>     goto next2
>     -- code
>     for loop3 = 1 to 12 do
>       -- code
>       goto next3
>       -- code
>       for loop4 = 1 to 12 do
>         -- code
>         goto next4
>         -- code
>         for loop5 = 1 to 12 do
>           -- code
>           goto next5
>           -- code
>           for loop6 = 1 to 12 do
>             -- code
>             goto next6
>             -- code
>             :next6 
>           end for
>           :next5 
>         end for
>         :next4 
>       end for
>       :next3 
>     end for
>     :next2 
>   end for
>   :next1 
> end for

Is equivalent to...

> for loop1 = 1 to 12 do
>   -- code
>   goto next1
>   :next1 
> end for

Is this what you meant the code to do?

79. Re: New keyword added: continue

• Posted by c.k.lester <euphoric at ?klester?com> May 28, 2008
• 767 views

Kat wrote:
> 
> This is getting irritating to the point of dropping Eu entirely.

Bye, kat!

81. Re: New keyword added: continue

• Posted by ken mortenson <kenneth_john at yahoo.??m> May 28, 2008
• 784 views

Kat wrote:
> 
> ken mortenson wrote:

> > Now I understand your loyalty to spaghetti.
> 
> I am not in favor of spagetti code. This is getting irritating to the point
> of dropping Eu entirely.

Please forgive me Kat.  I thought I was being cute.  Obviously I'm
not quite as charming as I must imagine myself to be.

83. Re: New keyword added: continue

• Posted by Matt Lewis <matthewwalkerlewis at gmail?c?m> May 28, 2008
• 757 views

ken mortenson wrote:
> 
> Matt Lewis wrote:
> > 
> > ken mortenson wrote:
> > > 
> > > I wouldn't be adverse to an optional from/by
> > > 
> > > Loop from 7 by -1.2
> > >   if (Index<-14.2) exit
> > > End Loop
> > 
> > That's good to know.  I think.
> 
> So, what are you trying to tell me?  I can take it.  I'm a big boy.

Exactly.

Matt

85. Re: New keyword added: continue

• Posted by CChris <christian.cuvier at agriculture.?ouv.?r> May 28, 2008
• 761 views

c.k.lester wrote:
> 
> Matt Lewis wrote:
> > c.k.lester wrote:
> > > Ah, I see how next/continue would work there, and retry. But restart-
> > > jumping OUT of a loop and then going back into it- looks like it might
> > > cause interpreter pains (memory leaks, etc.). And jumping out of the loop?
> > > Dunno. Maybe an interpreter modifier can speak to that.
> > You're probably afraid of 'exit', too.  :P
> > Seriously, exit is just a goto to the end of the loop.  It doesn't do any 
> > clean up or anything.  There isn't any needed.
> 
> You'd know.
> 
> I'm curious that there's no clean up necessary. It looks like there'd be a
> dangling variable. Eeeewwwwwww!!! :D
> 
> (I admit I've never used exit. I'm not a sloppy enough coder. HAHAHAHA. Just
> kidding. I might've used it once. Well, I just checked bbcmf-system. Out of
> about 8.6KLOC, exit appears 0 times. So, I probably never have used it.)

No cleanup is needed.
When you say

for i=1 to n do
-- ...
end for

a variable named i, but with a unique index, is created for the duration of the
routine it is in (top level code is in a procedure which returns in a special
way).
Since only the index of a variable is being used in actual execution, the only
concern is that this particular  i be used out of context. This is ensured by
hiding it when the parser sees "end for".
The parser doesn't goto or loop through code, it linearly ploughs through it.
The i variable is a variable like any other, but with a special scope, so that
the only references to it will appear inside the for loop it indexes.

What may be an issue is jumping into a for loop from outside. The first code in
a for loop initialises i, so strange things may happen if that code is skipped.
And the logic needed for goto to understand that it must reinitialise the for
loop index(es) involved before jumping in is probably costly. This can work in an
interpreter with multple passes over the source, but not with the current parser,
which is one pass only for speed.

CChris

87. Re: New keyword added: continue

• Posted by CChris <christian.cuvier at agriculture.g??v.fr> May 28, 2008
• 778 views

Kat wrote:
> 
> Derek Parnell wrote:
> > 
> > Kat wrote:
> > 
> > Thanks Kat. 
> > 
> > > Derek Parnell wrote:
> > >> ... how can I be sure that there is not another 'goto restart'
> > >> elsewhere in the code?
> > > 
> > > You can't. You read the code to see if there is another "goto" that label.
> > >
> > 
> > How likely would this requirement increase the cost of maintenance?
> 
> In Textpad, drag the cursor over the label, and keypress for search. You
> could,
> i suppose, add a "came_from" var you interrogate in some way.
> 
> > > The same with "exit", "return", etc.. I have a fair amount
> > > of code that has "return" sprinkled around, and no one has
> > > ever complained about more than one place leaving
> > > the function.
> > 
> > I see this as a different issue. With 'goto' the question I raise deals with
> > how ones arrives at the label and has nothing to do with the 'goto'
> > statement
> > itself, but with 'exit' and 'return', the process flow to arrive at that
> > statement
> > is clear and local.
> 
> It is as clear as goto, i think. If i have a function, and i can return from
> it in several points, how do you know which return got you back out of the
> function?
>  
> > > One way to restrict the "where from" is to localise all "goto"
> > > to procedure/function blocks, and not allow it in top level code.
> > > Exactly like in OOEU.
> > 
> > Does the number of statements in a routine affect this position?
> 
> What?  I don't see the connection between statement count and use of any
> keyword.
> 
> > >> ** If I have to place another looping construct within the same
> > >> scope as the one above, what should I call the labels?
> > > 
> > > Umm, how about "loop2" ?
> > 
> > Does the requirement that a 'goto' needs a (unique within the scope) label,
> > reduce the amount of code that has to be read by maintainers? To me it seems
> > that using the combination of 'label xyz' and 'goto xyz' contains a lot more
> > redundant content than 'next' does.
> 
> But you *know* where goto will goto, and across languages, you haveto remember
> where each language differs, as well as how each human language interprets
> each
> of those other keywords, such as "next", "continue", etc.
> 
> > If such a loop containing labels, needs to be later nested inside another
> > loop,
> > what is the suggested naming convention, if any?
> > 
> > e.g. We start with ...
> >   restart1:
> >   loop
> >      -- some code --
> >      goto restart1
> >      -- some more code ---
> >      restart2:
> >      loop
> >        -- some code ---
> >        goto restart2:
> >        -- some code --
> >        goto restart1
> >        -- some code
> >      end loop
> >   end loop
> > 
> > But later this needs to be nested, such as ...
> > 
> >  restart3:
> >  loop
> >     -- some code ---
> >     restart1:
> >     loop
> >        -- some code --
> >        goto restart1
> >        -- some more code ---
> >        restart2:
> >        loop
> >          -- some code ---
> >          goto restart2:
> >          -- some code --
> >          goto restart1
> >          -- some code --
> >        end loop
> >     end loop
> >     -- some code --
> >     goto restart3
> >     -- some code --
> >  end loop
> > 
> > Would it be better to keep the existing label names as above, or is it
> > better
> > to rename them to keep the implied nesting level obvious?
> 
> Better to find a better way to code that. I would keep the labels more
> descriptive
> of what they do, and then not change them if you are wrapping or inserting new
> code that describes another function.
> 
> > >> ** Under what circumstanes might I have to rename the labels?
> >  
> > > Never, i believe. 
> > 
> > See above.
> 
> Did.
>  
> > > Just as an aside, one other cure for that
> > > would be nested procedures, which could be
> > > called inside the nesting procedure, and the
> > > nested one have the scope of the nesting one's
> > > vars 
> > 
> > Yes, nested routines would be very very nice. I suspect that we will have
> > this
> > ability soon, but not for v4.0
> 
> Cool.
> 
> Kat

It can be in 4.0 in a matter of days. The code works in interpreted mode in Æ.
There may be issues with translated code, as I recently discovered, but the bulk
of it could take like 3 days to port in, and a couple more for any residual bugs
(I have always stated tat that code was experimental and not thoroughly tested).

CChris

89. Re: New keyword added: continue

• Posted by Derek Parnell <ddparnell at bi?pond.co?> May 28, 2008
• 793 views

CChris wrote:

> Which I'd support, with probably reservations about namespace handling.

What is it that you would support? Your response is not clear about what section
of that very long post you're referring to.

-- 
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell

91. Re: New keyword added: continue

• Posted by Derek Parnell <ddparnell at ?igpond.c?m> May 28, 2008
• 782 views

CChris wrote:

> If you supervise coders, you may ask them not to use it,
> since you are the boss. Any remaining concern?

Are you talking to me, Chris? If so, what are you talking about? I really
haven't got a clue what trying to say to me.

-- 
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell

93. Re: New keyword added: continue

• Posted by Jeremy Cowgar <jeremy at ?owgar.com> May 28, 2008
• 775 views

CChris wrote:
> 
> 
> The section preceding my comment, ie getting 80+% of OOEu into official Eu.
> 

What specific functionality of OOeu?

--
Jeremy Cowgar
http://jeremy.cowgar.com

95. Re: New keyword added: continue

• Posted by CChris <christian.cuvier at ag?iculture.gouv.f?> May 28, 2008
• 780 views

Derek Parnell wrote:
> 
> CChris wrote:
> 
> > If you supervise coders, you may ask them not to use it,
> > since you are the boss. Any remaining concern?
> 
> Are you talking to me, Chris? If so, what are you talking about? I really
> haven't
> got a clue what trying to say to me.
> 
> -- 
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell

You said: I'm concerned about having someday to maintain code that someone wrote
badly using goto.

Let's assume the oncern is not overplayed. Now how would that situation be
happening?
1/ Because the Eu interpreter or the standard lib uses goto. We mat reasonably
agree not to let this happen. After all, they are in the greater common
denominator of Eu, which dosn't include goto.
2/ Because someone you supervise is giving you such code. Then you are free to
set your coding rules, including not using goto.
3/ Because a supervisor hands you that job, and he accepted goto in code. But
then you were aware that it ould happen, right?
4/ Otherwise, you have hardly any obligation to maintain any code you didn't
write, so you can decide to not maintain if there's a goto.

Is that clearer? 
So, you can always avoid maintaining the dreaded code, and your concerns will
remain theory, even with goto in the language, not actual.

CChris

Notes: 
1/ I'm not actively pushing for goto, as it may be of scarce usefulness 
with the new flow control statements in, and has serious pitfalls. However, I
see that most of the reasons put forward against it are quite wrong.

2/ Can someone point me to actual publicly released spaghetti code? It's
everyone's talk, but I have never seen any. Preferrably something less than 5
year old.

97. Re: New keyword added: continue

• Posted by CChris <christian.cuvier at agriculture.gouv??r> May 28, 2008
• 773 views

Jeremy Cowgar wrote:
> 
> CChris wrote:
> > 
> > 
> > The section preceding my comment, ie getting 80+% of OOEu into official Eu.
> > 
> 
> What specific functionality of OOeu?
> 
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>

- prototype based classes
- dynamic variables (var_id(), read_variable(), ...)
- dynamic code execution (eval() and friends)
- supportfor optional : return_type in funvtion headers
- and, why not?, goto

CChris

99. Re: New keyword added: continue

• Posted by Matt Lewis <matthewwalkerlewis at gmail.co?> May 28, 2008
• 799 views

Jason Gade wrote:
> 
> CChris wrote:
> > 
> > - supportfor optional : return_type in funvtion headers
> 
> What is "optional : return_type in function headers"? That sounds like a move
> away from genericity to me.

You could overload class methods as long as they had different signatures.  
ooeu mangled names similar to C++.  So you could have two different methods
with the same name and same number of parameters.  The return type helped
the parser figure out which method to use based upon the return parameters
from functions.  It wasn't enforced in ooeu.

euclass complex( sequence c )
    atom real, imaginary
    
    function add( atom a ) : complex
        ...
    end function

    function add( complex c )
        ... 
    end function

    function complex( atom r ) : complex
        return {r, 0}
    end function

    function complex( atom r, atom i ) : complex
        return {r, i}
    end function

    function complex( complex c ) : complex
        return c
    end function
end euclass

complex x, y
x = complex( 0 )
y = complex( 5, 2 )

x = x.add( 3 )
x = x.add( y )
x = x.add( y.add( 2 ) )

101. Re: New keyword added: continue

• Posted by Matt Lewis <matthewwalkerlewis at gm?il.?om> May 28, 2008
• 766 views

Jason Gade wrote:
> 
> Matt Lewis wrote:
> > 
> > Jason Gade wrote:
> > > 
> > > What is "optional : return_type in function headers"? That sounds like a
> > > move
> > > away from genericity to me.
> > 
> > You could overload class methods as long as they had different signatures. 
> > 
> > ooeu mangled names similar to C++.  So you could have two different methods
> > with the same name and same number of parameters.  The return type helped
> > the parser figure out which method to use based upon the return parameters
> > from functions.  It wasn't enforced in ooeu.
>
> 
> Yeah, I had to recheck the docs after CChris mentioned it.
> 
> How does that affect non-method routines?

It doesn't, except when they're used as parameters for method calls.  
Basically, the return type was stored in a slot in the symbol table for
each function (defaulted to object, IIRC).  It was therefore an additional
couple of tokens to parse, and a little bit of additional information in the
symbol table that the OO symbol resolution code used.

Matt

103. Re: New keyword added: continue

• Posted by ken mortenson <kenneth_john at y?hoo.co?> May 28, 2008
• 800 views

Jeremy Cowgar wrote:
> 
> 
> > You said: I'm concerned about having someday to maintain code that someone
> > wrote
> > badly using goto.
> >
> 
> <snip>
>  
> > Let's assume the concern is not overplayed. Now how would that situation be 
> > happening?
> >
> > 1/ Because the Eu interpreter or the standard lib uses goto. We mat 
> > reasonably agree not to let this happen. After all, they are in the greater 
> > common denominator of Eu, which dosn't include goto.
> 
> I've heard a few people say this and it does not make sense to me. I am not
> arguing for or against goto but here is my simple observation on the above
> statement.
> 
> If goto is not good for the standard libraries than it's not good for the
> language.
> If it is good for the language than it's good for the standard library. I see
> no exceptions to this rule. Why would we add language functionality and then
> ban it from use? If we have the idea it should be banned, then it shouldn't
> be added! If we think it should be added then we cannot/should not ban it's
> use!

That's just too logical Jeremy.  What are you, some kind of fanatic? 

105. Re: New keyword added: continue

• Posted by Matt Lewis <matthewwalkerlewis at gmail.c?m> May 28, 2008
• 782 views

Jeremy Cowgar wrote:
> 
> If goto is not good for the standard libraries than it's not good for the
> language. If it is good for the language than it's good for the standard
> library. I see no exceptions to this rule. Why would we add language
> functionality and then ban it from use? If we have the idea it should be
> banned, then it shouldn't be added! If we think it should be added then we
> cannot/should not ban it's use!

That's a good general principle, but not necessarily true for every case.  One
place where goto can be a lifesaver is in porting code from other languages
that either have goto, or have other flow control structures that we don't.

Goto emulation in these cases can lead to really messy code that's technically
structured code, but the mess of nested ifs and flags can make a giant knot
that could be cut with a well placed goto here and there.  They can also be
used in certain cases to great effect in optimizing (take a look at the back
end of the interpreter :).

I accept that some view this as insufficient reason for adding goto.  I 
happen to disagree with them.

Matt

107. Re: New keyword added: continue

• Posted by Jeremy Cowgar <jeremy at cow?ar.co?> May 28, 2008
• 768 views

Matt Lewis wrote:
>  
> I accept that some view this as insufficient reason for adding goto.  I 
> happen to disagree with them.
> 

I think goto should be added, however, if goto exists and it makes sense to use
it in a given situation, then it should be allowed in the standard library.
Everyone is afraid of spaghetti code. We can create spaghetti code with or
without goto. What stops us from doing so? Hopefully those contributing to
Euphoria know how to program w/o spaghetti. Hopefully those peer reviewing
commits will recognize spaghetti when it's committed. To say that goto could
*possibly* create spaghetti *if* used improperly by a *novice* programmer
therefore it should not be allowed in the standard library sounds a bit odd to
me.

--
Jeremy Cowgar
http://jeremy.cowgar.com

109. Re: New keyword added: continue

• Posted by Matt Lewis <matthewwalkerlewis at gmail??om> May 28, 2008
• 814 views

ken mortenson wrote:
> 
> Matt Lewis wrote:
> > 
> > Goto emulation in these cases can lead to really messy code that's
> > technically
> > structured code, but the mess of nested ifs and flags can make a giant knot
> > that could be cut with a well placed goto here and there.
> 
> Matt, here's something to think about for a moment.  If GOTO is so essential,
> how is it that MILLIONS of programmer, writing BILLIONS of lines of code
> over DECADES have been able to forgo using it?  This is a serious thing to
> ponder.

Yes, lot's of code has been written without using $language_feature.  It does
not follow that $language_feature is superfluous.
 
> I admit the adjustment to writing structured code is not an easy one, but the
> rewards (this is just one of many voices of experience) are more than you
> know.

This statement makes even less sense than the one before.  Are you sure that
you meant to respond to me?

Matt