OpenEuphoria

1. Conceptual problem solved by GOTO

• Posted by Fernando Bauer <fmbauer at ?o?mail.com> Jun 06, 2008
• 791 views

Suppose we have GOTO and this kind of code (which I think is common):

procedure proc1()
if cond1 then
   .. some code here ..
   if cond2 then
      .. some code here ..
      if cond3 then
         .. some code here ..
         goto OUT
      end if
      .. some code here ..
   end if
   .. some code here ..
end if
OUT:
.. some code here ..
end procedure

In Eu 3.1, a possible implementation would be:

procedure proc1()
for i=1 to 1 do
if cond1 then
   .. some code here ..
   if cond2 then
      .. some code here ..
      if cond3 then
         .. some code here ..
         exit
      end if
      .. some code here ..
   end if
   .. some code here ..
end if
end for
.. some code here ..
end procedure

Now, without GOTO, we are forced to (mis)use a loop construct (for-loop,
while-loop) where there is NO loop.
Conceptually, IMHO this makes no sense.
To avoid the conceptual problem we could use flags, but IMHO this is even worst.

Regards,
   Fernando

3. Re: Conceptual problem solved by GOTO

• Posted by Chris Bensler <eu at creativepo?tal?ca> Jun 06, 2008
• 736 views

ken mortenson wrote:
> 
> I keep seeing people make the same false claims about GOTO over and over.
> 
> The issue regarding GOTO vs. structured code IS NOT SPEED.  Yes, calling a
> routine to refactor code makes the refactored code slower... but you NEVER
> have to call a sub routine.  The tradeoff without using functions is SIZE
> not SPEED.  
> 
> I've identified some lines of .. some code here .. with (A) and (B)
> 
> Fernando Bauer wrote:
> > procedure proc1()
> > if cond1 then
> >    .. some code here ..
> >    if cond2 then
> >       .. some code here ..
> >       if cond3 then
> >          .. some code here ..
> >          goto OUT
> >       end if
> >       .. some code here .. (A)
> >    end if
> >    .. some code here .. (B)
> > end if
> > OUT:
> > .. some code here ..
> > end procedure
> 
> You will note in the following that line (B) is now inline in two places
> (more SIZE) but only executes once (same SPEED)  It should be exactly the
> same speed for the if to branch to the else rather than the end if.
> 
> procedure proc1()
> if cond1 then
>    .. some code here ..
>    if cond2 then
>       .. some code here ..
>       if cond3 then
>          .. some code here ..
>       else
>          .. some code here .. (A)
>          .. some code here .. (B)
>       end if
>    else
>       .. some code here .. (B)
>    end if
> end if
> .. some code here ..
> end procedure
> 
> > Now, without GOTO, we are forced to (mis)use a loop construct (for-loop,
> > while-loop)
> > where there is NO loop.
> > Conceptually, IMHO this makes no sense.
> > To avoid the conceptual problem we could use flags, but IMHO this is even
> > worst.
> 
> You are not forced to misuse a loop.  No flags either.
> 
> If your basing your desire on GOTOs because of speed you are using a false
> premise and should rethink it.
> 
> Do I prefer this refactoring?  No.  That's why I use subroutines.  But if
> I need speed I just have to make the tradeoff with code size.

That is true in alot of cases but not always. More code can sometimes cause
additional cache misses (I just learned what caches misses actually are the other
day, thx Kat :) which actually make the optimization less efficient than the
original.

This can be seen in certain circumstances simply by rearranging a few lines of
more-or-less unrelated statements. The outcome is identical, but the execution
speed changes for what seems an inexplicable reason. I have often encountered
this type of anomoly when doing benchmarks. changing the order of functions often
produces radically different results, for example.

Chris Bensler
Code is Alchemy

5. Re: Conceptual problem solved by GOTO

• Posted by Andy Serpa <ac at ?nehorseshy?com> Jun 06, 2008
• 779 views

Although I vote NO on general goto, I do vote yes on "exit(x)" whereby x in an
integer allowing you to break out of x many nested loops, which avoids the use of
flags, etc.  A "continue" or "skip" would also be nice for loops, allowing you to
jump ahead to the next iteration immediately.

These could be seen as specific cases of goto, but I still vote NO on general
goto.

7. Re: Conceptual problem solved by GOTO

• Posted by Jim Brown <jbrown105 at linux?u?dhist.net> Jun 06, 2008
• 747 views

Andy Serpa wrote:
> 
> Although I vote NO on general goto, I do vote yes on "exit(x)" whereby x in
> an integer allowing you to break out of x many nested loops, which avoids the
> use of flags, etc.  A "continue" or "skip" would also be nice for loops,
> allowing
> you to jump ahead to the next iteration immediately.

Exit(n) is quite horrible, if you are deeply nested then you have to go back and
count lines in order to figure out where you will end up.

In any case, your response does not address the original problem, which had no
loops.

> 
> These could be seen as specific cases of goto, but I still vote NO on general
> goto.

9. Re: Conceptual problem solved by GOTO

• Posted by Chris Bensler <eu at c??ativeportal.ca> Jun 06, 2008
• 743 views

ken mortenson wrote:
> 
> Chris Bensler wrote:
> 
> > That is true in alot of cases but not always. More code can sometimes cause
> > additional cache misses (I just learned what caches misses actually are the
> > other day, thx Kat :) which actually make the optimization less efficient
> > than
> > the original.
> > 
> > This can be seen in certain circumstances simply by rearranging a few lines
> > of more-or-less unrelated statements. The outcome is identical, but the
> > execution
> > speed changes for what seems an inexplicable reason. I have often
> > encountered
> > this type of anomoly when doing benchmarks. changing the order of functions
> > often produces radically different results, for example.
> 
> Absolutely.  I just wanted to address the mistaken assertion that GOTO is
> faster than structure code (which under the covers often is the exact same
> code.)
> 
> A poor implementation can make a difference as well.
> 
> "Science is the belief in the ignorance of experts." - Richard Feynman

I think most of us know that hardcoding values is generally poor programming
practice. What happens when you reorganize your code and no longer have 2 nested
loops but 3 or 4 instead? Then you have to go back and make sure that any exit
statements you used are counting the proper number of blocks.
Not very maintainable. This is just asking for bugs.

Chris Bensler
Code is Alchemy

11. Re: Conceptual problem solved by GOTO

• Posted by Jeremy Cowgar <jeremy at cowga??com> Jun 06, 2008
• 744 views

Andy Serpa wrote:
> 
> Although I vote NO on general goto, I do vote yes on "exit(x)" whereby x in
> an integer allowing you to break out of x many nested loops, which avoids the
> use of flags, etc.  A "continue" or "skip" would also be nice for loops,
> allowing
> you to jump ahead to the next iteration immediately.
> 
> These could be seen as specific cases of goto, but I still vote NO on general
> goto.

We have a much better method already implemented called labeled loops. It was
discussed here quite a bit. General:

for a = 1 to length(lines) label "line_it" do
    line = lines[a]
    if match("/*", line) then
        while 1 do  --- we are going to eat all comment lines.
            -- read line
            -- test end of comment?
            if end_of_file then
                 exit "line_it"
            end if
        end while
    end if
end for

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

13. Re: Conceptual problem solved by GOTO

• Posted by Derek Parnell <ddparnell at bigp??d.com> Jun 06, 2008
• 762 views

Andy Serpa wrote:
> 
>I do vote yes on "exit(x)" whereby x in an integer allowing you to break
> out of x many nested loops, which avoids the use of flags, etc. 

Although v4.0 will not have "exit(x)" it does have "exit <label>" where <label>
is the name given to a loop. For example:

    while conda label "A" do
        --- stuff ---
        while condb label "B" do
            --- stuff
            if condc then
                exit "A" -- Exits the loop called 'A'
            end if
            -- stuff --
        end while
        -- stuff --
    end while
 

        

>A "continue" or "skip" would also be nice for loops, allowing
> you to jump ahead to the next iteration immediately.

Version 4.0 has a 'continue' statement now. It causes control to immediately
continue with the next iteration. It also can have an optional label name.


There is also a 'retry' statement that causes control to immediately repeat the
same iteration. This will be more useful when exception handling makes to
Euphoria one day.


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

15. Re: Conceptual problem solved by GOTO

• Posted by Jeremy Cowgar <jeremy at cowg?r.co?> Jun 06, 2008
• 751 views

Jason Gade wrote:
> 
> 
> Because the output of the translator is geared for speed; it is not meant to
> be read by or maintained by humans.
> 
> Most code doesn't need to be so highly optimized for the machine. As posted
> at one of your links "that's the compiler's job".
>  
> > Now, I want to take my own domain language used for hospital billings and
> > initial
> > hospital claim auditing and translate that to Euphoria, but can I? Not
> > easily.
> > It's far easier to just translate to C and use gotos. Now, why not just
> > do/keep
> > that? Because it would be far, far easier to use Euphoria as the final
> > language
> > instead of dealing with users changing the domain language, triggering a
> > compilation,
> > swapping in the .so, etc...
> > 

You did not address the rest of my message which was the real reason. As
Euphoria does translating to C, I *need* to do translating to Euphoria. *I* will
never look at that translated code. domain languages is a very common pattern
that saves huge amounts of time in many peoples applications.

Please tell me why I cannot make the same use of goto that C does? Do not say
that C does it for speed, it does not. goto is used for the ease of the
translator.

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

17. Re: Conceptual problem solved by GOTO

• Posted by Jason Gade <jaygade at ya?o?.com> Jun 06, 2008
• 762 views

Jeremy Cowgar wrote:
> 
> Jason Gade wrote:
> > 
> > 
> > Because the output of the translator is geared for speed; it is not meant to
> > be read by or maintained by humans.
> > 
> > Most code doesn't need to be so highly optimized for the machine. As posted
> > at one of your links "that's the compiler's job".
> >  
> > > Now, I want to take my own domain language used for hospital billings and
> > > initial
> > > hospital claim auditing and translate that to Euphoria, but can I? Not
> > > easily.
> > > It's far easier to just translate to C and use gotos. Now, why not just
> > > do/keep
> > > that? Because it would be far, far easier to use Euphoria as the final
> > > language
> > > instead of dealing with users changing the domain language, triggering a
> > > compilation,
> > > swapping in the .so, etc...
> > > 
> 
> You did not address the rest of my message which was the real reason. As
> Euphoria
> does translating to C, I *need* to do translating to Euphoria. *I* will never
> look at that translated code. domain languages is a very common pattern that
> saves huge amounts of time in many peoples applications.
> 
> Please tell me why I cannot make the same use of goto that C does? Do not say
> that C does it for speed, it does not. goto is used for the ease of the
> translator.
> 
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>

I never said you couldn't use goto. You can see that I've been relatively
neutral in this discussion and my official vote is "abstain".

However, when I see an argument with which I disagree I still feel compelled to
answer it.

As for you DSL example? I have no idea as I've never written anything in a DSL
and have zero experience in them. Are gotos common in DSLs? If so, why?

--
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: Conceptual problem solved by GOTO

• Posted by Matt Lewis <matthewwalkerlewis at ?mail?com> Jun 06, 2008
• 758 views

Jason Gade wrote:
> 
> Jeremy Cowgar wrote:
> > 
> > You did not address the rest of my message which was the real reason. As
> > Euphoria
> > does translating to C, I *need* to do translating to Euphoria. *I* will
> > never
> > look at that translated code. domain languages is a very common pattern that
> > saves huge amounts of time in many peoples applications.
> > 
> I never said you couldn't use goto. You can see that I've been relatively
> neutral
> in this discussion and my official vote is "abstain".
> 
> However, when I see an argument with which I disagree I still feel compelled
> to answer it.
> 
> As for you DSL example? I have no idea as I've never written anything in a DSL
> and have zero experience in them. Are gotos common in DSLs? If so, why?

I think that what he's saying is that he wants to write a DSL to euphoria
translator, not that his DSL has gotos (though it might).  Just like with
the euphoria translator, you might have incompatible datatypes, for example,
which make it impossible to write a general for loop, for example, without
using goto.  It's often easier to write code that does explicitly what
higher level constructs implement (i.e., the initialization, condition
checking and iteration of a for loop).

Having goto gives lower level control to the programmer, which is basically
why it's so easy to make spaghetti code with it.

Matt

21. Re: Conceptual problem solved by GOTO

• Posted by Kat <KAT12 at ?oosa?s.net> Jun 06, 2008
• 735 views
• Last edited Jun 07, 2008

ken mortenson wrote:
> 
> Derek Parnell wrote:
> > 
> > Andy Serpa wrote:
> > > 
> > >I do vote yes on "exit(x)" whereby x in an integer allowing you to break
> > > out of x many nested loops, which avoids the use of flags, etc. 
> > 
> > Although v4.0 will not have "exit(x)" it does have "exit <label>" where
> > <label>
> > is the name given to a loop.
> 
> How I hate to mention this.  I really, really do hate to mention this.  But
> I
> am compelled to for the sake of truth.  Here we are voting on GOTO and it's
> already in.  It's not the name GOTO that makes it a goto.  You can call it 
> banana if you want, it's having labels as targets.
> 
> So we aren't voting on GOTO; we're just calling it EXIT.
> 
> This explains my abstain vote to me.  I actually wondered why I didn't
> vote no.  I guess it's just one of those things that you either get or
> you don't.  Please don't take that as a shot at those that use GOTO, I
> did for decades myself and understand why some might want to use it.
> 
> I guess I've just seen it abused way too often to ever use it myself.

It's astonishing you fear you will abuse it and not be able to undo it when you
notice you used a goto.
 
> "Science is the belief in the ignorance of experts." - Richard Feynman

And this is a scientific vote, right?........

Kat

23. Re: Conceptual problem solved by GOTO

• Posted by ken mortenson <kenneth_john at yahoo??om> Jun 06, 2008
• 767 views
• Last edited Jun 07, 2008

Kat wrote:
> 
> It's astonishing you fear you will abuse it and not be able to undo it when
> you notice you used a goto.

No Kat, that is not it.  They do not slip into my code.  I do not even have
to think to not use them.  Loop, Branch and Sequence are all I will ever need.

It is not fear that motivates me.  Better to think of me as having a mind
warped by the church of L.B.S. (Loop, Branch and Sequence)   ...and warped it
is!

"I see unstructured code people..."
"...I see them everywhere..."
"...and they don't even know they are!" - sixth code sense.

"Labels are for bigots!"... "Isn't bigot a label?"... "So what's your point?"

25. Re: Conceptual problem solved by GOTO

• Posted by ken mortenson <kenneth_john at ya?oo.c?m> Jun 06, 2008
• 751 views
• Last edited Jun 07, 2008

Matt Lewis wrote:
> Well, we have exit right now.  Should we take it out?

No.

> It's very limited in its current implementation.

Which is what structure code is, constrained for a reason.  I admit it is
not easy to accept that reason because much of it is based on intangibles.

> The new label capability solves a very real
> problem, the only solution as of right now was to use flags and if statements
> to get out of nested loops.

This only appears correct.  However, no matter how much code someone
refactors as a demonstration it seems an unshakable belief.

> Your fear of labels seems almost pathological.

I fear them not.  No phobia.  No pathology.  There is a principle involved.

> I can understand being afraid
> of spaghetti code.

Don't even fear that.  I use the Gordian Knot solution.

> I can understand being against inclusion of goto.

Being that it's an individual realization, the understanding probably
differs from person to person even among those that agree.

>  I
> really don't understand your apparent opposition to a *structured* goto
> like exit.

Exit is essential.  Look at my previous discussion of Loop...End Loop.  In
my view it is much to be preferred to a multitude of different structures.

It's difficult to impress fundamental principles on others when a
lifetime of experience molded my thinking.  People want to target labels
instead of being disciplined in using only structured code.  It is their
privilege.  In some circumstances it is unthinkable to not have the
equivalent of goto.  I can't imagine a machine language without it
(Although the forth processor they came up with in the early 80's might
be an example.)

Once you change EXIT from 'skip to the end' to 'skip to where ever' you
open pandora's box.  I don't fear it.  I believe there is a better way
and being a good neighbor wish to share it with others.  So I try to
make my case.  Perhaps I can or perhaps not.  Should I not try?

I'm not sure what more I can say.  Do I make any sense at all?

Again, I'm not telling others what to do.  I am trying to persuade.
I believe the result is better with structured code.  Others are
free to disagree.  I am not unmoved by the arguments for including
labels.  I don't think they are evil.  I know how they can be used.

Did I mention how much I like Euphoria and wouldn't waste my time
if I didn't?  If I fear anything, I fear losing the elegance that
was Euphoria.

Beauty in Euphoria is more than skin deep.  I don't want it to go
ugly to the bone!  But I'm just one guy, beholdin' with one eye.

Perhaps that's too harsh.  I can live with whatever.  If I ever find
my code needs a label I will shout it from the rooftops. YMMV.


"Science is the belief in the ignorance of experts." - Richard Feynman

27. Re: Conceptual problem solved by GOTO

• Posted by Matt Lewis <matthewwalkerlewis at gmai?.c?m> Jun 06, 2008
• 754 views
• Last edited Jun 07, 2008

ken mortenson wrote:
> 
> Matt Lewis wrote:
>
> >  I
> > really don't understand your apparent opposition to a *structured* goto
> > like exit.
> 
> Exit is essential.  Look at my previous discussion of Loop...End Loop.  In
> my view it is much to be preferred to a multitude of different structures.
> 
> It's difficult to impress fundamental principles on others when a
> lifetime of experience molded my thinking.  People want to target labels
> instead of being disciplined in using only structured code.  It is their
> privilege.  In some circumstances it is unthinkable to not have the
> equivalent of goto.  I can't imagine a machine language without it
> (Although the forth processor they came up with in the early 80's might
> be an example.)
> 
> Once you change EXIT from 'skip to the end' to 'skip to where ever' you
> open pandora's box.  I don't fear it.  I believe there is a better way
> and being a good neighbor wish to share it with others.  So I try to
> make my case.  Perhaps I can or perhaps not.  Should I not try?
> 
> I'm not sure what more I can say.  Do I make any sense at all?

This does make sense to me.  I think we haven't been clear in explaining
what exit "label" does.  Here is an explanation:

while x < blah lable "x" do
    for i = 1 to 5 do
        if foo(x,i) then
            exit "x"
        end if
        -- do stuff
    end for
end while

exit "label" still goes to the end.  The question is, the end of which
loop?  The pre-4.0 exit only went to the end of the innermost loop.  The
post-4.0 exit allows the coder to specify which loop to exit.

Matt

29. Re: Conceptual problem solved by GOTO

• Posted by Andy Serpa <ac at oneho?ses?y.com> Jun 07, 2008
• 769 views

Derek Parnell wrote:
> 
> Andy Serpa wrote:
> > 
> >I do vote yes on "exit(x)" whereby x in an integer allowing you to break
> > out of x many nested loops, which avoids the use of flags, etc. 
> 
> Although v4.0 will not have "exit(x)" it does have "exit <label>" where
> <label>
> is the name given to a loop. For example:
> 
>     while conda label "A" do
>         --- stuff ---
>         while condb label "B" do
>             --- stuff
>             if condc then
>                 exit "A" -- Exits the loop called 'A'
>             end if
>             -- stuff --
>         end while
>         -- stuff --
>     end while
>  
> 
> >A "continue" or "skip" would also be nice for loops, allowing
> > you to jump ahead to the next iteration immediately.
> 
> Version 4.0 has a 'continue' statement now. It causes control to immediately
> continue with the next iteration. It also can have an optional label name. 
> 
> 
> There is also a 'retry' statement that causes control to immediately repeat
> the same iteration. This will be more useful when exception handling makes to
> Euphoria one day.
> 
I apologize I've missed all this stuff.  This explosion of conversation has
actually caused me to tune out because I'm no C coder and don't know what you
guys are talking about most of the time.

But those sound good -- I'll be looking forward to those changes.  [Now if only
I could get someone to take a look at memory usage problem I posted about a while
back on Windows since v3.0 and tell me why it hogs memory it is done using which
it does not in v2.5.  This causes problems for me.]

31. Re: Conceptual problem solved by GOTO

• Posted by ken mortenson <kenneth_john at yahoo?com> Jun 07, 2008
• 778 views

Fernando Bauer wrote:

> > procedure proc1()
> > if cond1 then
> >    .. some code here ..
> >    if cond2 then
> >       .. some code here ..
> >       if cond3 then
> >          .. some code here ..
> >       else
> >          .. some code here .. (A)
> >          .. some code here .. (B)
> >       end if
> >    else
> >       .. some code here .. (B)
> >    end if
> > end if
> > .. some code here ..
> > end procedure
> > 
> Thanks Ken for your implementation!  It solves the conceptual problem, however
> it seems that it creates another problem: for each nested-if it can be
> necessary
> to duplicate a block of code. And you have to maintain these blocks equal. So,
> it seems to me that this implementation does not follow the "Don't Repeat
> Yourself"
> principle.

Your welcome Fernando, and you are correct.  Thou shall not duplicate code
which is why I'd definitely put all the line (B) code into a subroutine.

It doesn't really matter how deep your nesting goes.  Just put it all into
a single routine.  Then, instead of exit to a label you simply return from
the routine.  If for some reason you have multiple many nested loops you
factor them into more routines.  No trouble.  BTW, did we just describe the
mother of all spaghetti?  Realistically, there is never a problem and
choosing good routine names makes it all pretty much self documenting.

Loop1
TOP:
  Loop2
    Loop...
      Loop9999
        go TOP
      End   
    End
  End
End

Becomes...

procedure routine1()
  Loop2
    Loop...
      Loop9999
        return
      End   
    End
  End
end proc

Loop1
  routine1
End