OpenEuphoria

1. voting on GOTO

• Posted by Jim Brown <jbrown105 at linuxbudd?ist.?et> Jun 04, 2008
• 861 views

Ok, so here is the official voting thread for the proposal on goto and label.   
My proposal was basically a goto that was restricted to using only labels in    
the current scope, but otherwise unrestricted.

Please vote yes or no, or abstain. Comments appreciated.

The full details of the proposal as currently slated, are:

goto and labels are only valid in the current scope. You can use the keyword
goto to
jump around in the same file at top level scope (but not across files,          
only within the same file) and you can use goto to jump around inside           
routines. But you can't jump across scope. Goto can't see labels that           
are outside of the current local scope, and there is no support for a           
'global' scope. The current local scope will either be the top-level
scope of the file code is currently executing from, or the private scope        
of the routine that goto is executing inside of.                              
Labels are defined with the label keyword, and are strings.  You can define and
use labels in the top-level scope of a file, but this is discouraged.
                                                                                
Scoping isn't affected by loops. This includes for loops. Any other type        
of loop, jumping in and out works as you expect it would.                       
You can just backwards and forwards. Labels do not have to come before goto
statements or vice versa.
                                                                                
For for loops, jumping out doesn't appear to cause any problems. Jumping        
into a for loop leaves the loop variable uninitialized, which can cause         
problems if you allow execution to reach the end of the for loop. (If           
you dont read the loop var and you jump back out of the for loop, then          
it works fine. If you only jump around theinside of a for loop but allow        
the for loop to start iteration normally, then it also works fine.              
Likewise if you jump to a label that is right before the start of a for         
loop.)                                                                          

It is possible to check if a variable is uninitialized. The recommended way to
deal with for loops is, if you must jump into a for loop, check if the variable
is uninitialized and jump to a label that is right before the the beginning of
the for loop statement to continue iteration.
Jumping into for loops is discouraged, however.

3. Re: voting on GOTO

• Posted by Jim Brown <jbrown105 at linuxbuddhist??et> Jun 04, 2008
• 794 views

Bernie Ryan wrote:
> I vote No; would rather see forward reference instead of goto.
> 
> Bernie
> 

I just wanted to point out that the two aren't mutually exclusive. goto does not
help at all in simulating forward references, so if we need it we'd need the real
version.

5. Re: voting on GOTO

• Posted by Kat <KAT12 at ?oosah?.net> Jun 04, 2008
• 803 views
• Last edited Jun 05, 2008

Larry Miller wrote:
> 
> I vote NO on goto.
> The potential for abuse outweighs the rare benefits.

And if he engages in **A N Y** forms of "abuse", cut off his hands!

Kat

7. Re: voting on GOTO

• Posted by Kat <KAT12 at coos?hs.?et> Jun 04, 2008
• 804 views
• Last edited Jun 05, 2008

Jim Brown wrote:
> 
> Ok, so here is the official voting thread for the proposal on goto and label.
>   
> My proposal was basically a goto that was restricted to using only labels in
>    
> the current scope, but otherwise unrestricted.
> 
> Please vote yes or no, or abstain. Comments appreciated.
> 
> The full details of the proposal as currently slated, are:
> 
> goto and labels are only valid in the current scope. You can use the keyword
> goto to        
> jump around in the same file at top level scope (but not across files,     
>     
> only within the same file) and you can use goto to jump around inside      
>     
> routines. But you can't jump across scope. Goto can't see labels that      
>     
> are outside of the current local scope, and there is no support for a      
>     
> 'global' scope. The current local scope will either be the top-level       
>      
> scope of the file code is currently executing from, or the private scope   
>     
> of the routine that goto is executing inside of.                           
>   
> Labels are defined with the label keyword, and are strings.  You can define
> and use labels in the top-level scope of a file, but this is discouraged.
>                                                                            
>     
> Scoping isn't affected by loops. This includes for loops. Any other type   
>     
> of loop, jumping in and out works as you expect it would.                  
>     
> You can just backwards and forwards. Labels do not have to come before goto
> statements or vice versa.
>                                                                            
>     
> For for loops, jumping out doesn't appear to cause any problems. Jumping   
>     
> into a for loop leaves the loop variable uninitialized, which can cause    
>     
> problems if you allow execution to reach the end of the for loop. (If      
>     
> you dont read the loop var and you jump back out of the for loop, then     
>     
> it works fine. If you only jump around theinside of a for loop but allow   
>     
> the for loop to start iteration normally, then it also works fine.         
>     
> Likewise if you jump to a label that is right before the start of a for    
>     
> loop.)                                                                     
>     
> 
> It is possible to check if a variable is uninitialized. The recommended way
> to deal with for loops is, if you must jump into a for loop, check if the
> variable
> is uninitialized and jump to a label that is right before the the beginning
> of the for loop statement to continue iteration.
> Jumping into for loops is discouraged, however.

I think i'd have just said "no jumping into uninitialised loops". I don't know
why you'd do that anyhow offpaw, unless you are using goto and a while loop to
simulate a repeat-until loop (which Eu does not have). Otherwise you are prolly
just trying to save a couple bytes of memory and reuse existing code, which isn't
so necessary nowadays. You don't need to goto into a structure simulating the
case/switch statement that Eu doesn't have, but which you can make with goto.

I vote YES on having goto.

Kat

9. Re: voting on GOTO

• Posted by c.k.lester <euphoric at c?leste?.com> Jun 04, 2008
• 798 views
• Last edited Jun 05, 2008

Chris Bensler wrote:
> 
> What could you do with a goto that could not be done otherwise? Optimization
> is not a good enough reason, since I doubt there would be very much
> performance
> gain if any. It may even hinder the language performance in general.

In my opinion, ANY performance gain is worthwhile, as I plan to use BBCMF
far and wide on web hosting, and the faster it is, the more users I can
accommodate.

Also, I have been assured that adding GOTO to the interpreter in no way
negatively affects its speed/performance.

I voted 'yes' on the dev list (and most devs voted yes) for two reasons:

1. I don't care if other people want to use it.
2. It doesn't negatively impact performance of the interpreter.

> Consider if goto even belongs in Eu's repertoire, regardless if it's useful
> or not, as long as we can still achieve the same thing through different
> means.
> Does it actually lend itself to Eu's characteristics? How will it affect the
> language internally?

Good questions, because where do we draw the line between usability and
performance? Right now, on the performance end of the spectrum, assembly
is the language of choice. For usability... I'd have to put Euphoria there
just because I know it and am ignorant of other competing languages. We
have to ask, at times, do we want to sacrifice usability (by which I mean
ease-of-development, ease-of-maintenance, etc.) for performance?

Because Euphoria performs so well as is, my votes will tend to be toward
usability (w/o sacrificing performance), and not toward performance (while
sacrificing usability).

> Rather than a vote, I'd suggest compiling and summarizing all the previous
> discussions
> on goto and put in an official feature request on sourceforge.

Even as a feature request, it has to be discussed and ultimately voted on. I
think you're right that this needs more discussion.

11. Re: voting on GOTO

• Posted by Larry Miller <larrymiller at sa?ktel.ne?> Jun 04, 2008
• 810 views
• Last edited Jun 05, 2008

As long term users of this forum will be well aware, Robert Craig was opposed to
the introduction of goto into Euphoria. If this should ever happen I can imagine
what his initial reaction might be:

"WHAT HAVE THEY DONE TO MY BABY?"

Larry Miller

13. Re: voting on GOTO

• Posted by Jim Brown <jbrown105 at li?uxbuddhist.n?t> Jun 04, 2008
• 800 views
• Last edited Jun 05, 2008

This proposal has already been vetted by the dev list, and passed there, 7 to 1.

A lot of thought and discussion went into goto. What survived is the proposal
presented here.

15. Re: voting on GOTO

• Posted by ChrisBurch3 <crylex at g?ail.?om> Jun 04, 2008
• 796 views
• Last edited Jun 05, 2008

Larry Miller wrote:
> 
> As long term users of this forum will be well aware, Robert Craig was opposed
> to the introduction of goto into Euphoria. If this should ever happen I can
> imagine what his initial reaction might be:
> 
> "WHAT HAVE THEY DONE TO MY BABY?"
> 
> Larry Miller

I've got married and got my own life now DAAAAD - duhhh

Chris

17. Re: voting on GOTO

• Posted by Kat <KAT12 at ?oosah?.net> Jun 04, 2008
• 821 views
• Last edited Jun 05, 2008

c.k.lester wrote:
> 
> Chris Bensler wrote:
> > 
> > What could you do with a goto that could not be done otherwise? Optimization
> > is not a good enough reason, since I doubt there would be very much
> > performance
> > gain if any. It may even hinder the language performance in general.
> 
> In my opinion, ANY performance gain is worthwhile, as I plan to use BBCMF
> far and wide on web hosting, and the faster it is, the more users I can
> accommodate.
> 
> Also, I have been assured that adding GOTO to the interpreter in no way
> negatively affects its speed/performance.
> 
> I voted 'yes' on the dev list (and most devs voted yes) for two reasons:
> 
> 1. I don't care if other people want to use it.
> 2. It doesn't negatively impact performance of the interpreter.
> 
> > Consider if goto even belongs in Eu's repertoire, regardless if it's useful
> > or not, as long as we can still achieve the same thing through different
> > means.
> > Does it actually lend itself to Eu's characteristics? How will it affect the
> > language internally?
> 
> Good questions, because where do we draw the line between usability and
> performance? Right now, on the performance end of the spectrum, assembly
> is the language of choice. For usability... I'd have to put Euphoria there
> just because I know it and am ignorant of other competing languages. We
> have to ask, at times, do we want to sacrifice usability (by which I mean
> ease-of-development, ease-of-maintenance, etc.) for performance?
> 
> Because Euphoria performs so well as is, my votes will tend to be toward
> usability (w/o sacrificing performance), and not toward performance (while
> sacrificing usability).
> 
> > Rather than a vote, I'd suggest compiling and summarizing all the previous
> > discussions
> > on goto and put in an official feature request on sourceforge.
> 
> Even as a feature request, it has to be discussed and ultimately voted on. I
> think you're right that this needs more discussion.

So we had the discussion, this is how it went:

[15:46] <euphoric> i don't know why i never got into C much. ever since Euphoria
came along, i haven't needed to.
[15:46] <euphoric> i mean, think about it. program with Euphoria then translate.
[15:47] <euphoric> BAM!
[15:47] <katsmeow-afk> yeasm BAM, C code with gotos!
[15:47] <euphoric> Nuh-uh!
[15:48] <euphoric> Translated code does NOT use GOTOs.
[15:48] <euphoric> Does it?
[15:48] <euphoric> :)
[15:48] <katsmeow-afk> if you say so
[15:48] <iamlost> it uses them all over the place
[15:48] <iamlost> every single loop type is implemtend, not with C loops, but
with gotos
[15:48] <katsmeow-afk> lol
[15:48] <[Tiggr]> hehehehehe ;o)
[15:48] <iamlost> and the backend uses goto like crazy
[15:48] <katsmeow-afk> that has GOT to be posted on euphorum
[15:49] <katsmeow-afk> mind if i quote?
[15:49] <katsmeow-afk> or do you wanna do it?
[15:49] <iamlost> katsmeow-afk: please, go ahead :)

Kat

19. Re: voting on GOTO

• Posted by Phil Russell <pg_russell at line?ne.?et> Jun 04, 2008
• 821 views
• Last edited Jun 05, 2008

ChrisBurch3 wrote:
> 
> I vote yes - if poeple want to use it, and it doesn't affect speed, then its
> abs fine by me. I may or may never use it, that's my choice.
> 

Seconded.

Phil

21. Re: voting on GOTO

• Posted by c.k.lester <euphoric at ckl?ster?com> Jun 04, 2008
• 835 views
• Last edited Jun 05, 2008

Jason Gade wrote:
> Kat wrote:
> > [15:48] <iamlost> every single loop type is implemtend, not with C loops,
> > but with gotos
> > [15:48] <iamlost> and the backend uses goto like crazy
> 
> Because C is a lower level language.

That's what I tried to argue. They wouldn't hear me. :)

23. Re: voting on GOTO

• Posted by Matt Lewis <matthewwalkerlewis at gm?il.co?> Jun 04, 2008
• 815 views
• Last edited Jun 05, 2008

Chris Bensler wrote:
> 
> Perhaps a warning that can be toggled to indicate if goto has been used
> would be handy. 

grep goto *.e*

Matt

25. Re: voting on GOTO

• Posted by Kat <KAT12 at coos?hs.?et> Jun 04, 2008
• 807 views
• Last edited Jun 05, 2008

Jason Gade wrote:
> 
> Kat wrote:
> > 
> > c.k.lester wrote:
> > > 
> > > Chris Bensler wrote:
> > > > 
> > > > What could you do with a goto that could not be done otherwise?
> > > > Optimization
> > > > is not a good enough reason, since I doubt there would be very much
> > > > performance
> > > > gain if any. It may even hinder the language performance in general.
> > > 
> > > In my opinion, ANY performance gain is worthwhile, as I plan to use BBCMF
> > > far and wide on web hosting, and the faster it is, the more users I can
> > > accommodate.
> > > 
> > > Also, I have been assured that adding GOTO to the interpreter in no way
> > > negatively affects its speed/performance.
> > > 
> > > I voted 'yes' on the dev list (and most devs voted yes) for two reasons:
> > > 
> > > 1. I don't care if other people want to use it.
> > > 2. It doesn't negatively impact performance of the interpreter.
> > > 
> > > > Consider if goto even belongs in Eu's repertoire, regardless if it's
> > > > useful
> > > > or not, as long as we can still achieve the same thing through different
> > > > means.
> > > > Does it actually lend itself to Eu's characteristics? How will it affect
> > > > the
> > > > language internally?
> > > 
> > > Good questions, because where do we draw the line between usability and
> > > performance? Right now, on the performance end of the spectrum, assembly
> > > is the language of choice. For usability... I'd have to put Euphoria there
> > > just because I know it and am ignorant of other competing languages. We
> > > have to ask, at times, do we want to sacrifice usability (by which I mean
> > > ease-of-development, ease-of-maintenance, etc.) for performance?
> > > 
> > > Because Euphoria performs so well as is, my votes will tend to be toward
> > > usability (w/o sacrificing performance), and not toward performance (while
> > > sacrificing usability).
> > > 
> > > > Rather than a vote, I'd suggest compiling and summarizing all the
> > > > previous
> > discussions</font></i>
> > > > on goto and put in an official feature request on sourceforge.
> > > 
> > > Even as a feature request, it has to be discussed and ultimately voted on.
> > > I
> > > think you're right that this needs more discussion.
> > 
> > So we had the discussion, this is how it went:
> > 
> > }}}
<eucode>
> > [15:46] <euphoric> i don't know why i never got into C much. ever since
> > Euphoria came along, i haven't needed to.
> > [15:46] <euphoric> i mean, think about it. program with Euphoria then
> > translate.
> > [15:47] <euphoric> BAM!
> > [15:47] <katsmeow-afk> yeasm BAM, C code with gotos!
> > [15:47] <euphoric> Nuh-uh!
> > [15:48] <euphoric> Translated code does NOT use GOTOs.
> > [15:48] <euphoric> Does it?
> > [15:48] <euphoric> :)
> > [15:48] <katsmeow-afk> if you say so
> > [15:48] <iamlost> it uses them all over the place
> > [15:48] <iamlost> every single loop type is implemtend, not with C loops,
> > but with gotos
> > [15:48] <katsmeow-afk> lol
> > [15:48] <[Tiggr]> hehehehehe ;o)
> > [15:48] <iamlost> and the backend uses goto like crazy
> > [15:48] <katsmeow-afk> that has GOT to be posted on euphorum
> > [15:49] <katsmeow-afk> mind if i quote?
> > [15:49] <katsmeow-afk> or do you wanna do it?
> > [15:49] <iamlost> katsmeow-afk: please, go ahead :)
> > </eucode>
{{{

> > 
> > Kat
> 
> Because C is a lower level language.

Yet even C has loops which Eu doesn't have, and won't have in v4, and might not
ever have. And still the loops are made with goto! ( NO, i am not advocating
making loops with goto in Eu.)

Kat

27. Re: voting on GOTO

• Posted by CChris <christian.cuvier at agriculture?gouv.fr> Jun 04, 2008
• 812 views
• Last edited Jun 05, 2008

Yes to goto.

I don't see much myself using it, but if it helps others, they shouldn't beleft
out. And no one gave a single pointer to real world  spaghetti code.

CChris

29. Re: voting on GOTO

• Posted by c.k.lester <euphoric at ?klester.?om> Jun 04, 2008
• 804 views
• Last edited Jun 05, 2008

CChris wrote:
> 
> And no one gave a single pointer to real world  spaghetti code.

Well, duh... Euphoria doesn't have pointers.

31. Re: voting on GOTO

• Posted by Jeremy Cowgar <jeremy at cow?ar.co?> Jun 04, 2008
• 800 views
• Last edited Jun 05, 2008

c.k.lester wrote:
> 
> Jason Gade wrote:
> > Kat wrote:
> > > [15:48] <iamlost> every single loop type is implemtend, not with C loops,
> but with gotos</font></i>
> > > [15:48] <iamlost> and the backend uses goto like crazy
> > 
> > Because C is a lower level language.
> 
> That's what I tried to argue. They wouldn't hear me. :)

Because it's invalid. C has while loops, C has for loops, C has if statements,
the same as Euphoria. So, why does C then have goto's? Because in some cases it's
very valuable.

I've written hundreds of thousands of lines of production code in C. I've used
goto a few times, only when it has made the application more clear and easier to
maintain. To me we should have that ability in Euphoria.

What if, I wanted to *translate* my own domain language used for specific
business rules into Euphoria code? Are you saying I should not be allowed to use
goto's that would make the resulting code much cleaner, faster and easier to
maintain as does the Euphoria to C translator?

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

33. Re: voting on GOTO

• Posted by Derek Parnell <ddparnell at bigpo?d.co?> Jun 04, 2008
• 804 views
• Last edited Jun 05, 2008

Larry Miller wrote:
> 
> As long term users of this forum will be well aware, Robert Craig was opposed
> to the introduction of goto into Euphoria. If this should ever happen I can
> imagine what his initial reaction might be:
> 
> "WHAT HAVE THEY DONE TO MY BABY?"

Almost ... here is his response ...

----------------------
I vote No.
 
I don't want to now have to spend a couple of seconds
scanning the source code for each routine (and top-level),
checking for possible GOTO's or labels, every time I pick up
someone else's Euphoria code. I like being absolutely safe
in the knowledge that there can't be any.
 
e.g. to understand the control flow of any large block of code
containing:
 
     .... dozens of lines of code, running more than one screen
     .... but are there any GOTO's or labels in here?
     .... I guess I now have to scan it all to be certain I understand
     .... the flow of control
 
e.g.
      while x do
           Hmmm. I *used to* understand the possible
           ways that control flow
           could exit out of a while loop, but ...
           (... any GOTO's or labels in here?)
          < big chunk of messy code >
      end while
 
      for i ... do
          <big chunk of code>
          any GOTO's ?
          any labels?
          can I even be sure the loop var has been initialized? No.
      end for
 
      if x then -- used to look straightforward, but now ...?
          <big chunk of code>
          any GOTO's?
          any labels?
      else
          <big chunk of code>
          any GOTO's?
          any labels?
      end if
 
The arrangement was, that the developers
would not release any major feature without the
regular EUforum participants hearing exactly
what the proposed change is, and having their chance to
vote yes/no. Many contented users pay little attention to
discussions on EUforum, until they hear that a
significant change, requiring their vote, is possibly coming.
 
Note: I am just casting one vote against.
If the majority of EUforum + developers
wants GOTO, then that's fine with me.
 
Other than Kat, it didn't sound like anyone
had any urgent personal desire to use GOTO,
they just philosophically believed in letting
the other guy use it if he wished.
 
The implementation of GOTO should not be too hard,
but you might want to check for any assumptions
that I may have made regarding optimizing basic blocks,
especially in the Translator.
 
There are lots of language "features" that could
be easily added. That does not mean they should be added.
The test, especially for core statements in the language,
should not be: Would this provide some convenience
to some user in some situation?
 
I realize that I will not be forced to ever personally use GOTO,
but I will be forced to be aware that other people's code,
that I am trying to understand, *might* contain a GOTO.
 
Once you add a new core language statement, and it starts being used,
it will be virtually impossible to ever remove it.
Someone will have to maintain it forever,
even if it complicates other, possibly better
features and internal optimizations that might come along.
 
Regards,
    Rob Craig
    Rapid Deployment Software
    http://www.RapidEuphoria.com
-------------------

35. Re: voting on GOTO

• Posted by Derek Parnell <ddparnell at big??nd.com> Jun 04, 2008
• 828 views
• Last edited Jun 05, 2008

ChrisBurch3 wrote:
> 
> Hi
> 
> I thought Derek said it was already in.

I have been mis-quoted. I said it was being worked on. I never said it WAS in. I
was trying to get across the idea that it WILL BE in (unless  voted out).

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

37. Re: voting on GOTO

• Posted by Jeremy Cowgar <jeremy at c?wg?r.com> Jun 04, 2008
• 819 views
• Last edited Jun 05, 2008

> Chris Bensler wrote:
> > 
> > Language design should not be based purely on desire, there was alot of
> > thought
> > put into making Euphoria simplistic yet powerful and flexible. Those traits
> > should be paramount.
>

Indeed, join the dev list and you will see that the list was created May 17th
and for the month of may was 841 messages discussing language design, then
already for the month of June we are at 130 messages discussing language design.
These discussions are based on long term EUforum and sf.net requests. We are not
dreaming things up as we go on, but trying to solve existing problems that have
already been identified.

The devs on the list, and others who have helped contribute thoughts and ideas
on solutions *have* been working hard.

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

39. Re: voting on GOTO

• Posted by Bernie Ryan <xotron at blue?rog.?om> Jun 04, 2008
• 806 views
• Last edited Jun 05, 2008

Jeremy Cowgar wrote:
> Indeed, join the dev list and you will see that the list was created May 17th
> and for the month of may was 841 messages discussing language design, then
> already
> for the month of June we are at 130 messages discussing language design. These
> discussions are based on long term EUforum and sf.net requests. We are not
> dreaming
> things up as we go on, but trying to solve existing problems that have already
> been identified.
> 
> The devs on the list, and others who have helped contribute thoughts and ideas
> on solutions *have* been working hard.

Jeremy:

Then where is a purpose list of features and a list of list of features

currently implemented ?

Most user's don't want to monitor 841 messages discussing language design;

they just want a summary of what is being added.

What happen to euwikwi updates.
 
Bernie

My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API 

Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan

41. Re: voting on GOTO

• Posted by Matt Lewis <matthewwalkerlewis at gmai?.c?m> Jun 04, 2008
• 794 views
• Last edited Jun 05, 2008

Derek Parnell wrote:
> 
> if i recited e.e.cummings at 
>     the top of my 
>   voice would it be a problem? while
> having 
>     a shower - probably not. while 
> in the train going to work - probably
> yes.

FTFY.

Matt

43. Re: voting on GOTO

• Posted by Kat <KAT12 at coos?hs.ne?> Jun 04, 2008
• 798 views
• Last edited Jun 05, 2008

ken mortenson wrote:
> 
> Abstain.  I'm fine with letting the super-delegates choose.  Whatever
> Euphoria becomes, I can continue to use 2.5 or 3.
> 
> Is there a vision for Euphoria?  I believe Rob had one and developed it well.
> It has also inspired and enhanced my own vision, for which I am thankful.
> 
> It is a joy to write algorithms using sequences.  Losing Rob's vision of a
> simple powerful language is, although expected, disappointing.

How much simpler can you get than "goto"? Is there a shorter word in another
language (like Spanish "va") that would be simple enough? You CAN still write
exactly the same code you have been writing. I can tell you that i have not yet
used one goto when coding in Euphoria, and you don't haveto in Eu v4 either.

Kat

45. Re: voting on GOTO

• Posted by Chris Bensler <eu at creativ??ortal.ca> Jun 04, 2008
• 794 views
• Last edited Jun 05, 2008

Derek Parnell wrote:
> 
> 
> Join the developers list and be a participant then. You don't have to code
> anything
> but it will be easier to hear what's going on.
> 

Thanks Derek, I may. I haven't had much time to participate in Eu.
You might regret the suggestion though. HA! :)


Jeremy Cowgar wrote:
> 
> Indeed, join the dev list and you will see that the list was created May 17th
> and for the month of may was 841 messages discussing language design, then
> already
> for the month of June we are at 130 messages discussing language design. These
> discussions are based on long term EUforum and sf.net requests. We are not
> dreaming
> things up as we go on, but trying to solve existing problems that have already
> been identified.
> 
> The devs on the list, and others who have helped contribute thoughts and ideas
> on solutions *have* been working hard.
> 
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>

Sorry Jeremy, I didn't mean to undermine your efforts. I'm sure you guys aren't
just drawing straws to determine what to twiddle next and I know you are all very
capable. I was just expressing a point of view for the general audience, my
reason to vote no eventhough I haven't any real opinion about the usefulness of a
goto statement, not a mandate or accusation.

To paraphrase some wise words from Ray Smith that I finally accepted, no tool is
meant for every job.

Chris Bensler
Code is Alchemy

47. Re: voting on GOTO

• Posted by Chris Bensler <eu at ?re?tiveportal.ca> Jun 04, 2008
• 796 views
• Last edited Jun 05, 2008

Derek Parnell wrote:
> 
> Chris Bensler wrote:
> > 
> > What could you do with a goto that could not be done otherwise? 
> 
> Why does that matter?
> 
> If I recited e.e.cummings at the top of my voice, would it be a problem? While
> having a shower - probably not. While in the train going to work - probably
> yes.
> 
> GOTO in personal use only code is not an issue for me.
> GOTO in public domain code will probably have more bugs and cost too much to
> maintain and so will probably die out.
> 
> 
> > Rather than a vote, I'd suggest compiling and summarizing all
> > the previous discussions on goto and put in an official feature
> > request on sourceforge.
> 
> Be my guest.
> 
> -- 
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell

It matters for justification. Would you buy a car if you know you are only going
to use it one day in a year and you could just take the bus or a taxi, or even
rent a car and it would still be more economical? What if you don't even know
what you might need a car for but someone just says you have to have a car in
case you might need it someday?

.. if you were singing badly and I was your neighbour it might be a problem :D

Chris Bensler
Code is Alchemy

49. Re: voting on GOTO

• Posted by jacques deschênes <desja at globetrotter??et> Jun 04, 2008
• 788 views
• Last edited Jun 05, 2008

I abstain

51. Re: voting on GOTO

• Posted by Derek Parnell <ddparnell at bigpon?.co?> Jun 04, 2008
• 798 views
• Last edited Jun 05, 2008

Kat wrote:
 
> That would have been me that said here that it was in, because i was
> told by the guy who added it that it was in and working fine and
> passed tests. 

That's okay. There is probably a misunderstanding about what "in" means. I was
referring to the concept of "in" being that the code is merged into the main
respository and is now accepted as part of the language. That 'guy' probably
meant that in his personal copy of the code base, it works but he hasn't merged
that into the main trunk yet on any permentant basis.

> Do you want to be the person who has him tear out all his code,
> wasting the time it took to write it PLUS the time to tear it out,
> and delete it??

Ahhhh... the joys of source code control systems. Actually, reverting back is
very easy to do.

All of the people that are updating Euphoria accept that some of their efforts
will not see the light of day, for a variety of reasons. That's part of the deal.
For example, I spent a day and half replacing a perfectly good hash table
implementation with what I thought was some pretty slick enhancements. It turned
out though that my version ran five times slower than the original. Ouch! I spent
another day tweaking my code but still couldn't match the original. So I 'tore
out' my code (reverted back to the original). Shit happens - oh well.

The point is that we will write some code for review and experimentation,
knowing full well that it might be a dead end. So just because it's in does
always mean that it's "in".

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

53. Re: voting on GOTO

• Posted by Jeremy Cowgar <jeremy at cowgar?com> Jun 04, 2008
• 807 views
• Last edited Jun 05, 2008

Lucius L. Hilley III wrote:
>  
> See, this is a place where I get to prove my sitting on the fence
> for the moment.
> 
> GOTO is not a car the comes for free.  Others, may and will, use goto
> in their future code.  This means it takes up space.  Meaning it may
> get in the way of some peoples progress.  Its existance may or may
> not slow down the interpreter.  Much of that is determined based
> upon placemnet and structure.  And of course placemnet and structure
> is dictated by what previously existed and must be displaced to
> allow fot the injection of GOTO into the language.
> 

Maybe some of this needs clearing...

#1 Goto has been developed and tested.
#2 Goto does not slow down any existing benchmark. Pre-goto and Post-goto code
runs *exactly* the same
#3 The added code for goto is tiny. Once all figured out, it is very little
code.

I am unsure of what you mean by getting in the way of some peoples progress.

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

55. Re: voting on GOTO

• Posted by Jeremy Cowgar <jeremy at c?wgar.?om> Jun 04, 2008
• 814 views
• Last edited Jun 05, 2008

ken mortenson wrote:
> 
> Jeremy Cowgar wrote:
> 
> > Such is goto. It comes for free, no expenses what-so-ever. It will be out of
> > your way, but one day if you want to use it, it's there in an instant.
> 
> There is a cost.  It comes when you share code.  If code never required 
> maintenance (how often is that true?) perhaps you could make a case.
> 
> If your code is kept private, the cost is still there but you bare it alone
> and may not even notice it.
> 

This is true *only* if you think every instance of goto is evil. I do not think
anyone would claim *every* use of goto is evil.

I maintain that you can write terrible code with while as well as goto. You can
write beautiful code with while as well as goto.

The choice is yours. I also maintain that in some instances, goto can be more
effective than and clearer than a while loop, thus making maintenance costs less.

Can you write terrible code with goto? Sure! Can you write terrible code with
while? Sure! Can you write terrible code with an if statement? Sure! What kind of
coder are you? A terrible code writer? You can bet I will not use your library. A
professional coder who cares about speed, beauty and maintenance costs? You can
bet I will use your library regardless of the language constructs you use.

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

57. Re: voting on GOTO

• Posted by Lucius L. Hilley III <euphoria at u?kmar.?om> Jun 04, 2008
• 802 views
• Last edited Jun 05, 2008

Jeremy Cowgar wrote:
> 
> Lucius L. Hilley III wrote:
> >  
> > See, this is a place where I get to prove my sitting on the fence
> > for the moment.
> > 
> > GOTO is not a car the comes for free.  Others, may and will, use goto
> > in their future code.  This means it takes up space.  Meaning it may
> > get in the way of some peoples progress.  Its existance may or may
> > not slow down the interpreter.  Much of that is determined based
> > upon placemnet and structure.  And of course placemnet and structure
> > is dictated by what previously existed and must be displaced to
> > allow fot the injection of GOTO into the language.
> > 
> 
> Maybe some of this needs clearing...
> 
> #1 Goto has been developed and tested.
> #2 Goto does not slow down any existing benchmark. Pre-goto and Post-goto code
> runs *exactly* the same
> #3 The added code for goto is tiny. Once all figured out, it is very little
> code.
> 
> I am unsure of what you mean by getting in the way of some peoples progress.
> 
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>

Mister_xyz writes a magic_lib that uses goto.
Mister_xyz leaves the euphoria scene.
Later somebody discovers that magic_lib has bugs.
OR Somebody decides to add some super_magic to the lib.
Mister_xyz used goto's really badly.
Somebody has such a hard time adding to the magic_lib
that he:

1) Doesn't understand how it works and gives up.
2) Understands enough to simply reverse engineer and
   rewrite the code his own way.  Then add his
   super_magic.

    Lucius L. Hilley III - Unkmar

59. Re: voting on GOTO

• Posted by Jeremy Cowgar <jeremy at cowgar.?o?> Jun 04, 2008
• 834 views
• Last edited Jun 05, 2008

Lucius L. Hilley III wrote:
> 
> Mister_xyz writes a magic_lib that uses goto.
> Mister_xyz leaves the euphoria scene.
> Later somebody discovers that magic_lib has bugs.
> OR Somebody decides to add some super_magic to the lib.
> Mister_xyz used goto's really badly.
> Somebody has such a hard time adding to the magic_lib
> that he:
> 
> 1) Doesn't understand how it works and gives up.
> 2) Understands enough to simply reverse engineer and
>    rewrite the code his own way.  Then add his
>    super_magic.
> 

In previous posts I think I have explained why this is nothing to be afraid of.
The reason is simple. You can write bad goto code. You can write bad while code.
If you write bad goto code then you're not the type of person who will write good
while code. Your while code will be bad too. Thus, regardless if goto exists or
not, if magic_lib is coded poorly, tough luck.

In fact, when I use a library, I may not read every line, but I scan the library
code. If it's poorly coded then I will not use it. That's pre-goto or post-goto.
A bad library is not at all required on the existence of goto. Right now there
are horrible libraries in the archive that I wouldn't touch w/a ten foot pole,
and none of those have goto. (clarification, the vast amount of libraries in the
archive are great).

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

61. Re: voting on GOTO

• Posted by Matt Lewis <matthewwalkerlewis at gm?il.?om> Jun 05, 2008
• 833 views

Lucius L. Hilley III wrote:
> 
> Jeremy Cowgar wrote:
> > 
> > I am unsure of what you mean by getting in the way of some peoples progress.
> > 
> Mister_xyz writes a magic_lib that uses goto.
> Mister_xyz leaves the euphoria scene.
> Later somebody discovers that magic_lib has bugs.
> OR Somebody decides to add some super_magic to the lib.
> Mister_xyz used goto's really badly.
> Somebody has such a hard time adding to the magic_lib
> that he:
> 
> 1) Doesn't understand how it works and gives up.
> 2) Understands enough to simply reverse engineer and
>    rewrite the code his own way.  Then add his
>    super_magic.

This is true, but is independent of goto.  Even if well written, it can
be difficult to get in and grok your own code after a few months, let alone
someone else's.

Not that it's a paragon of great coding, but I can tell you that eusql (which
I'd say is probably the most complex bit of code I've released publicly)
would be a nightmare for someone else to step in and maintain.  Or consider
the front end for euphoria itself.  That's some difficult code to get into.

#2 also often happens because of NIH syndrome, which we as coders are all too 
susceptible to.  And which is also not necessarily unrelated to my previous
point.

Matt

63. Re: voting on GOTO

• Posted by Chris Bensler <eu at c?eativeportal.c?> Jun 05, 2008
• 797 views

Jeremy Cowgar wrote:
> 
> Chris Bensler wrote:
> >  
> > It matters for justification. Would you buy a car if you know you are only
> > going
> > to use it one day in a year and you could just take the bus or a taxi, or
> > even
> > rent a car and it would still be more economical? What if you don't even
> > know
> > what you might need a car for but someone just says you have to have a car
> > in
> > case you might need it someday?
> > 
> > .. if you were singing badly and I was your neighbour it might be a problem
> > :D
> > 
> 
> Chris,
> 
> One could say:
> 
> Would you accept a free Lamborgini, all expenses paid, insurance and all as
> well as a place to store it and a whistle that when you blow it, the car will
> come to you in an instant when you need it? Even though you have a car already
> that you can still use or even take the bus if you wish?
> 
> Such is goto. It comes for free, no expenses what-so-ever. It will be out of
> your way, but one day if you want to use it, it's there in an instant.
> 

But it's not free, there is hidden fees. In the form of confusion, uncertainty
and maintenance overhead of the language. As Rob pointed out, it may end up
hindering future language developments which are far more beneficial to all of
us.

What if you've already given me several cars that I never use? Now everytime I
want to use the car that I actually drive, I have to move the others out of the
way first.

As I said, it doesn't really matter to me either way if there is goto, but since
it doesn't matter to me and I don't see any need for it, I'd rather vote no and
be safe instead of sorry.

I don't see goto as a 'need', I see it as a 'want' and only by a small minority
really.

Aside from some convenience and the rare occasion that goto is actually more
practical, the only real justification I've seen for implementing goto is for
porting code from other languages to Eu, and for low-level optimization. Eu is
not low-level however.

The goto discussions always remind me of a debate over whether or not a glass is
half full or half empty. On one hand there is the people who say 'why implement
it?' and on the other is the people who say 'why not?' and that is about the
extent of the validity of the debate.

Chris Bensler
Code is Alchemy

65. Re: voting on GOTO

• Posted by ken mortenson <kenneth_john at ?ahoo.co?> Jun 05, 2008
• 798 views

Jeremy Cowgar wrote:
> The argument that goto costs is not valid, at least it's not any more valid
> that while costs as well as for, if, else, function, procedure, include,
> etc...

So you are saying that the costs are equal.  Your support for this is that
good and bad code can be written regardless of what you use.

While your supporting argument is true it is not the whole story.  The costs
are not equal.  A point which has already been made by many on this forum.
  
Labels are not equivalent to the start of a structure.  While can only be
the first instruction or entered from a preceding instruction.  Labels add
cost because they can be ENTERED FROM ANYWHERE in the current scope.

ENTERED FROM ANYWHERE is an additional cost beyond the equivalent costs that
goto and while share.  The more complicated your code the more significant
this cost becomes.  Jeremy, as long as you ignore this cost, you can not
make a valid argument.  Your argument must include this cost to be valid.

> About maintenance overhead of the language. That's just about nil. Rob himself
> also said goto would be very easy to add. Code that has already been added
> hasn't
> been touched for a long time.

So maintenance cost is almost nil and Rob knows that.  So his reason for
not wanting it in the language should be given some serious weight.

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

67. Re: voting on GOTO

• Posted by ken mortenson <kenneth_john at ?ahoo.co?> Jun 05, 2008
• 812 views

Jeremy Cowgar wrote:
> 
> ken mortenson wrote:
> >   
> > Labels are not equivalent to the start of a structure.  While can only be
> > the first instruction or entered from a preceding instruction.  Labels add
> > cost because they can be ENTERED FROM ANYWHERE in the current scope.
> > 
> 
> This totally depends on how you code. The few times I've used goto in C, the
> number of entry points was exactly one. Sure, get sloppy and enter from a
> thousand
> points, whoa! Look out, that's code that is probably easier to analyze the
> problem
> from scratch and rewrite w/o even becoming corrupted with the twisted mess
> that
> was originally created.

"This totally depends on how you code."

This sure sounds like a true statement.  Is it?  If I know Jeremy well I
know that he writes solid code and would never create uncertainty for me
as a maintenance programmer.  Now I find a label in Jeremy's code.

Is this label the beginning of a structure?  I don't know.  That's
uncertainty.  That's a potential cost.  Does the fact that I know Jeremy
to be a great programmer have any effect on my uncertainty.  Nope.

The best Jeremy can do, by writing the best code Jeremy knows how, is to
reduce my uncertainty, but never eliminate it.

Now, Ken is a really bad programmer.  He never uses while or for or any
of that unneeded crap because he can do it all with goto.  It's a good
thing this language gives me goto's or ken would never be able to share
his crappy code with anyone (and wouldn't that be a loss!)

Ken uses labels as subroutines.  He has switches everywhere to tell him
where he's been so he knows where to go next.  He writes impressively
complex code that only he is smart enough to maintain... for a while.

Klugnuts from the planet luvs_chaos writes bad structured code that Jeremy
has to maintain.  He comes to a while loop.  He knows exactly how he
got there with no uncertainty because this language doesn't have goto or
any of it's equivalents.  Jeremy fixes the code and gets his choice of
love slave from the planet luvs_chaos as a reward.

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

69. Re: voting on GOTO

• Posted by Salix <salix at ?reema?l.hu> Jun 05, 2008
• 814 views

Bernie Ryan wrote:
> 
> Jim Brown wrote:
> > 
> > Ok, so here is the official voting thread for the proposal on goto and
> > label.
> >  > 
> I vote No; would rather see forward reference instead of goto.
> 
> Bernie
> 

My vote is 'no' for goto.

Salix

71. Re: voting on GOTO

• Posted by ZNorQ <znorq at holha??.com> Jun 05, 2008
• 806 views

I vote 'yes'.

I haven't had use for GOTO since the days of basic 'coding' on the C64.
Personally, I hate GOTO; mainly for the same 'against' arguments stated earlier
in this 'poll'.

If the implementation of GOTO doesn't have any negative impact, why not? We have
to accept the fact that there are coders with different programming styles and
preferences, and if they choose to use that statement, let them.

Kenneth / ZNorQ

73. Re: voting on GOTO

• Posted by Mario Steele <eumario at trila?e.net> Jun 05, 2008
• 800 views

Chris Bensler wrote:
> 
> Jeremy Cowgar wrote:
> > 
> > ken mortenson wrote:
> > >   
> > > Labels are not equivalent to the start of a structure.  While can only be
> > > the first instruction or entered from a preceding instruction.  Labels add
> > > cost because they can be ENTERED FROM ANYWHERE in the current scope.
> > > 
> > 
> > This totally depends on how you code. The few times I've used goto in C, the
> > number of entry points was exactly one. Sure, get sloppy and enter from a
> > thousand
> > points, whoa! Look out, that's code that is probably easier to analyze the
> > problem
> > from scratch and rewrite w/o even becoming corrupted with the twisted mess
> > that
> > was originally created.
> > 
> > --
> > Jeremy Cowgar
> > <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
> 
> Seriously, this sounds as though goto should be implemented *just in case*
> someone
> might find a good use for it at some point in the future. What are the cases
> where it would actually be practical to use goto in Euphoria? Is it seriously
> worth increasing the language footprint for the sake of a blue moon?
> 
> I've been using Euphoria for just about 10 years now and have never even had
> the desire for a goto statement, let alone a need for it. And I have
> experience
> with it, none bad either.
> 
> I do not deny that it can be useful, but for the rare occasion when it is, is
> it really that unsurmountable to get around it, even if it does mean messier
> code and some lateral thinking?
> 
> Chris Bensler
> Code is Alchemy

Heh, Chris, I remember a time, when you believed Euphoria's Memory Management
libraries we no where near what it needed to be.  So you wrote your own memory
routines.  Were they absolutely nesscary?

allocate_string()  = allocate(length(string)+1) poke(mem,string,length(string))

You created the library, was it absolutely nesscary, just on the off chance that
someone else would find it useful?  That it, as you said, "might be implemented"
?

Mario Steele
http://enchantedblade.trilake.net
Attaining World Dominiation, one byte at a time...

75. Re: voting on GOTO

• Posted by CChris <christian.cuvier at agric?ltur?.gouv.fr> Jun 05, 2008
• 810 views

Lucius L. Hilley III wrote:
> 
> Jeremy Cowgar wrote:
> > 
> > Lucius L. Hilley III wrote:
> > >  
> > > See, this is a place where I get to prove my sitting on the fence
> > > for the moment.
> > > 
> > > GOTO is not a car the comes for free.  Others, may and will, use goto
> > > in their future code.  This means it takes up space.  Meaning it may
> > > get in the way of some peoples progress.  Its existance may or may
> > > not slow down the interpreter.  Much of that is determined based
> > > upon placemnet and structure.  And of course placemnet and structure
> > > is dictated by what previously existed and must be displaced to
> > > allow fot the injection of GOTO into the language.
> > > 
> > 
> > Maybe some of this needs clearing...
> > 
> > #1 Goto has been developed and tested.
> > #2 Goto does not slow down any existing benchmark. Pre-goto and Post-goto
> > code
> > runs *exactly* the same
> > #3 The added code for goto is tiny. Once all figured out, it is very little
> > code.
> > 
> > I am unsure of what you mean by getting in the way of some peoples progress.
> > 
> > --
> > Jeremy Cowgar
> > <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
> 
> Mister_xyz writes a magic_lib that uses goto.
> Mister_xyz leaves the euphoria scene.
> Later somebody discovers that magic_lib has bugs.
> OR Somebody decides to add some super_magic to the lib.
> Mister_xyz used goto's really badly.
> Somebody has such a hard time adding to the magic_lib
> that he:
> 

Fir starters, bugs were found in magic_lib, but adding to it is still being
considered. So the code must not be tht bad. I doubt it could if goto had been
used unwisely.

> 1) Doesn't understand how it works and gives up.

This could happen for a variety of reasons completely unrelated to goto. 

> 2) Understands enough to simply reverse engineer and
>    rewrite the code his own way.  Then add his
>    super_magic.

That's his call. If he catches mice, who cares about the color of that cat?

> 
>     Lucius L. Hilley III - Unkmar

For all the above, I think this scenario is very unrealistic.

CChris

77. Re: voting on GOTO

• Posted by Jim Brown <jbrown105 at li?uxb?ddhist.net> Jun 05, 2008
• 801 views

Jason Gade wrote:
> 
> Heh, honestly you probably shouldn't have asked for comments 
> (Or at least to keep comments in a separate thread).

Yes, well, I never said I was a smart guy. :)

> 
> But how long is the voting going to remain open? One week? What's the tally
> so far?

So far, 13 in favor of GOTO, 6 against, 3 formally abstaining.

Of that, from the dev list, 7 voted in favor, 1 against, 1 formally abstaining.

I think we should wait until at least 19:00 UTC. After that, we can consider the
poll closed.

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

79. Re: voting on GOTO

• Posted by Fernando Bauer <fmbauer at ?otmail.co?> Jun 05, 2008
• 824 views

Greg Haberek wrote:
> 
> 
> I vote NO. NO. NO. NO. NO. NO. NO. NO. NO. NO. NO. NO. NO. Explicitly NO, and
> once moreover, NO! GOTO, in any form, breaks the inherently logical "flow" of
> *all* programming (especially Euphoria, with its top-down methodology).
Sorry, I disagree.

> I don't
> care if it's been implemented and tested, taken around the block, and fed to
> the dog. To quote my cat Sasha, "DO NOT WANT."
> 
> One may argue, "but Greg, you don't *have* to use goto, only those who need
> it will use it!" WRONG! You. Don't. Need. GOTO. Not now, not ever. If you need
> GOTO, then you're doing it wrong. Go back and re-think the layout of your
> code.
Sorry, I disagree.

> If it actually flows in a logical and coherent manner, then GOTO is
> irrelevant.
> I'm a firm believer that GOTO was invented by sloppy programmers, for sloppy
> programmers.
Sorry, I disagree.

> 
> -Greg

As I already said, IMHO, in some situations, GOTO can be the best tool regarding
speed, elegance, simplicity and maintenance. I agree with Jeremy about this
subject.
- Fernando

81. Re: voting on GOTO

• Posted by Jason Gade <jaygade at y?hoo?com> Jun 05, 2008
• 800 views

CChris wrote:
> 
> Fernando Bauer wrote:
> > 
> > Greg Haberek wrote:
> > > 
> > > 
> > > I vote NO. NO. NO. NO. NO. NO. NO. NO. NO. NO. NO. NO. NO. Explicitly NO,
> > > and
> > > once moreover, NO! GOTO, in any form, breaks the inherently logical "flow"
> > > of
> > > *all* programming (especially Euphoria, with its top-down methodology).
> > Sorry, I disagree.
> > 
> > > I don't
> > > care if it's been implemented and tested, taken around the block, and fed
> > > to
> > > the dog. To quote my cat Sasha, "DO NOT WANT."
> > > 
> > > One may argue, "but Greg, you don't *have* to use goto, only those who
> > > need
> > > it will use it!" WRONG! You. Don't. Need. GOTO. Not now, not ever. If you
> > > need
> > > GOTO, then you're doing it wrong. Go back and re-think the layout of your
> > > code.
> > Sorry, I disagree.
> > 
> > > If it actually flows in a logical and coherent manner, then GOTO is
> > > irrelevant.
> > > I'm a firm believer that GOTO was invented by sloppy programmers, for
> > > sloppy
> > > programmers.
> > Sorry, I disagree.
> > 
> > > 
> > > -Greg
> > 
> > As I already said, IMHO, in some situations, GOTO can be the best tool
> > regarding
> > speed, elegance, simplicity and maintenance. I agree with Jeremy about this
> > subject.
> > - Fernando
> 
> I'd be a little less enthusiastic.
> 
> Using goto in code is like using "thing" or "get" in a sentence. You can say
> almost everything with these words, without having to care looking for the
> proper
> word. The burden of decodng is on the reder/listener.
> 
> Yet, in some cases, these words are apt and should be used, because the more
> specialised wors would be improper or awkward.
> 
> Now, conrary to written or spoken language, code goes through various stages
> before being at production level. During the earlier stage, its logic is in
> a flu, and using goto speeds development by removing many bugs related to code
> structure changes.
> 
> However, as it tends to raise the maintainance cost, it is best removed from
> production code at 97%, left only in cases where the specialised constructs
> wouldn't perform better, whichver criterium is used to gauge performance.
> 
> This is why I still think it is better to have goto than not to have it. Just
> advertise it as a last resort tool, when the speialised, preferred constructs
> hit some limit.
> 
> CChris

Wow. That was really well said, Chris. I liked the analogy.

Kudos.

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

83. Re: voting on GOTO

• Posted by Jason Gade <jaygade at ?a?oo.com> Jun 05, 2008
• 784 views

Chris Bensler wrote:
> Why is goto even being considered at this timeanyways, if there is no real
> need
> for it? We should be trying to fill in gaps in the language, not put sprinkles
> on the cake.
> 
> I would much rather see oop, named sequence elements and better C interfaces
> to name a few things off the top of my head which I do miss DAILY.
> 
> 
> Chris Bensler
> Code is Alchemy

Why is goto being considered at this time?

Jeremy Cowagar (and others) are making a new and improved standard library for
Euphoria.

It was decided to incorporate this library in with Euphoria version 4.0.

Some features, many of which have been outstanding on sourceforge for a long
time, were included in a feature list for 4.0 and the new standard library will
rely upon them.

Goto is one such feature which, as usual, has been discussed to death.

We were discussing goto on the developer's list when Rob Craig made an
appearance stating his opposition to goto but that he would go along with it as
long as a vote was taken in Euforum -- and that the community at large should be
aware of the changes that are being discussed.

So, that's why it's being discussed. Goto has been implemented, should it be
included?

As for named sequence elements, enumerations have been added to 4.0. No oop, and
no better C interface.

Maybe you should post about what would make a better C interface for future
versions?

I think that 4.0 is approaching feature freeze though. Since Jeremy and Matt are
more the leads on this I'll let them say for sure.

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

85. Re: voting on GOTO

• Posted by Greg Haberek <ghaberek at gmail?co?> Jun 05, 2008
• 801 views

As I recall, the slogan on the Euphoria webpage says "Just say NO to complicated
programming languages!" Does GOTO not complicate things? I couldn't possibly
imagine it would make Euphoria any simpler. We need to maintain that simplicity.

On a more general note, I think we're moving way too fast on implementing new
"features" in Euphoria. Just because we can add a feature, doesn't mean we
should. I don't want to see Euphoria start Jumping the shark[1], and I feel it is
moving in that direction.

-Greg

1 http://en.wikipedia.org/wiki/Jumping_the_shark

87. Re: voting on GOTO

• Posted by Chris Bensler <eu at creativepor?a?.ca> Jun 05, 2008
• 797 views

Greg Haberek wrote:
> 
> 
> As I recall, the slogan on the Euphoria webpage says "Just say NO to
> complicated
> programming languages!" Does GOTO not complicate things? I couldn't possibly
> imagine it would make Euphoria any simpler. We need to maintain that
> simplicity.
> 
> On a more general note, I think we're moving way too fast on implementing new
> "features" in Euphoria. Just because we can add a feature, doesn't mean we
> should.
> I don't want to see Euphoria start Jumping the shark[1], and I feel it is
> moving
> in that direction.
> 

Thank you Greg, I share these sentiments exactly.

Chris Bensler
Code is Alchemy

89. Re: voting on GOTO

• Posted by Greg Haberek <ghaberek at gma?l.c?m> Jun 05, 2008
• 788 views

> Look at the code in PCRE, as mentioned already and then see how goto would
> greatly
> simplify things.

There seem to be several chunks of PCRE-related code scattered around the SVN
trunk, some C, some Euphoria. Nothing I've looked at thus far has expressed a
need for GOTO. Perhaps you could point me in the right direction?


> Actually, for the feature set we've added we've been moving pretty slowly.
> Things
> have been discussed to great lengths on the dev list before we even think
> about
> proposing things here. In less the last 20 days nearly 1,000 (literally)
> messages
> have been exchanged on the dev list. Many ideas adopted, many canned, many
> that
> were good but slated for the future.

I completely was unaware of any developer mailing list. I thought EUforum was
the de facto discussion on the direction of Euphoria. In fact, I am not even a
developer on the project, but I would very much like to be. I may not do much,
but if I could be added, that would be great.


> Everything that has been implemented thus far have been requests many years
> old. Is it bad that these requests many years old that have been discussed
> high
> and low are being implemented finally or implemented in the 4.0 release?

A lot of "feature requests" popup on the EUforum over and over, mostly from
newbies who've recently joined the list and were unaware the potential "feature"
had already been discussed to death. A lot of these potential "features" are
often turned down immediately, like the forward-referencing routine_id() bug,
GOTO and labels, OOP, and threading (just a few for example). These all get
turned down each time they come up, as the general consensus was that they are
bad and/or Rob did not want to implement them. But now that "we" can add
features, people seem more adamant about just jumping and adding them.


-Greg

91. Re: voting on GOTO

• Posted by Derek Parnell <ddparnell at bigpo?d?com> Jun 05, 2008
• 772 views

Greg Haberek wrote:

> I think we're moving way too fast on implementing new "features"
> in Euphoria.

What is the appropriate rate to implement new "features"?

What is the criteria for considering a "feature"?

What is the criteria for accepting a "feature"?

What is the criteria for rejecting a "feature"?

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

93. Re: voting on GOTO

• Posted by Bernie Ryan <xotron at bl?efr?g.com> Jun 05, 2008
• 800 views

Jim Brown wrote:
> 

> goto is more or less a requirement to be able to port PCRE.
> 


   And who decided that PCRE was a necessary feature to be added into

   the core of Euphoria ?

   That should be in a library or a DLL/SO instead of bloating the

   core of the language.

   How many users need to use it ?
  

Bernie

My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API 

Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan

95. Re: voting on GOTO

• Posted by Jeremy Cowgar <jeremy at cowg?r?com> Jun 05, 2008
• 806 views

Chris Bensler wrote: 
> > > Why is goto even being considered at this timeanyways, if there is no real
> > > need
> > > for it? We should be trying to fill in gaps in the language, not put
> > > sprinkles
> > > on the cake
> > >  
> > 
> > The code exists and is ready to be added. The elease of 4.0 has been delayed
> > enough, some of these things may have to wait until 4.1.
> 
> If I make you a poop-pie, does that mean you should be obligated to eat it?
> 
> Sorry bad analogy, I don't mean that goto is crap, but it's funny and to the
> point :)

The question was not about the merits of goto but as to why it was being
considered. So, in your example, because the poop-pie existed, it too would be
considered for eating. Hopefully only considered for a split second, but,
considered.

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

97. Re: voting on GOTO

• Posted by Jim Brown <jbrown105 at linuxbu?dhist.?et> Jun 05, 2008
• 786 views

Chris Bensler wrote:
> 
> Jim Brown wrote:
> > 
> > Chris Bensler wrote:
> > > 
> > > Going back to the discussion of goto. As I said before, I'm not really for
> > > or
> > > against it. I voted no because nobody has been able to show a legitimate
> > > need
> > > for it and because it's always easier to add it later than to take it out
> > > when/if
> > > it's regretted. I'm just not about to say yes, toss it in there, because
> > > some
> > > people say 'why not!?'.
> > 
> > goto is more or less a requirement to be able to port PCRE.
> 
> Is it more or less? Can you elaborate a bit on why goto is needed? Maybe you
> can convince more than just myself.

I didn't try to do the port myself, so I don't know.

PCRE uses goto quite heavily (as you can tell for yourself by doing a grep on
the source code). Although it is certainly possible to rewrite those uses of goto
to use state machine flags and whatnot, the burden of doing so is considerable
and doesn't have any clear benefit.

> 
> > > 
> > > Why is goto even being considered at this timeanyways, if there is no real
> > > need
> > > for it? We should be trying to fill in gaps in the language, not put
> > > sprinkles
> > > on the cake
> > >  
> > 
> > The code exists and is ready to be added. The elease of 4.0 has been delayed
> > enough, some of these things may have to wait until 4.1.
> 
> If I make you a poop-pie, does that mean you should be obligated to eat it?
> 

Which is why it is being discussed now, instead of having been committed two
weeks ago.

> 
> Chris Bensler
> Code is Alchemy

99. Re: voting on GOTO

• Posted by Jason Gade <jaygade at yah?o.?om> Jun 05, 2008
• 803 views

Chris Bensler wrote:
> 
> Jason Gade wrote:
> > 
> > Chris Bensler wrote:
> > > Why is goto even being considered at this timeanyways, if there is no real
> > > need
> > > for it? We should be trying to fill in gaps in the language, not put
> > > sprinkles
> > > on the cake.
> > > 
> > > I would much rather see oop, named sequence elements and better C
> > > interfaces
> > > to name a few things off the top of my head which I do miss DAILY.
> > > 
> > > 
> > > Chris Bensler
> > > Code is Alchemy
> > 
> > Why is goto being considered at this time?
> > 
> > Jeremy Cowagar (and others) are making a new and improved standard library
> > for
> > Euphoria.
> > 
> > It was decided to incorporate this library in with Euphoria version 4.0.
> > 
> > Some features, many of which have been outstanding on sourceforge for a long
> > time, were included in a feature list for 4.0 and the new standard library
> > will
> > rely upon them.
> 
> Why would it be relying on features that have not even been officially
> approved
> yet? It appears to me that consulting the community is more of a afterthought
> and simple courtesy ebenthough the decision has already been made.

We /are/ consulting the community. And many of these things have been discussed
over and over and over again.

> I dont' mean that to be rude or bitter. I can easily relate to those people
> who have spent alot of effort to provide a prototype of the proposed changes
> and don't want to see their efforts tossed aside. Unfortunately, just because
> someone already spent the effort doesn't mean that it should be accepted.
> There
> is more at stake than bruising someone's feelings.

I agree. I'm one of the "simpler is better" crowd, myself.

> 
> > Goto is one such feature which, as usual, has been discussed to death.
> 
> I know, and nothing is ever resolved in the dicussion, it's an age-old
> programmers debate, which just tells me that it should be consider VERY
> CAREFULLY.
> There is merits to both sides of the debate.

Of course it does. But after ten years or more of debate, at what point do  you
throw up your hands and say, "whatever."

I don't like goto. I'm just tired of hearing about it. And a couple of people
have made some decent arguments in support.

> > We were discussing goto on the developer's list when Rob Craig made an
> > appearance
> > stating his opposition to goto but that he would go along with it as long as
> > a vote was taken in Euforum -- and that the community at large should be
> > aware
> > of the changes that are being discussed.
> > 
> > So, that's why it's being discussed. Goto has been implemented, should it be
> > included?
> 
> Fair enough. I do not think that 1 day warrants a valid polling time however.
> I would suggest at least 1 month, to give people a chance to have their say,
> who are not around every single day. I know you guys are eager to move on and
> get v4 out the door, but this deserves a high level of scrutiny.

We, the community, have been discussing goto /forever/.

> 
> > As for named sequence elements, enumerations have been added to 4.0. No oop,
> > and no better C interface.
> 
> I'll have to look into what enum.e is exactly, but it doesn't sound liek the
> same thing. In any case, a library is not any less cumbersome than using
> constants
> for the indices. It can resolve the namespace contamination, but it cannot
> make
> particularly clean code.
> 
> As far as I can tell, I think a best case scenario would be:
> s["foo".."bar"]["fubar"]
> compared to 
> subs(subs(s,{"foo","bar"}),{"fubar"})
> 
> Not that a lib wouldn't be a good interim solution to offer, but it is not
> ideal.

enums aren't in a library. It's a new keyword for automatic constants.

> 
> > Maybe you should post about what would make a better C interface for future
> > versions?
> 
> Mainly builtin support for C-style structs would make a huge difference in the
> standardization and simplification of porting API's to Eu.

See, this is where I would disagree and say that Euphoria doesn't need C style
structs -- at least not built-in.

> 
> This post is already deviating too far off-topic, so I will refrain from any
> further explanation.
> 
> Anyhow, I will concede on the goto discussion. I think I've more than made my
> points. No new features should be considered lightly regardless if they seem
> insignificant, because in the end nothing is insignificant. Especially
> something
> as contraversial as goto. I'm just trying to raise alarms for any would-be
> voters
> who may be more-or-less unbiased on the topic.
> 
> I know there is merit to having goto, but I would compare it to buying a
> backhoe,
> just in case you might decide to landscape your yard someday.
> 
> Maybe porting code from other languages is enough reason to include goto. I
> dunno, I can't really decide. Since I'm not sure, I will err on the side of
> caution.
> 
> Chris Bensler
> Code is Alchemy

I think that goto is the most controversial feature.

There are also new words such as continue, retry, and entry which are
specialized gotos. Personally, I prefer goto to retry and entry myself (even
though I don't really like any of them) but I've been a pretty lone voice in the
wilderness.

There is a list about about 10-15 new features on the roadmap, most of which
have been implemented and are being tested and tweaked.

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

101. Re: voting on GOTO

• Posted by Chris Bensler <eu at creat?ve?ortal.ca> Jun 05, 2008
• 785 views

Derek Parnell wrote:
> 
> Greg Haberek wrote:
> 
> > I think we're moving way too fast on implementing new "features"
> > in Euphoria.
> 
> What is the appropriate rate to implement new "features"?
> 
> What is the criteria for considering a "feature"?
> 
> What is the criteria for accepting a "feature"?
> 
> What is the criteria for rejecting a "feature"?
> 
> -- 
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell

Excellent questions Derek, I think those should be dev-team directives.
Or are they already?

Chris Bensler
Code is Alchemy

103. Re: voting on GOTO

• Posted by Greg Haberek <ghaberek at gma?l.com> Jun 05, 2008
• 812 views

These are my personal standings on general software development.

> What is the appropriate rate to implement new "features"?

One feature, at a time, should be chosen and implemented. Multiple features may
be implemented in a single release, so long as they're implemented in a linear
fashion and don't break or replace the previous feature.


> What is the criteria for considering a "feature"?

An addition to the product whose benefits outweigh its costs. One which aims to
make the product simpler, faster and/or easier to use, without being confusing or
obtuse. "Bug fixes" are not features.


> What is the criteria for accepting a "feature"?

It must be generally accepted by the active development community. Votes should
be based on seniority, which in turn is based on previous contributions to the
product and level of competence in using it.


> What is the criteria for rejecting a "feature"?

Replace "accepted" with "rejected" in the paragraph above.


-Greg

105. Re: voting on GOTO

• Posted by Jeremy Cowgar <jeremy at cowg?r.c?m> Jun 05, 2008
• 795 views

Greg Haberek wrote:
> 
> These are my personal standings on general software development.
> 
> > What is the appropriate rate to implement new "features"?
> 
> One feature, at a time, should be chosen and implemented. Multiple features
> may be implemented in a single release, so long as they're implemented in a
> linear fashion and don't break or replace the previous feature.
> 

We have 3-4 developers. Should the others just sit around? One developer may
implement, test commit. Features are tested before commit. We do peer review.
When John commits Jane looks at the changes. Jane sees something John did not and
she adds a test, finds a bug, fixes and commits. That may be the next day. In the
mean time, Jed is also working on another feature. John still had more coding
time available to him, so he started on the next request or maybe knock out a few
bug requests. At any one moment 3, 4, 5 features may be in development. That's
the only efficient way of doing it.
 
> > What is the criteria for considering a "feature"?
> 
> An addition to the product whose benefits outweigh its costs. One which aims
> to make the product simpler, faster and/or easier to use, without being
> confusing
> or obtuse. "Bug fixes" are not features.
> 

I'll bet the above would never be able to be agreed upon, just look at the goto
debate. I think the benefits of goto outweigh the cost, others do not.

> 
> > What is the criteria for accepting a "feature"?
> 
> It must be generally accepted by the active development community. Votes
> should
> be based on seniority, which in turn is based on previous contributions to the
> product and level of competence in using it.
> 

That sounds OK, however, I think it's beyond realistic implementation. You also
have many issues with basing things of seniority. For instance, Jim has been a
Euphoria programmer since 1921 and he absolutely hates this new idea of a while
loop. The good old goto can do a while loop, a for loop and any other loop you
may dream up in your wild, young mind. In the mean time Josh and Jack leave the
Euphoria scene because they are tired of Jim's old ways. Now there is a huge gap
between Jim's seniority and everyone else.

Different voting systems have been tested high and low. All have problems.
What's the best? I don't know.

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

107. Re: voting on GOTO

• Posted by Matt Lewis <matthewwalkerlewis at g?ail.co?> Jun 05, 2008
• 788 views

Greg Haberek wrote:
> 
> > Look at the code in PCRE, as mentioned already and then see how goto would
> > greatly
> > simplify things.
> 
> There seem to be several chunks of PCRE-related code scattered around
> the SVN trunk, some C, some Euphoria. Nothing I've looked at thus far
> has expressed a need for GOTO. Perhaps you could point me in the right
> direction?

matt@oneill:~/euphoria/dev/rds/source/pcre$ grep -c goto *c | grep -v \:0
pcre_compile.c:96
pcre_dfa_exec.c:9
pcre_exec.c:28
 
> I completely was unaware of any developer mailing list. I thought EUforum
> was the de facto discussion on the direction of Euphoria. In fact, I am
> not even a developer on the project, but I would very much like to be. I
> may not do much, but if I could be added, that would be great.

It's been announced here, though given the volume of this forum, it's 
easy to miss a post here and there.  Anyone can join.  It was created in
part to get rid of some of the noise here.  It's a pretty active list,
and most of what is said there is probably not of interest to the average
euphoria user, though it's not all implementation.  There's a lot of 
discussion about design issues, too.
 
> A lot of "feature requests" popup on the EUforum over and over, mostly
> from newbies who've recently joined the list and were unaware the
> potential "feature" had already been discussed to death. A lot of these
> potential "features" are often turned down immediately, like the
> forward-referencing routine_id() bug, GOTO and labels, OOP, and threading
> (just a few for example). These all get turned down each time they come
> up, as the general consensus was that they are bad and/or Rob did not
> want to implement them. But now that "we" can add features, people seem
> more adamant about just jumping and adding them.

More like, people who would have liked to have done so would have previously,
but weren't able.  Not that everything that's been done has been perfect,
but I think that for such an unstructured project, it's gone pretty well.

Matt

109. Re: voting on GOTO

• Posted by Jim Brown <jbrown105 at linuxbud??ist.net> Jun 05, 2008
• 785 views

The poll closes at 13 in favor, 8 against, and 3 abstaining.

Jim Brown wrote:
> 
> Jason Gade wrote:
> > 
> > Heh, honestly you probably shouldn't have asked for comments 
> > (Or at least to keep comments in a separate thread).
> 
> Yes, well, I never said I was a smart guy. :)
> 
> > 
> > But how long is the voting going to remain open? One week? What's the tally
> > so far?
> 
> So far, 13 in favor of GOTO, 6 against, 3 formally abstaining.
> 
> Of that, from the dev list, 7 voted in favor, 1 against, 1 formally
> abstaining.
> 
> I think we should wait until at least 19:00 UTC. After that, we can consider
> the poll closed.
> 
> > 
> > --
> > 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.

111. Re: voting on GOTO

• Posted by Bernie Ryan <xotron at bl?ef?og.com> Jun 05, 2008
• 795 views

Matt Lewis wrote:
> 
> 
> The size of the interpreter was increased by 100-150KB.  I think this is a
> very reasonable tradeoff.
> 

Matt:

   Why don't we just change the IL code to PARROT and then we will

   be able to merge all the features used in other languages.


Bernie

My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API 

Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan

113. Re: voting on GOTO

• Posted by Matt Lewis <matthewwalkerlewis at gmai?.?om> Jun 05, 2008
• 815 views

Bernie Ryan wrote:
> 
>    Why don't we just change the IL code to PARROT and then we will
>    be able to merge all the features used in other languages.

I agree that a port to Parrot would be interesting.  I recall Pete Lomax
worked on that for a while.  I did a port to .Net.  It's far from trivial,
however.  Also, Parrot is still under development, and I don't think there's 
any good sense about when it will be considered stable.

Plus, we already have a good VM.

Matt

115. Re: voting on GOTO

• Posted by Colin Taylor <colinetaylor at gmail?co?> Jun 05, 2008
• 798 views
• Last edited Jun 06, 2008

I vote NO.

 - Colin

117. Re: voting on GOTO

• Posted by Kat <KAT12 at coo?ahs.ne?> Jun 05, 2008
• 822 views
• Last edited Jun 06, 2008

Chris Bensler wrote:

<snip>
 
> I know there is merit to having goto, but I would compare it to buying a
> backhoe,
> just in case you might decide to landscape your yard someday.

Have you SEEN my yard?! Lets start with a trackhoe and a couple D10's, and get
them to bury a small nuke, just for starters! Really, there's a 20ft layer of
hard shale 70ft down the mountain, and .. wait.. were you serious?

Kat

119. Re: voting on GOTO

• Posted by Andy Serpa <ac at onehor?eshy.c?m> Jun 05, 2008
• 815 views
• Last edited Jun 06, 2008

For whatever it is worth -- one vote I suppose -- I vote NO on goto.

121. Re: voting on GOTO

• Posted by Derek Parnell <ddparnell at ?igpond.co?> Jun 05, 2008
• 801 views
• Last edited Jun 06, 2008

Bernie Ryan wrote:
>    Why don't we just change the IL code to PARROT 

Or LLVM?

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

123. Re: voting on GOTO

• Posted by Robert Craig <rds at Rapid?uphor?a.com> Jun 05, 2008
• 821 views
• Last edited Jun 06, 2008

Jim Brown wrote:
> The poll closes at 13 in favor, 8 against, and 3 abstaining.

We haven't established any formal rules about voting (yet), 
but since I already put a message on the main page 
that voting would close "in a couple of days",
I think we need to keep the poll open for 
another 48 hours, especially since there was 
no warning that a vote was coming, and some people 
only check EUforum every few days.

As I said, I will gladly respect the outcome of the vote,
whichever way it goes, but I know that some people will 
be rightfully upset if they are caught off-guard and 
given no chance to vote on something as important as this.
Not all changes will require a vote by the main EUforum,
but I think that goto qualifies.

By the way, if anyone wants to become a developer,
let me know. I'll add any responsible person
who has a strong knowledge of Euphoria, and perhaps C,
and who is serious about helping out. You'll have to
get a (free) SourceForge id, and learn about SVN.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com

125. Re: voting on GOTO

• Posted by Jim Brown <jbrown105 at linux??ddhist.net> Jun 05, 2008
• 809 views
• Last edited Jun 06, 2008

Ok, the poll shall continue.

Is Saturday (06/07/08) 17:00 UTC agreeable to everyone?

127. Re: voting on GOTO

• Posted by Robert Craig <rds at RapidEu?h?ria.com> Jun 05, 2008
• 819 views
• Last edited Jun 06, 2008

Jim Brown wrote:
> 
> Ok, the poll shall continue.
> 
> Is Saturday (06/07/08) 17:00 UTC agreeable to everyone?

Fair enough.
I'll state that on the RapidEuphoria main page.
I assume UTC and GMT are the same thing.
EUforum shows times in GMT.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com

129. Re: voting on GOTO

• Posted by Kat <KAT12 at coos??s.net> Jun 06, 2008
• 815 views

Robert Craig wrote:
> 
> Jim Brown wrote:
> > 
> > Ok, the poll shall continue.
> > 
> > Is Saturday (06/07/08) 17:00 UTC agreeable to everyone?
> 
> Fair enough.
> I'll state that on the RapidEuphoria main page.
> I assume UTC and GMT are the same thing.
> EUforum shows times in GMT.

Lets use UT1 and vote on which to use (UT1, UTC, GMT) to end the vote with.
Without accurate time keeping, we might miss someone's vote on this most
earthshaking topic, the most ultimately important vote in all of Euphoria's
history: goto. Time keeping is vital to all modern economies, synchronizing the
movements of goods and services, keeping computers in sync on phone lines, irc
networks, banks, and countries' defence networks. We can't just randomly pick a
reference system of time willynilly, nor allow any one person to dictate how we
measure time, this must be a well thought out and considered occurance, with
input by everyone who uses time! I call for at least 10 years of discussion on
this critical topic, and then a vote, with the vote terminated by some other
event than a artificial time measurement.

Kat

131. Re: voting on GOTO

• Posted by Kat <KAT12 at coosahs.ne?> Jun 06, 2008
• 804 views

c.k.lester wrote:
> 
> Kat wrote:
> > 
> > ...the most ultimately important vote in all of Euphoria's history: goto.
> 
> I asked for examples where GOTO would help streamline or otherwise make a
> Euphoria program better. Nobody can provide any*- not even you, its most
> vocal supporter and advocate.
> 
> (*Well, they haven't, yet.)

It's been shown, been done, been 10 years. Code has been provided, only to be
shot down which chants of "can't it be done another way?" and "that's evil" and
"who would want to do that?". So point me to the dunking chair, i'll sit down and
buckle myself in... i acknowledge you win, but you are still wrong.

Kat

133. Re: voting on GOTO

• Posted by Jim Brown <jbrown105 at linuxbudd??st.net> Jun 06, 2008
• 807 views

c.k.lester wrote:
> 
> Kat wrote:
> > c.k.lester wrote:
> > > Kat wrote:
> > > > ...the most ultimately important vote in all of Euphoria's history:
> > > > goto.
> > > I asked for examples where GOTO would help streamline or otherwise make a
> > > Euphoria program better. Nobody can provide any*- not even you, its most
> > > vocal supporter and advocate.
> > > (*Well, they haven't, yet.)
> > It's been shown, been done, been 10 years.
> 
> No, it hasn't. Ever. Not once. A Euphoria-code example.

I think that goto does has merit as a way to improve the readability and
maintainability of code. I and others provided examples (or links to such) which
have not yet been contested. By you or any one else.
With that issue out of the way .. you want to focus on speed. Fair enough.

What you were asking was quite hard to do since one could have to be able to
write it and somehow show that it works without actually being able to test the
code. A rather high burden of proof. This is why most examples are done in other
languages. In fact, to counter this, please come up with an example in euphoria
where using goto slows down the code. Pretty please with a berry on top?

For a real life example, compare the speed of EuRegex and PCRE. I'd ask to
compare the speed of EuRegex to EuPCRE, but I can't. I'm confident that if EuPCRE
did exist, it'd be faster than EuRegex.

> 
> > Code has been provided, only to be
> > shot down which chants of "can't it be done another way?" and "that's evil"
> > and "who would want to do that?". So point me to the dunking chair, i'll sit
> > down and buckle myself in... i acknowledge you win, but you are still wrong.
> 
> Certainly there's somebody who advocates GOTO in Euphoria who could provide
> an example of where a GOTO would significantly improve a Euphoria program's
> performance. Pretend Euphoria has GOTO right now and wow the skeptics.

Like I said in a previous post, using goto is a lot faster than function calls.

Not that I'm advocating the abandonment of making function calls. But you did
ask what could be faster.

Real life examples that could be made faster? Uhm, any tall recursive function
such as factorial(). Just one example.

>  
> (Just today I reworked some of my BBCMF code and had it serving up pages in
> HALF the time it was taking before! *pats self on back* Without GOTO, even.)
> 
> Remember, I'm talking about Euphoria. The goto in C has been shown to be
> beneficial to Euphoria. Great. But adding GOTO to Euphoria would be
> beneficial... how?

Speed of course, but there is also the improved maintainability and readability
of code (if used correctly of course).

In other languages, goto is also a good way to break out of nested loops and/or
if statements. But with labeled loops, that issue is not relevant. (How to break
out of a nested if statement? Surround it with a while loop, and add an 'exit'
right before the 'end while' line! Nice hack, eh?)

135. Re: voting on GOTO

• Posted by "Euler German" <eulerg at gmail.com> Jun 06, 2008
• 805 views

> On 5 Jun 2008 at 15:28, Derek Parnell wrote (maybe snipped):

> posted by: Derek Parnell <ddparnell at bigpo??.com>
> 
> Euler German wrote:
> 
> > Just to add that there are times when I really miss a DO CASE case
> > this ... case that ... other[wise] ... END CASE construct. But I can
> > wait. :)
> 
> 
> This construct has been implemented in v4.0 and I'm doing some
> extensive testing with it. It works very well and makes code look a
> lot cleaner. eg.
> 
>    switch upper(SOMEVAL) do
>        case "ME":
>        case "MYSELF":
>        case "I":
>               foo()
>               exit
> 
>        case "YOU":
>        case "THEM":
>              bar()              
>              -- fall thru
> 
>        case "HE":
>        case "SHE":
>              qwerty()
>             exit
> 
>        case else:
>              default()
> 
>     end switch
> 
That's what I was talking about! Job well done guys. You have my 
endless sympathy. :)

And though "else case" sounds a bit weird I can live with that. ;)

-- 
_
_| euler f german
_| sete lagoas, mg, brazil
_| efgerman{AT}gmail{DOT}com

137. Re: voting on GOTO

• Posted by Jeremy Cowgar <jeremy at ?owga?.com> Jun 06, 2008
• 811 views

gshingles wrote:
>  
> As for built-in or dll, I think the decision has well and truly been made on
> that issue, but if in future it was decided to split it out, I would suggest
> at least the maintenance of a builtin binary for *nix since you can usually
> get exu to run on a web host, but the host may not have the .so.
> 

Built-in vs. dll was made for distribution purposes and also supporting dos.
regular expressions work fine in the dos version of eu4.0. So, you know now that
if it's 4.0, it has regular expressions. No possible missing dll/so, mismatch,
etc... I bet that regular expressions will become one of the most widely used new
features of 4.0.

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

139. Re: voting on GOTO

• Posted by Chris Bensler <eu at cre?tivep?rtal.ca> Jun 06, 2008
• 789 views

Euler German wrote:
> 
> > On 5 Jun 2008 at 15:28, Derek Parnell wrote (maybe snipped):
> 
> > posted by: Derek Parnell <ddparnell at bigpo??.com>
> > 
> > Euler German wrote:
> > 
> > > Just to add that there are times when I really miss a DO CASE case
> > > this ... case that ... other[wise] ... END CASE construct. But I can
> > > wait. :)
> > 
> > 
> > This construct has been implemented in v4.0 and I'm doing some
> > extensive testing with it. It works very well and makes code look a
> > lot cleaner. eg.
> > 
> >    switch upper(SOMEVAL) do
> >        case "ME":
> >        case "MYSELF":
> >        case "I":
> >               foo()
> >               exit
> > 
> >        case "YOU":
> >        case "THEM":
> >              bar()              
> >              -- fall thru
> > 
> >        case "HE":
> >        case "SHE":
> >              qwerty()
> >             exit
> > 
> >        case else:
> >              default()
> > 
> >     end switch
> > 
> That's what I was talking about! Job well done guys. You have my 
> endless sympathy. :)
> 
> And though "else case" sounds a bit weird I can live with that. ;)
> 
> -- 
> _
> _| euler f german
> _| sete lagoas, mg, brazil
> _| efgerman{AT}gmail{DOT}com
> 
> 

'case else' disambiguates from if/else

Chris Bensler
Code is Alchemy

141. Re: voting on GOTO

• Posted by c.k.lester <euphoric at cklest??.com> Jun 06, 2008
• 799 views

Kat wrote:
> 
> Duh,, Euphoria doesn't have goto.

Quoting myself since you missed it (or failed reading comprehension):
I asked for examples where GOTO would help streamline or otherwise make a
Euphoria program better.

Basically, pretend GOTO is already there, then show me some functions where
GOTO would speed up the code.

> > Pretend Euphoria has GOTO right now and wow the skeptics.
> Pretend it's been done, pretend it was done in the PCRE/euPRC thread you were
> talking on.

The burden of proof is not on me. It's up to the GOTO advocates to show how
having GOTO will benefit the language.

143. Re: voting on GOTO

• Posted by Kat <KAT12 at coosahs?n?t> Jun 06, 2008
• 811 views

c.k.lester wrote:
> 
> Kat wrote:
> > 
> > Duh,, Euphoria doesn't have goto.
> 
> Quoting myself since you missed it (or failed reading comprehension):
> I asked for examples where GOTO would help streamline or otherwise make a
> Euphoria program better.

That's not a quote.

> Basically, pretend GOTO is already there, then show me some functions where
> GOTO would speed up the code.
> 
> > > Pretend Euphoria has GOTO right now and wow the skeptics.
> > Pretend it's been done, pretend it was done in the PCRE/euPRC thread you
> > were
> > talking on.
> 
> The burden of proof is not on me. It's up to the GOTO advocates to show how
> having GOTO will benefit the language.

CK, talking to you stopped being productive *at all* yesterday. So far today, no
one has gotten thru to you. You can't even carry a thought from talking to one
person to talking to the next. Hell, let me quote myself: "So point me to the
dunking chair, i'll sit down and buckle myself in... i acknowledge you win, but
you are still wrong."

Kat

145. Re: voting on GOTO

• Posted by Jim Brown <jbrown105 at linu?bud?hist.net> Jun 06, 2008
• 821 views

c.k.lester wrote:
> 
> > > Pretend Euphoria has GOTO right now and wow the skeptics.
> > Pretend it's been done, pretend it was done in the PCRE/euPRC thread you
> > were
> > talking on.
> 
> The burden of proof is not on me. It's up to the GOTO advocates to show how
> having GOTO will benefit the language.

At the same time, while admitting the burden of proof might not be as strong, it
would be great for those against GOTO to give solid evidence on how adding it
would be bad for the language. Not just vague remarks about "spagetthi code" and
the like.

147. Re: voting on GOTO

• Posted by Chris Bensler <eu at creativ?p?rtal.ca> Jun 06, 2008
• 804 views

Jim Brown wrote:
> 
> c.k.lester wrote:
> > 
> > > > Pretend Euphoria has GOTO right now and wow the skeptics.
> > > Pretend it's been done, pretend it was done in the PCRE/euPRC thread you
> > > were
> > > talking on.
> > 
> > The burden of proof is not on me. It's up to the GOTO advocates to show how
> > having GOTO will benefit the language.
> 
> At the same time, while admitting the burden of proof might not be as strong,
> it would be great for those against GOTO to give solid evidence on how adding
> it would be bad for the language. Not just vague remarks about "spagetthi
> code"
> and the like.

Fear of abuse is paranoia and a weak argument. There are much more valid reasons
against goto, such as uncertain code flow.

Chris Bensler
Code is Alchemy

149. Re: voting on GOTO

• Posted by Kat <KAT12 at ?oo?ahs.net> Jun 06, 2008
• 796 views

c.k.lester wrote:
> 
> Jim Brown wrote:
> > 
> > 9,999,999 function calls is about 2 seconds. 99,999,999 gotos is <1 second.
> 
> While that kicks total butt, I have to wonder who calls a function almost
> 10 million times? Just curious. I'm sure Kat with her processing of gigabytes
> of text probably makes use of some lines of code many many times... Kat?

Sure, i can answer that one. HE SHOWED YOU A 10:1 SPEEDUP USING GOTO IN EUPHORIA
CODE.

I needed goto so i could write code that simulated a for nest 85 levels deep, or
recursion that went further deep than MAXINT in mirc or Eu or TurboPascal. Goto
in that case allowed me to NOT overflow the stack or heap, EVEN ON THE C64. But
the code would not run on Eu or TP, both crash with this or that errors. I can do
it in mirc, but mirc's  r e a l l y  slow at some things. It was yrs ago, i don't
know where the code is now. I do remember the "85" because it was a task
performed on a sentence with 85 english words in it, counting punctuation, the
longest sentence i could find at the time.

Kat

151. Re: voting on GOTO

• Posted by Jeremy Cowgar <jeremy at cow??r.com> Jun 06, 2008
• 786 views

c.k.lester wrote:
> 
> What I'm saying is, if it's going to take some astronomical number of
> iterations to show a slight improvement, then it's probably not worth
> adding to the core, because nobody's going to call a function that many
> times.
> 

Slight improvement? His code showed more than twice as fast! Slight improvement
is the 2-4% you asked for.

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

153. Re: voting on GOTO

• Posted by Greg Haberek <ghaberek at gmai??com> Jun 06, 2008
• 793 views

Matt Lewis wrote:
> 
> Greg Haberek wrote:
> > 
> > There seem to be several chunks of PCRE-related code scattered around
> > the SVN trunk, some C, some Euphoria. Nothing I've looked at thus far
> > has expressed a need for GOTO. Perhaps you could point me in the right
> > direction?
> 
> matt@oneill:~/euphoria/dev/rds/source/pcre$ grep -c goto *c | grep -v \:0
> pcre_compile.c:96
> pcre_dfa_exec.c:9
> pcre_exec.c:28

So the C code needs it... let the C code have it!!! Just compile that into the
Interpreter back-end. Isn't that what you're already doing? Are most (if not
*all*) the things the Interpreter does actually implemented in the C back-end? I
would imagine it'd be the *fastest* and *simplest* route to implementing PCRE.
Why bother re-writing it in Euphoria? Then you'll have to re-re-write it every
time there's an update (or hunt down the updates to the PRCE code and implement
them individually) if you'd like to maintain that the code is fresh and stable.

As much as I respect you as a programmer, Matt, I find this a moot argument for
GOTO.

-Greg

155. Re: voting on GOTO

• Posted by Matt Lewis <matthewwalkerlewis at gm?il?com> Jun 06, 2008
• 807 views

Greg Haberek wrote:
> 
> Matt Lewis wrote:
> > 
> > Greg Haberek wrote:
> > > 
> > > There seem to be several chunks of PCRE-related code scattered around
> > > the SVN trunk, some C, some Euphoria. Nothing I've looked at thus far
> > > has expressed a need for GOTO. Perhaps you could point me in the right
> > > direction?
> > 
> > matt@oneill:~/euphoria/dev/rds/source/pcre$ grep -c goto *c | grep -v \:0
> > pcre_compile.c:96
> > pcre_dfa_exec.c:9
> > pcre_exec.c:28
> 
> So the C code needs it... let the C code have it!!! Just compile that
> into the Interpreter back-end. Isn't that what you're already doing? Are
> most (if not *all*) the things the Interpreter does actually implemented
> in the C back-end? I would imagine it'd be the *fastest* and *simplest*
> route to implementing PCRE. Why bother re-writing it in Euphoria? Then
> you'll have to re-re-write it every time there's an update (or hunt down
> the updates to the PRCE code and implement them individually) if you'd
> like to maintain that the code is fresh and stable.
> 
> As much as I respect you as a programmer, Matt, I find this a moot argument
> for GOTO.

Huh?  You asked a question and I answered it.  No one is saying that we 
should port PCRE instead of putting it into the interpreter (well, maybe 
Bernie).

I don't understand what's so hard about this argument (which multiple people
have gotten wrong, BTW--I'm addressing all of you here).  For the sake of 
argument, let's pretend that the letters P, C, R and E were never typed in 
that order.

The question was, when is goto a useful thing, over and above what you
can do with other structures that euphoria has.  I answered, "It can be
very useful when porting code from other languages that might have goto
or other features that aren't easily handled by what euphoria has."
I then gave my previous, failed attempt at doing just that with PCRE, to
show that it wasn't completely theoretical.

You [in the generic sense] are free to disagree with the need for goto.  
You are not free to think that this argument has anything to do with the 
decision to include PCRE into euphoria, and that including it has any
bearing on the debate about goto.  It was simply an example of some useful
code that couldn't be easily made into a native euphoria port.

Now, you could ask, "Why bother to port it?  Why not just wrap the shared
library?"  And my answer would be:  it's easier to distribute euphoria code
with a euphoria app than to deal with additional dependencies.  And if 
the performance is acceptable, then it's a plus.  And it's not going to be
possible or desirable to put every useful library into the interpreter.

Matt

157. Re: voting on GOTO

• Posted by Chris Bensler <eu at cre?tivepo?tal.ca> Jun 06, 2008
• 801 views

After careful reconsideration, I retract my no vote and choose to abstain.

I cannot with honesty find enough reason to disallow this feature.
The construct is low-level enough to be exceptional from Eu's principles of
top-down processing and strict syntax and does offer new freedom to the
programmer to express their intentions in a way that is easiest for them
(regardless if it is a good choice, it should be theirs), which is the important
thing.

Chris Bensler
Code is Alchemy

159. Re: voting on GOTO

• Posted by Hermans <joseph.hermans at ?ando?a.be> Jun 06, 2008
• 808 views

I vote YES because of speed and also because the tricks used to avoid 'goto' are
IMO just as bad or even worse than 'goto' itself.
About readability: it's all a matter of getting used to. About maintainability:
every program without proper remarks is always bad to maintain.

161. Re: voting on GOTO

• Posted by Igor Kachan <kinz at peterlink??u> Jun 06, 2008
• 828 views

I vote NO to GOTO.

--
Igor

163. Re: voting on GOTO

• Posted by Lucius L. Hilley III <euphoria at unkma?.com> Jun 06, 2008
• 814 views

Euler German wrote:
> 
> > On 5 Jun 2008 at 20:20, Chris Bensler wrote (maybe snipped):
> 
> > 
> > posted by: Chris Bensler <eu at cre?tivep?rtal.ca>
> > 
> > Euler German wrote:
> > > 
> > > > On 5 Jun 2008 at 15:28, Derek Parnell wrote (maybe snipped):
> > > 
> > > > posted by: Derek Parnell <ddparnell at bigpo??.com>
> > > > 
> > > > Euler German wrote:
> > > > 
> > > > > Just to add that there are times when I really miss a DO CASE
> > > > > case this ... case that ... other[wise] ... END CASE construct.
> > > > > But I can wait. :)
> > > > 
> > > > 
> > > > This construct has been implemented in v4.0 and I'm doing some
> > > > extensive testing with it. It works very well and makes code look
> > > > a lot cleaner. eg.
> > > > 
> > > >    switch upper(SOMEVAL) do
> > > >        case "ME":
> > > >        case "MYSELF":
> > > >        case "I":
> > > >               foo()
> > > >               exit
> > > > 
> > > >        case "YOU":
> > > >        case "THEM":
> > > >              bar()              
> > > >              -- fall thru
> > > > 
> > > >        case "HE":
> > > >        case "SHE":
> > > >              qwerty()
> > > >             exit
> > > > 
> > > >        case else:
> > > >              default()
> > > > 
> > > >     end switch
> > > > 
> > > That's what I was talking about! Job well done guys. You have my
> > > endless sympathy. :)
> > > 
> > > And though "else case" sounds a bit weird I can live with that. ;)
> > > 
> > > -- 
> > > _
> > > _| euler f german
> > > _| sete lagoas, mg, brazil
> > > _| efgerman{AT}gmail{DOT}com
> > > 
> > > 
> > 'case else' disambiguates from if/else
> > 
> Indeed, but wouldn't "otherwise" make it even better? I mean, the 
> only place you can expect "else" is on if ... end if constructs. But 
> this is me.
> 
> -- 
> _
> _| euler f german
> _| sete lagoas, mg, brazil
> _| efgerman{AT}gmail{DOT}com
> 
> 

Sure, lets just keep adding keywords to accomplish the task instead
of reorganizing the current ones in an elegant and explanatory way.

After all, how many keywords does euphoria need before it simply
scares newbies to death?  Wow, I thought we were going for sexy and
simple.

    Lucius L. Hilley III - Unkmar

165. Re: voting on GOTO

• Posted by Jeremy Cowgar <jeremy at cowg??.com> Jun 07, 2008
• 810 views

Peter Robinson wrote:
>  
> By block I was including loops, conditionals, procedures and functions. They
> share a common context (in a logical sense, I'm not talking about what happens
> in the interpreter), so you may want to jump within them. I don't include the
> file-level in this, since being within the same file may not involve any
> contextual
> connection. I modularise by keeping within context, which may or may not
> correspond
> with the language's implementation of scope.
> 

Many small utilities are a single file w/their body as the main file, for
instance, this simple "cat" command written as euphoria:

sequence cmds, lines
lines = read_file(cmds[3])
for a = 1 to length(lines) do
    puts(1, lines[a])
end for

That's a pretty silly way of doing things, but, that is the *entire* application
and it's all at the file level. I doubt that you would use goto at the file level
if your application is contained in functions:

procedure display_file(sequence filename)
    sequence lines
    lines = read_file(filename)
    for a = 1 to length(lines) do
        puts(1, lines[a])
    end for
end procedure

procedure main()
    sequence cmds
    display_file(cmds[3])
end procedure

main()

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

167. Re: voting on GOTO

• Posted by David Stevenson <ff16 at ?ts.ne?> Jun 07, 2008
• 813 views

No

169. Re: voting on GOTO

• Posted by CChris <christian.cuvier at a?riculture.g?uv.fr> Jun 07, 2008
• 798 views

Euler German wrote:
> 
> > On 6 Jun 2008 at 10:38, Lucius L. Hilley III wrote (maybe snipped):
> 
> > Sure, lets just keep adding keywords to accomplish the task instead of
> > reorganizing the current ones in an elegant and explanatory way.
> > 
> > After all, how many keywords does euphoria need before it simply
> > scares newbies to death?  Wow, I thought we were going for sexy and
> > simple.
> > 
> >     Lucius L. Hilley III - Unkmar
> > 
> 
> Keywords don't scare newbies. Dogmas do. Why I'm not amazed this 
> community didn't grow in more than 5 years? Maybe I should quote 
> David Cuny (I hope you don't mind, David): "...I'm not sure that my 
> hopes for Euphoria match most of those using it." and also of his 
> brew: "I wrote my pre-processor and Py as examples of what I thought 
> Euphoria could become. They ended up looking a lot like Python  Lua. 
> I'm not sure my idea of Euphoria would make many current users 
> happy."
> 

Exactly why it's by sheer luck I'm still around.

CChris

> Who's scaring who? And David Cuny is certainly NOT a newbie. ;)
> 
> -- 
> _
> _| euler f german
> _| sete lagoas, mg, brazil
> _| efgerman{AT}gmail{DOT}com
> 
>

171. Re: voting on GOTO

• Posted by Jim Brown <jbrown105 at linux??ddhist.net> Jun 07, 2008
• 783 views

The poll closes at 18 for, 13 against, and 4 abstaining.

Robert Craig wrote:
> 
> Jim Brown wrote:
> > 
> > Ok, the poll shall continue.
> > 
> > Is Saturday (06/07/08) 17:00 UTC agreeable to everyone?
> 
> Fair enough.
> I'll state that on the RapidEuphoria main page.
> I assume UTC and GMT are the same thing.
> EUforum shows times in GMT.
> 
> Regards,
>    Rob Craig
>    Rapid Deployment Software
>    <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>

173. Re: voting on GOTO

• Posted by Kat <KAT12 at coos?h?.net> Jun 09, 2008
• 802 views

Robert Craig wrote:
> 
> Jim Brown wrote:
> > The poll closes at 18 for, 13 against, and 4 abstaining.
> > 
> > Robert Craig wrote:
> > > 
> > > Jim Brown wrote:
> > > > 
> > > > Ok, the poll shall continue.
> > > > 
> > > > Is Saturday (06/07/08) 17:00 UTC agreeable to everyone?
> > > 
> > > Fair enough.
> > > I'll state that on the RapidEuphoria main page.
> > > I assume UTC and GMT are the same thing.
> > > EUforum shows times in GMT.
> 
> OK.
> You now have a mandate to proceed with a GOTO statement.
> Thanks for being patient.

You're welcome. 


Kat