OpenEuphoria

1. Good Use of GOTO

• Posted by c.k.lester <euphoric at cklester.c??> Jun 05, 2008
• 873 views
• Last edited Jun 06, 2008

After hearing from both sides, I've come to the conclusion that the goto
being implemented is unnecessary. We are getting loop constructs that
handle most of what GOTO would be used for, aren't we?

   continue, exit, retry, etc...

These all lend themselves to maintenance, program flow, structure, while a
GOTO does not.

Can somebody show me a case (with sample code) where a GOTO would be
significantly better than using another construct? Also, please explain
why Euphoria would need GOTO if we add PCRE to the interpreter.

3. Re: Good Use of GOTO

• Posted by Jim Brown <jbrown105 at linuxbuddhi?t.?et> Jun 05, 2008
• 868 views
• Last edited Jun 06, 2008

c.k.lester wrote:
> 
> After hearing from both sides, I've come to the conclusion that the goto
> being implemented is unnecessary. We are getting loop constructs that
> handle most of what GOTO would be used for, aren't we?
> 
>    continue, exit, retry, etc...
> 
> These all lend themselves to maintenance, program flow, structure, while a
> GOTO does not.
> 
> Can somebody show me a case (with sample code) where a GOTO would be
> significantly better than using another construct? Also, please explain
> why Euphoria would need GOTO if we add PCRE to the interpreter.

How would you implement/rewrite the following functions (from Linux kernel
2.6.11 source) ? Even if you had the full repretiore of eu 4.0 keywords? (which,
admittedly, the author of this code did not have)

static struct dentry *vfat_lookup(struct inode *dir, struct dentry *dentry,
                                  struct nameidata *nd)
{       
        int res;
        struct vfat_slot_info sinfo;
        struct inode *inode;
        struct dentry *alias;
        struct buffer_head *bh = NULL
        struct msdos_dir_entry *de;
        int table;

        lock_kernel();
        table = (MSDOS_SB(dir->i_sb)->options.name_check == 's') ? 2 : 0;
        dentry->d_op = &vfat_dentry_ops[table];

        inode = NULL;
        res = vfat_find(dir, &dentry->d_name, &sinfo, &bh, &de);
        if (res < 0) {
                table++;
                goto error;
        }
        inode = fat_build_inode(dir->i_sb, de, sinfo.i_pos, &res);
        brelse(bh);        if (res) {
                unlock_kernel();
                return ERR_PTR(res);
        }
        alias = d_find_alias(inode);
        if (alias) {
                if (d_invalidate(alias) == 0)
                        dput(alias);
                else {  
                        iput(inode);
                        unlock_kernel();
                        return alias;
                }
        
        }
error:  
        unlock_kernel();
        dentry->d_op = &vfat_dentry_ops[table];
        dentry->d_time = dentry->d_parent->d_inode->i_version;
        dentry = d_splice_alias(inode, dentry);               
        if (dentry) {                                         
                dentry->d_op = &vfat_dentry_ops[table];
                dentry->d_time = dentry->d_parent->d_inode->i_version;
        }
        return dentry;
}

static int vfat_create(struct inode *dir, struct dentry *dentry, int mode,
                       struct nameidata *nd)
{
        struct super_block *sb = dir->i_sb;
        struct inode *inode = NULL;
        struct buffer_head *bh = NULL;
        struct msdos_dir_entry *de;
        struct vfat_slot_info sinfo;
        int res;

        lock_kernel();
        res = vfat_add_entry(dir, &dentry->d_name, 0, &sinfo, &bh, &de);
        if (res < 0)
                goto out;
        inode = fat_build_inode(sb, de, sinfo.i_pos, &res);
        brelse(bh);
        if (!inode)
                goto out;
        res = 0;
        inode->i_mtime = inode->i_atime = inode->i_ctime = CURRENT_TIME_SEC;
        mark_inode_dirty(inode);
        inode->i_version++;
        dir->i_version++;
        dentry->d_time = dentry->d_parent->d_inode->i_version;
        d_instantiate(dentry, inode);
out:
        unlock_kernel();
        return res;
}

static int vfat_build_slots(struct inode *dir, const unsigned char *name,
                            int len, struct msdos_dir_slot *ds,
                            int *slots, int is_dir)
{       
        struct msdos_sb_info *sbi = MSDOS_SB(dir->i_sb);
        struct fat_mount_options *opts = &sbi->options;
        struct msdos_dir_slot *ps;
        struct msdos_dir_entry *de;
        unsigned long page;
        unsigned char cksum, lcase;
        unsigned char msdos_name[MSDOS_NAME];
        wchar_t *uname;
        int res, slot, ulen, usize, i;
        loff_t offset;

        *slots = 0;
        res = vfat_valid_longname(name, len);
        if (res)
                return res;

        page = __get_free_page(GFP_KERNEL);
        if (!page)
                return -ENOMEM;                               

        uname = (wchar_t *)page;
        res = xlate_to_uni(name, len, (unsigned char *)uname, &ulen, &usize,
                           opts->unicode_xlate, opts->utf8, sbi->nls_io);
        if (res < 0)
                goto out_free;
        
        res = vfat_is_used_badchars(uname, ulen);
        if (res < 0) 
                goto out_free;
        
        res = vfat_create_shortname(dir, sbi->nls_disk, uname, ulen,
                                    msdos_name, &lcase);
        if (res < 0) 
                goto out_free;
        else if (res == 1) { 
                de = (struct msdos_dir_entry *)ds;
                res = 0;
                goto shortname;                               
        }                                                     

        /* build the entry of long file name */
        *slots = usize / 13;
        for (cksum = i = 0; i < 11; i++)
                cksum = (((cksum&1)<<7)|((cksum&0xfe)>>1)) + msdos_name[i];
        
        for (ps = ds, slot = *slots; slot > 0; slot--, ps++) {
                ps->id = slot;
                ps->attr = ATTR_EXT;
                ps->reserved = 0;
                ps->alias_checksum = cksum;
                ps->start = 0; 
                offset = (slot - 1) * 13;
                fatwchar_to16(ps->name0_4, uname + offset, 5);
                fatwchar_to16(ps->name5_10, uname + offset + 5, 6);
                fatwchar_to16(ps->name11_12, uname + offset + 11, 2);
        }
        ds[0].id |= 0x40;
        de = (struct msdos_dir_entry *)ps;

shortname: 
        /* build the entry of 8.3 alias name */
        (*slots)++;
        memcpy(de->name, msdos_name, MSDOS_NAME);
        de->attr = is_dir ? ATTR_DIR : ATTR_ARCH;
        de->lcase = lcase;
        de->adate = de->cdate = de->date = 0;
        de->ctime = de->time = 0;
        de->ctime_ms = 0;
        de->start = 0;
        de->starthi = 0;
        de->size = 0;

out_free:
        free_page(page);
        return res;
}

5. Re: Good Use of GOTO

• Posted by Bernie Ryan <xotron at ?luefrog.c?m> Jun 05, 2008
• 860 views
• Last edited Jun 06, 2008

Jim Brown wrote:
> 
> c.k.lester wrote:
> > 
> > After hearing from both sides, I've come to the conclusion that the goto
> > being implemented is unnecessary. We are getting loop constructs that
> > handle most of what GOTO would be used for, aren't we?
> > 
> >    continue, exit, retry, etc...
> > 
> > These all lend themselves to maintenance, program flow, structure, while a
> > GOTO does not.
> > 
> > Can somebody show me a case (with sample code) where a GOTO would be
> > significantly better than using another construct? Also, please explain
> > why Euphoria would need GOTO if we add PCRE to the interpreter.
> 
> How would you implement/rewrite the following functions (from Linux kernel
> 2.6.11
> source) ? Even if you had the full repretiore of eu 4.0 keywords? (which,
> admittedly,
> the author of this code did not have)
> 
> static struct dentry *vfat_lookup(struct inode *dir, struct dentry *dentry,
>                                   struct nameidata *nd)
> {       
>         int res;
>         struct vfat_slot_info sinfo;
>         struct inode *inode;
>         struct dentry *alias;
>         struct buffer_head *bh = NULL
>         struct msdos_dir_entry *de;
>         int table;
> 
>         lock_kernel();
>         table = (MSDOS_SB(dir->i_sb)->options.name_check == 's') ? 2 : 0;
>         dentry->d_op = &vfat_dentry_ops[table];
> 
>         inode = NULL;
>         res = vfat_find(dir, &dentry->d_name, &sinfo, &bh, &de);
>         if (res < 0) {
>                 table++;
>                 goto error;
>         }
>         inode = fat_build_inode(dir->i_sb, de, sinfo.i_pos, &res);
>         brelse(bh);        if (res) {
>                 unlock_kernel();
>                 return ERR_PTR(res);
>         }
>         alias = d_find_alias(inode);
>         if (alias) {
>                 if (d_invalidate(alias) == 0)
>                         dput(alias);
>                 else {  
>                         iput(inode);
>                         unlock_kernel();
>                         return alias;
>                 }
>         
>         }
> error:  
>         unlock_kernel();
>         dentry->d_op = &vfat_dentry_ops[table];
>         dentry->d_time = dentry->d_parent->d_inode->i_version;
>         dentry = d_splice_alias(inode, dentry);               
>         if (dentry) {                                         
>                 dentry->d_op = &vfat_dentry_ops[table];
>                 dentry->d_time = dentry->d_parent->d_inode->i_version;
>         }
>         return dentry;
> }
> 
> static int vfat_create(struct inode *dir, struct dentry *dentry, int mode,
>                        struct nameidata *nd)
> {
>         struct super_block *sb = dir->i_sb;
>         struct inode *inode = NULL;
>         struct buffer_head *bh = NULL;
>         struct msdos_dir_entry *de;
>         struct vfat_slot_info sinfo;
>         int res;
> 
>         lock_kernel();
>         res = vfat_add_entry(dir, &dentry->d_name, 0, &sinfo, &bh, &de);
>         if (res < 0)
>                 goto out;
>         inode = fat_build_inode(sb, de, sinfo.i_pos, &res);
>         brelse(bh);
>         if (!inode)
>                 goto out;
>         res = 0;
>         inode->i_mtime = inode->i_atime = inode->i_ctime = CURRENT_TIME_SEC;
>         mark_inode_dirty(inode);
>         inode->i_version++;
>         dir->i_version++;
>         dentry->d_time = dentry->d_parent->d_inode->i_version;
>         d_instantiate(dentry, inode);
> out:
>         unlock_kernel();
>         return res;
> }
> 
> static int vfat_build_slots(struct inode *dir, const unsigned char *name,
>                             int len, struct msdos_dir_slot *ds,
>                             int *slots, int is_dir)
> {       
>         struct msdos_sb_info *sbi = MSDOS_SB(dir->i_sb);
>         struct fat_mount_options *opts = &sbi->options;
>         struct msdos_dir_slot *ps;
>         struct msdos_dir_entry *de;
>         unsigned long page;
>         unsigned char cksum, lcase;
>         unsigned char msdos_name[MSDOS_NAME];
>         wchar_t *uname;
>         int res, slot, ulen, usize, i;
>         loff_t offset;
> 
>         *slots = 0;
>         res = vfat_valid_longname(name, len);
>         if (res)
>                 return res;
> 
>         page = __get_free_page(GFP_KERNEL);
>         if (!page)
>                 return -ENOMEM;                               
> 
>         uname = (wchar_t *)page;
>         res = xlate_to_uni(name, len, (unsigned char *)uname, &ulen, &usize,
>                            opts->unicode_xlate, opts->utf8, sbi->nls_io);
>         if (res < 0)
>                 goto out_free;
>         
>         res = vfat_is_used_badchars(uname, ulen);
>         if (res < 0) 
>                 goto out_free;
>         
>         res = vfat_create_shortname(dir, sbi->nls_disk, uname, ulen,
>                                     msdos_name, &lcase);
>         if (res < 0) 
>                 goto out_free;
>         else if (res == 1) { 
>                 de = (struct msdos_dir_entry *)ds;
>                 res = 0;
>                 goto shortname;                               
>         }                                                     
> 
>         /* build the entry of long file name */
>         *slots = usize / 13;
>         for (cksum = i = 0; i < 11; i++)
>                 cksum = (((cksum&1)<<7)|((cksum&0xfe)>>1)) + msdos_name[i];
>         
>         for (ps = ds, slot = *slots; slot > 0; slot--, ps++) {
>                 ps->id = slot;
>                 ps->attr = ATTR_EXT;
>                 ps->reserved = 0;
>                 ps->alias_checksum = cksum;
>                 ps->start = 0; 
>                 offset = (slot - 1) * 13;
>                 fatwchar_to16(ps->name0_4, uname + offset, 5);
>                 fatwchar_to16(ps->name5_10, uname + offset + 5, 6);
>                 fatwchar_to16(ps->name11_12, uname + offset + 11, 2);
>         }
>         ds[0].id |= 0x40;
>         de = (struct msdos_dir_entry *)ps;
> 
> shortname: 
>         /* build the entry of 8.3 alias name */
>         (*slots)++;
>         memcpy(de->name, msdos_name, MSDOS_NAME);
>         de->attr = is_dir ? ATTR_DIR : ATTR_ARCH;
>         de->lcase = lcase;
>         de->adate = de->cdate = de->date = 0;
>         de->ctime = de->time = 0;
>         de->ctime_ms = 0;
>         de->start = 0;
>         de->starthi = 0;
>         de->size = 0;
> 
> out_free:
>         free_page(page);
>         return res;
> }

Jim:

    Why can't any of these GOTO's be replaced by calls to functions ? 


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

7. Re: Good Use of GOTO

• Posted by Jim Brown <jbrown105 at l?nuxbuddhi?t.net> Jun 05, 2008
• 839 views
• Last edited Jun 06, 2008

Bernie Ryan wrote:
> 
> Jim:
> 
>     Why can't any of these GOTO's be replaced by calls to functions ? 
> 

Because they are making the main function return? How would you have a function
return, not to its caller, but its caller's caller?

Also, the need to pass arguments to helper functions via the stack is lightly
slower. In most cases one probably doesn't care about that.

> 
> Bernie
>

9. Re: Good Use of GOTO

• Posted by Jim Brown <jbrown105 at linuxbudd?ist.?et> Jun 05, 2008
• 850 views
• Last edited Jun 06, 2008

Bernie Ryan wrote:
> 
> Jim Brown wrote:
> > Because they are making the main function return? How would you have a
> > function
> > return, not to its caller, but its caller's caller?
> > 
> > Also, the need to pass arguments to helper functions via the stack is
> > lightly
> > slower. In most cases one probably doesn't care about that.
> 
> First this is poor example to answer CK's original question.

It is not. He wanted an example where goto was used to enhance maintainability
of the code.

The code in the example is clear and easy to follow, and easy to maintain.

> 
> We don't write Linux Kernel code in Euphoria.
> 

I wasn't saying we would, or should.

> You can always pass arguments and pointers. If you want speed use

Pass arguments as pointers, you mean?

Passing all arguments as pointers still takes up space and time through the
stack.

A single pointer might be better. But that adds considerable compleixty to
extract the arguments.

Also, you do not address my point to you, that the goto's are harder to replace
with function calls because they return from the main function.

> 
> assembler.    

So you have no problems with Euphoria being as slow as Java or Python, or even
slower? If so, that's fine.

> 
> Bernie
> 
> My files in archive:
> WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API 
> 
> Can be downloaded here:
> <a
> href="http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan">http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan</a>

11. Re: Good Use of GOTO

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

Jim Brown wrote:
> How would you implement/rewrite the following functions (from Linux kernel
> 2.6.11
> source) ?

Why would I need to? I don't know what the code is so I'm asking if
implementing/rewriting in Euphoria is necessary or if there are other options.

13. Re: Good Use of GOTO

• Posted by c.k.lester <euphoric at ckles??r.com> Jun 06, 2008
• 859 views

Michael J. Sabal wrote:
> c.k.lester wrote:
> >    continue, exit, retry, etc...
> I thought the whole point of introducing GOTO was so as not to litter the 
> language with all these extra keywords.  I vote to keep GOTO and get rid
> of all the other words (except exit, for legacy's sake).

GOTO is a poor substitute for these other words.

for t=1 to 10 next
  if a then
    continue
  else
    -- code
  end if
end for

In the above very simple example, which nobody should ever use but it is
analogous to something more complicated, the continue tells the interpreter
to resume the loop... meaning, it knows to increment t then goto the top and
resume execution.

How would you use GOTO there?

for t=1 to 10 next
  if a then
    goto...?
  else
    -- code
  end if
end for

In all the cases of continue, retry, exit, the interpreter and programmer
are constantly aware of code structure and flow. With GOTO, you have to
resort to contortions to do the same thing that these simple words allow.

In the example above, no matter where you GOTO, your loop var will not
increment... without extra [cumbersome] code.

15. Re: Good Use of GOTO

• Posted by c.k.lester <euphoric at ckles?er?com> Jun 06, 2008
• 831 views

Jim Brown wrote:
> c.k.lester wrote:
> > Also, please explain
> > why Euphoria would need GOTO if we add PCRE to the interpreter.
> I concede this point. I would have prefered a version of EuPCRE which wouldn't
> have a stack limitation for recursive pcre expressiosn.

Ah. Okay, so with PCRE in the interpreter, GOTO isn't needed, but to have
created a wrapper lib for it (?), GOTO would have been nice to have...?

17. Re: Good Use of GOTO

• Posted by Jeremy Cowgar <jeremy at cowga?.co?> Jun 06, 2008
• 844 views

c.k.lester wrote:
> 
> After hearing from both sides, I've come to the conclusion that the goto
> being implemented is unnecessary. We are getting loop constructs that
> handle most of what GOTO would be used for, aren't we?
> 

Instead of hashing this all out again and again, I'm going to point to a few
resources by people who know what they are doing and please, if you are really
interested in the debate, take the time to read them. Do not just assume you've
been taught and shown a few instances where goto is evil, therefore goto is evil.
You will see references to the 1968 paper everyone loves to quote (or mis-quote)
you will also see references from people such as Linus, Don Knuth and others.

http://c2.com/cgi/wiki?GoodUseOfGoto
http://kerneltrap.org/node/553/2131
http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=177764
http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.apdv.sql.doc/doc/c0024356.htm
http://www.cprogramming.com/tutorial/goto.html

Please note that the above examples are in languages that have goto. I obviously
could not find examples/talk of how goto is good/bad in Euphoria because it does
not have it.

Also note, I am simply submitting these links to the public for them to read. In
this instance, I am not fighting for or against goto, I am just providing a few
links that show goto may not always be evil because there are a few well
publicized links say it is. When making a decision it's always good to be
informed of both choices.

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

19. Re: Good Use of GOTO

• Posted by Jim Brown <jbrown105 at linuxbuddh?st.?et> Jun 06, 2008
• 834 views

c.k.lester wrote:
> 
> Jim Brown wrote:
> > How would you implement/rewrite the following functions (from Linux kernel
> > 2.6.11
> > source) ?
> 
> Why would I need to? I don't know what the code is so I'm asking if
> implementing/rewriting in Euphoria is necessary or if there are other options.

These functions serve as an example where you get the speed benefits of goto
plus good maintainability from goto.

You may not need those particular functions implemented in euphoria (in fact,
you probably never will), but that style of coding might be helpful one day when
writing your own speed critical routines in euphoria.

21. Re: Good Use of GOTO

• Posted by Kat <KAT12 at c??sahs.net> Jun 06, 2008
• 847 views

c.k.lester wrote:
> 
> Michael J. Sabal wrote:
> > c.k.lester wrote:
> > >    continue, exit, retry, etc...
> > I thought the whole point of introducing GOTO was so as not to litter the 
> > language with all these extra keywords.  I vote to keep GOTO and get rid
> > of all the other words (except exit, for legacy's sake).
> 
> GOTO is a poor substitute for these other words.
> 
> for t=1 to 10 next
>   if a then
>     continue
>   else
>     -- code
>   end if
> end for
> 
> In the above very simple example, which nobody should ever use but it is
> analogous to something more complicated, the continue tells the interpreter
> to resume the loop... meaning, it knows to increment t then goto the top and
> resume execution.

Continue where? Now when i see a for loop, i haveto be concerned that somewhere,
someone may have put in a "continue", or perhaps a "retry", and come back up to
the top of the loop in a most UN-NATURAL way, making the loop var either what it
should be, or something else! Or WORSE, and "entry" keyword! Now i haveto scan
for those words when reading, always in the back of my head, that they will cause
some program flow that is not within the promised for-next-endfor loop. And don't
get me started on "exit" which works differently for procedures, while-loops, and
for-loops! The difficulty in maintaining this garbage is going to be
astronomical, and i want to know who is going to keep up orphaned code like that,
because it certainly won't be me!
 
> How would you use GOTO there?
> 
> for t=1 to 10 next
>   if a then
>     goto...?
>   else
>     -- code
>   end if
> end for
> 
> In all the cases of continue, retry, exit, the interpreter and programmer
> are constantly aware of code structure and flow. With GOTO, you have to
> resort to contortions to do the same thing that these simple words allow.
>
> In the example above, no matter where you GOTO, your loop var will not
> increment... without extra [cumbersome] code.

OMG, you mean like:

t += 1 
or 
t -= 1

How horrific! The sight of such makes me light headed, i swear. If i could only
tell you how many times in the past i have had to inc a var when i wanted it
inc'd, and those vars had no clue of my intentions unless i typed it out in plain
text for all the freaking world to see, it just breaks my heart to see new
programmers making explicit code, or :labels, or continue(+2), or retries(-1),
or,,, or such, and not hiding the changes they have made to loop vars in using
new keywords. Thanks for pointing this out, CK!

Kat

23. Re: Good Use of GOTO

• Posted by Jason Gade <jaygade at ?ahoo.?om> Jun 06, 2008
• 836 views

Michael J. Sabal wrote:
> 
> c.k.lester wrote:
> > 
> > After hearing from both sides, I've come to the conclusion that the goto
> > being implemented is unnecessary. We are getting loop constructs that
> > handle most of what GOTO would be used for, aren't we?
> > 
> >    continue, exit, retry, etc...
> > 
> 
> I thought the whole point of introducing GOTO was so as not to litter the 
> language with all these extra keywords.  I vote to keep GOTO and get rid
> of all the other words (except exit, for legacy's sake).

Well, I like exit and continue. retry and entry? Not so much.

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

25. Re: Good Use of GOTO

• Posted by c.k.lester <euphoric at cklest?r.c?m> Jun 06, 2008
• 855 views

Kat wrote:
> c.k.lester wrote:
> > Michael J. Sabal wrote:
> > > c.k.lester wrote:
> > > >    continue, exit, retry, etc...
> > > I thought the whole point of introducing GOTO was so as not to litter the 
> > > language with all these extra keywords.
> > GOTO is a poor substitute for these other words.
> > 
> > for t=1 to 10 next
> >   if a then
> >     continue
> >   else
> >     -- code
> >   end if
> > end for
> > 
> > In the above very simple example, which nobody should ever use but it is
> > analogous to something more complicated, the continue tells the interpreter
> > to resume the loop... meaning, it knows to increment t then goto the top and
> > resume execution.
> 
> Continue where?

Continue says, "Continue the loop at the next iteration."

GOTO says nothing comprehensible.

In cases where you have imbedded loops, I would hope one could make use of
the loop var...

for a=1 to z do
  for b=a to y do
    if x then
      continue b -- early loop iteration
    else
      continue a -- early loop iteration
    end if
end for -- regular loop iteration

> > In the example above, no matter where you GOTO, your loop var will not
> > increment... without extra [cumbersome] code.
> 
> OMG, you mean like:
> 
> t += 1 
> or 
> t -= 1
> 
> How horrific!

Hey, we agree on something!

27. Re: Good Use of GOTO

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

c.k.lester wrote:
> 
> Okay, thanks for speaking up Matt. Now, if Euphoria had GOTO, you could
> have ported PCRE, but from what I've heard that implementation would have
> been drastically slower than merging PCRE into the interpreter. Isn't that
> true?
>

<snip>
 
> But wasn't the current solution found to be superior? Putting the C code
> directly into the interpreter for an extra 150K seemed to be the best way
> and, thus, was chosen.

CK... None of that is at all revelent. The fact is easy. PCRE developers found
goto superior to other constructs which they had available to them in C, which
are the same constructs we have available to us in Euphoria (for, while, if).

Why should a euphoria developer not have that ability? Please answer that
question. The standard library in regular expressions (which is no simple task to
parse/match) that has had hundreds of developers contribute to, that has been
included in almost any instance where regular expressions are used. Those
developers (again who are no dummies) decided that goto was far superior. Please
tell me why a euphoria developer should not also have that ability?

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

29. Re: Good Use of GOTO

• Posted by Kat <KAT12 at co?sahs?net> Jun 06, 2008
• 831 views

c.k.lester wrote:
> 
> Matt Lewis wrote:
> > c.k.lester wrote:
> > > And why, if PCRE is going to be merged into the interpreter (I might not
> > > have
> > > that idea correct), then why the Euphoria language would need a GOTO.
> > I was the one who initially brought this up.  A year or two ago, I started
> > working on porting PCRE to euphoria.  I had to do some really ugly things
> > to work around the use of goto.  Obviously, no one is going to try to port
> > PCRE when it's already a part of euphoria.
> 
> Okay, thanks for speaking up Matt. Now, if Euphoria had GOTO, you could
> have ported PCRE, but from what I've heard that implementation would have
> been drastically slower than merging PCRE into the interpreter. Isn't that
> true?
> 
> > It was meant as an example where the lack of goto made it difficult to
> > impossible to get something done.
> 
> But wasn't the current solution found to be superior? Putting the C code
> directly into the interpreter for an extra 150K seemed to be the best way
> and, thus, was chosen.

Yea, Matt, stop putting facts into the issue. Any code that has goto in it,
don't wrap it, put it right into the Euphoria core.

Kat

31. Re: Good Use of GOTO

• Posted by Jason Gade <jaygade at yah?o.c?m> Jun 06, 2008
• 841 views

Actually, that while is probably unnecessary.  I think I had started with "while
res >= 0 do" but then changed it. I needed to make sure that both res < 0 and a
null alias fell through to the error code.

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

33. Re: Good Use of GOTO

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

Jason Gade wrote:
> 
> Okay, so it's three functions. Here's the second:
> 

Hm, do you think the nested if's are easier to understand? The first using goto
was much easier to understand and see the code flow, imho.

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

35. Re: Good Use of GOTO

• Posted by Jason Gade <jaygade at ?ahoo?com> Jun 06, 2008
• 844 views

Jeremy Cowgar wrote:
> 
> Jason Gade wrote:
> > 
> > Okay, so it's three functions. Here's the second:
> > 
> 
> Hm, do you think the nested if's are easier to understand? The first using
> goto
> was much easier to understand and see the code flow, imho.
> 
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>

While I don't prefer goto, and will probably never use it (but never say never),
I was taking this up for the challenge more than anything else.

I don't see a clarity advantage in either one, really. The comment works as good
as a label. Heck, my comment could have been "-- goto out" and it would probably
have been more clear.

I'm sure that someone else could improve upon my code without goto.

I still can't believe I muffed the first one with the useless while...

The interesting thing is how Jim's examples are progressive -- the first
function has exactly one goto to one label which is easily replaced by an else
statement. The second function has two gotos to one label which is again
relatively easy and clear to replace, but not as much as the first. The third
function has four gotos to two labels. Still working on it.

Of course, I should be working on and testing 4.0 like I started to do last
night...

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

37. Re: Good Use of GOTO

• Posted by Chris Bensler <eu at creative?ortal.?a> Jun 06, 2008
• 850 views

Jeremy Cowgar wrote:
> 
> Without goto:
> 
> With goto:
> 

I think this is easier to understand compared to using goto.
The code flow is completely evident, whereas the use of got requires locating
the label it refers to. Of course, you could indent the goto code to show the
flow, but then why not just use nested if's?

-- still assuming that structs and pointers and refs are sequences...
function vfat_create(sequence dir_p, sequence dentry_p, integer mode, sequence
nd_p)
	sequence sb_p
	sequence inode_p
	sequence bh_p
	sequence de_p
	sequence sinfo
	integer res

	sb_p = dir_p[I_SB]
	inode_p = {}
	bh_p = {}

	lock_kernel()
	res = vfat_add_entry(dir_p, dentry_p[D_NAME], 0, sinfo, bh_p, de_p)
	if res >= 0 then
                inode = fat_build_inode(sb_p, de_p, sinfo[I_POS], res)
		brelse(bh_p)
		if length(inode) then
			res = 0
			inode_p[I_MTIME] = CURRENT_TIME_SEC
			inode_p[I_ATIME] = CURRENT_TIME_SEC
			inode_p[I_CTIME] = CURRENT_TIME_SEC
			mark_inode_dirty(inode_p)
			inode_p[I_VERSION] += 1
			dir_p[I_VERSION] += 1
			dentry_p[D_TIME] = dentry_p[D_PARENT][D_INODE][I_VERSION]
			d_instatiate(dentry_p, inode_p)
		end if
	end if
	
	-- out
	unlock_kernel()
	return res

end function

Chris Bensler
Code is Alchemy

39. Re: Good Use of GOTO

• Posted by Jason Gade <jaygade at yaho?.c?m> Jun 06, 2008
• 840 views

c.k.lester wrote:
> 
> Jeremy Cowgar wrote:
> > c.k.lester wrote:
> > > But wasn't the current solution found to be superior? Putting the C code
> > > directly into the interpreter for an extra 150K seemed to be the best way
> > > and, thus, was chosen.
> > Why should a euphoria developer not have that ability?
> 
> It has never been demonstrated that a Euphoria developer needs the ability.
> 
> GOTO is simply not needed in Euphoria. It's already blazingly fast enough
> without adding a construct like GOTO.
> 
> > Those developers (again who are no dummies) decided that goto was far
> > superior. Please tell me why a euphoria developer should not also have
> > that ability?
> 
> Because a GOTO in C might increase performance by up to 50%.
> 
> Show me similar performance benefits for Euphoria.
> 
> If you can't, then GOTO should not be added because it's just useless bloat
> and at least won't be around to trip programmers up.

Now wait a minute -- didn't you say earlier that a 2%-5% increase was sufficient
for a new feature, or was that someone else?

Regardless, you can't keep moving the bar.

goto can make for hard to understand code. Programmers should be encouraged to
find ways to write their code without it. However, in very rare cases, it can be
a useful tool.

Now, I haven't used got since the 8-bit Basic days and I don't plan on starting.
But I've seen enough good arguments to at least be neutral about it and I have
seen some instances of C code where it's probably the best choice.

Well, certainly not as many good examples as goto's partisans suggest exist, but
still.

See some of Jeremy's links above.

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

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

j.

41. Re: Good Use of GOTO

• Posted by Jim Brown <jbrown105 at linuxbudd?i?t.net> Jun 06, 2008
• 835 views

c.k.lester wrote:
> 
> Jeremy Cowgar wrote:
> > c.k.lester wrote:
> > > But wasn't the current solution found to be superior? Putting the C code
> > > directly into the interpreter for an extra 150K seemed to be the best way
> > > and, thus, was chosen.
> > Why should a euphoria developer not have that ability?
> 
> It has never been demonstrated that a Euphoria developer needs the ability.
> 

Yes it has. We just discussed one example!

> 
> > Those developers (again who are no dummies) decided that goto was far
> > superior. Please tell me why a euphoria developer should not also have
> > that ability?
> 
> Because a GOTO in C might increase performance by up to 50%.
> 
> Show me similar performance benefits for Euphoria.

This requires benchmarking. I am effectively the only person atm who has the
ability to run those benchmarks.
So this is either theoretical, or you are singling me out and asking me to
produce.
 
> If you can't, then GOTO should not be added because it's just useless bloat
> and at least won't be around to trip programmers up.
>
> GOTO is simply not needed in Euphoria. It's already blazingly fast enough
> without adding a construct like GOTO.

I disagree. I've never said that speed performance was the sole factor in adding
goto support. It certainly is a factor, and it does exist, but it is not the only
one.

43. Re: Good Use of GOTO

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

Jim Brown wrote:
> c.k.lester wrote:
> > Okay, thanks for speaking up Matt. Now, if Euphoria had GOTO, you could
> > have ported PCRE, but from what I've heard that implementation would have
> > been drastically slower than merging PCRE into the interpreter. Isn't that
> > true?
> I did not hear this. Nor do I understand why this would be the case.
> Especially
> if the translation could be done without losing goto. Please explain.

I might be confused, so let me explain where I'm coming from:

There are two ways to give Euphoria programmers access to PCRE:

1. put it into the interpreter
2. make a library that calls shared code

#1 was chosen because it would provide for faster code.

> No, the current solution was chosen because the lack of a native goto made a
> native port impossible. A native port would have been superior, if it could
> be accomplished.

I thought a native port was done (basically, you just do something like
include pcre.h in the interpreter).

45. Re: Good Use of GOTO

• Posted by c.k.lester <euphoric at ckles?e?.com> Jun 06, 2008
• 843 views

Jeremy Cowgar wrote:
> 
> 	if res < 0 then
> 		-- out
> 	else

Why do that? Why not

if res >= 0 then
  inode = fat_build_inode(sb_p, de_p, sinfo[I_POS], res)
  brelse(bh_p)
  ...
end if

Anyway, I prefer the one without the GOTOs as it's easier to parse.

In the one with GOTOs, at first glance, I would assume that all that code
is going to be called. But then I see the label "out" line. Now I have to
go back up into the code and find a GOTO (or more). This is, of course, a
simple example. I would HATE to see GOTOs in a function bigger than the
simple one you've posted.

47. Re: Good Use of GOTO

• Posted by Jim Brown <jbrown105 at linux?uddhist.n?t> Jun 06, 2008
• 840 views

c.k.lester wrote:
> 
> Anyway, I prefer the one without the GOTOs as it's easier to parse.
> 
> In the one with GOTOs, at first glance, I would assume that all that code
> is going to be called. But then I see the label "out" line. Now I have to
> go back up into the code and find a GOTO (or more). This is, of course, a
> simple example. I would HATE to see GOTOs in a function bigger than the
> simple one you've posted.

It's a matter of style. With the proper indentation, you should be able to spot
them immediately. Without it, the nested ifs are signficiantly harder to read.

Hitting Ctrl+F or otherwise using the Find/Search facility of your IDE or text
editor shouldn't be that hard either...

49. Re: Good Use of GOTO

• Posted by c.k.lester <euphoric at ck??ster.com> Jun 06, 2008
• 829 views

Derek Parnell wrote:
> c.k.lester wrote:
> > It has never been demonstrated that a Euphoria developer needs the ability.
> Here's an idea ... let's compile the definitive list of all Euphoria's
> abilities,
> then divided them into the set that developers need and the set that
> developer's
> don't need. Could be interesting, no?

hmmmmm. Do it!

> > GOTO is simply not needed in Euphoria. It's already blazingly fast enough
> > without adding a construct like GOTO.
> > Show me similar performance benefits for Euphoria.
> > 
> > If you can't, then GOTO should not be added because it's just useless bloat
> > and at least won't be around to trip programmers up.
> 
> Can this rationale be used for all of Euphoria's capabilities?

No, it can be used for all of Euphoria's potential capabilities (requested
features, etc.).

We've got a base foundation: Euphoria 3.1.1. If you want to add to that base,
you have to demonstrate that the added ability will do two of these three
things, if not all three:

1. improve execution speed
2. improve development time
3. improve maintenance time

GOTO might do #1 for Euphoria, but nobody has offered examples/benchmarks. So
we'll wait for those...

GOTO will certainly not consistently do #2 or #3.

51. Re: Good Use of GOTO

• Posted by c.k.lester <euphoric at cklester.?o?> Jun 06, 2008
• 838 views

Jim Brown wrote:
> c.k.lester wrote:
> > There are two ways to give Euphoria programmers access to PCRE:
> > 1. put it into the interpreter
> > 2. make a library that calls shared code
> > #1 was chosen because it would provide for faster code.
> Speedwise, I think if there was a difference, it would be small enough to be
> ignored.

Really? PCRE in the core would be no more faster than an include library?!

> Nope. Native port = euPCRE (PCRE written in euphoria)

Gotcha. But I still find it hard to believe that euPCRE would be as fast
as PCRE in the core.

53. Re: Good Use of GOTO

• Posted by Jeremy Cowgar <jeremy at c?wg?r.com> Jun 06, 2008
• 855 views

c.k.lester wrote:
> 
> Jeremy Cowgar wrote:
> > c.k.lester wrote:
> > > It has never been demonstrated that a Euphoria developer needs the
> > > ability.
> > CK, did you actually read any of the links I gave in a previous post?
> 
> Yes I did. None of them were convincing arguments for adding GOTO to Euphoria.
> 

Convincing to who? Others have already commented otherwise. Convincing to you?
I'm not sure a 15,000% speed increase and 98% line count reduction would convince
you.

> 
> Again, the need for benchmarking is evident. :)
>

Go ahead then and benchmark a function call. Then benchmark just the function
body inside of a for loop.
 
> 
> I kinda disagree. I think GOTO is easier to abuse. It's unstructured. You can
> use it to go anywhere from anywhere. The if/while/for/etc. is far more
> structured and you are limited to what kind of damage you can do accidentally.

Easier than an include file? For instance, you had to do a code clean up in
BBCMF due to include usage, and I'm not picking on you, it was just pretty easy
to abuse. I think therefore we should go to a monolithic structure where all code
is in one file.

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

55. Re: Good Use of GOTO

• Posted by Chris Bensler <eu at c?eati?eportal.ca> Jun 06, 2008
• 853 views

Jeremy Cowgar wrote:
> 
> c.k.lester wrote:
> > 
> > It has never been demonstrated that a Euphoria developer needs the ability.
> >
> 
> CK, did you actually read any of the links I gave in a previous post?
>  
> > > Those developers (again who are no dummies) decided that goto was far
> > > superior. Please tell me why a euphoria developer should not also have
> > > that ability?
> > 
> > Because a GOTO in C might increase performance by up to 50%.
> > 
> > Show me similar performance benefits for Euphoria.
> >
> 
> Huh? I've said 1,000 times function calls are expensive and *no one* will say
> they are not. Goto can avoid many cases of function calls in critical
> situations.
>  
> > If you can't, then GOTO should not be added because it's just useless bloat
> > and at least won't be around to trip programmers up.
> 
> Trip programmers up? Seriously, I'm kind of getting tired of playing this
> game.
> I've said a million times (not 1,000) that programmers can abuse if, while,
> for, functions, procedures, includes, etc... If a programmer is going to abuse
> goto, they have plenty of other things they will abuse as well. I think you
> are still paying attention to the document about why goto is bad that was
> published
> in 1968. Languages have changed a bit since then.
> 
> Can you please spend some time and read the links I posted previously and then
> continue to comment if you wish?
> 
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>

I've read all of those links you posted in entirety. It appears the only really
valid uses of goto discussed are for exception handling which does not halt
execution but skips instead, and for exiting nested blocks of code easily. One
other valid use I can think of is for jump tables, but I don't know if that would
be relevant in Euphoria.

The other valid argument for goto is optimization, but I have a hard time seeing
this as an issue in euphoria. Mainly because if speed is so critical, Euphoria is
probably not the right choice regardless of the use of goto.

Lastly is pure and simple convenience. IMO this is the greatest reason to
include goto. People do deserve the freedom to work in their own fashion. We
don't all think alike. The choice to add goto however is not just about what is
good for the community but what is good for the language in the long term as
well.

I've initiated a list of pro's and con's. Feel free to elaborate, comment or
criticize.

PROS:
  Ambiguous Flow Control
  Convenience of Development
  Potential for Optimization

CONS:
  Ambiguous Code Flow
  Inconvenience of Maintenance
  Potential for Abuse
  Does not Adhere to Euphoria's Top-Down Philosophy
  Complex Rules of Usage

Chris Bensler
Code is Alchemy

57. Re: Good Use of GOTO

• Posted by c.k.lester <euphoric at ck?ester.?om> Jun 06, 2008
• 837 views

Lucius L. Hilley III wrote:

> for t=1 to 10 next
>   if a then
>     goto "t_continue"
>   else
>     -- code
>   end if
>   label "t_continue"
> end for

Good job, Lucius! :) This solidifies my opinion that GOTO is unnecessary.
The example just using 'continue' is cleaner, and it's probably faster
without GOTO (one less jump?).

59. Re: Good Use of GOTO

• Posted by Jim Brown <jbrown105 at linuxbuddhist.?e?> Jun 06, 2008
• 849 views

c.k.lester wrote:
> 
> Jim Brown wrote:
> > c.k.lester wrote:
> > > There are two ways to give Euphoria programmers access to PCRE:
> > > 1. put it into the interpreter
> > > 2. make a library that calls shared code
> > > #1 was chosen because it would provide for faster code.
> > Speedwise, I think if there was a difference, it would be small enough to be
> > ignored.
> 
> Really? PCRE in the core would be no more faster than an include library?!

Um.

> > > 2. make a library that calls shared code

In other words, a dll/so.

As for parsing the include files ... what can I say. Euphoria is fast. ;)

> 
> > Nope. Native port = euPCRE (PCRE written in euphoria)
> 
> Gotcha. But I still find it hard to believe that euPCRE would be as fast
> as PCRE in the core.

Fair enough. I still feel it would at least have been more maintainable though.

61. Re: Good Use of GOTO

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

Jim Brown wrote:
> 
> Perhaps you could cite the arguments (at least the ones you feel the most
> pertaint)
> and give your counter-responses.

There are counter-arguments to all the arguments in each of those links. No
need to rehash them here... is there? I simply remain unconvinced.

> We keep hearing this, yet when CChris asked for modern examples of spagetthi
> code abuse from languages which do support goto (such as C), he got nothing.
> 
> The burden of proof is now on you to show that this is the case....

http://en.wikipedia.org/wiki/Spaghetti_code
http://www.reddit.com/info/6l7dr/comments/

I have no idea what this is saying:
http://sourcemaking.com/antipatterns/spaghetti-code

A quick search of your favorite search engine should find more.

63. Re: Good Use of GOTO

• Posted by c.k.lester <euphoric at ckle?ter.co?> Jun 06, 2008
• 833 views

Jeremy Cowgar wrote:
> c.k.lester wrote:
> > Yes I did. None of them were convincing arguments for adding GOTO to
> > Euphoria.
> Convincing to who? Others have already commented otherwise. Convincing to you?
> I'm not sure a 15,000% speed increase and 98% line count reduction would
> convince
> you.

Come on. Hyperbole? This isn't 'me' vs 'you' or 'us' vs 'them.' It's a
rational discussion on the merits of GOTO being added to the Euphoria
interpreter. Nobody's religion is in question here.

A 15,000% speed increase and 98% line count reduction would entice me, for
sure!

P.S. Not everybody was euphoric for GOTO in those links you provided. There
were many good arguments against GOTO.

> Easier than an include file? For instance, you had to do a code clean up in
> BBCMF due to include usage, and I'm not picking on you, it was just pretty
> easy
> to abuse.

Uh, no. There was no abuse. I modularized the code as Euphoria 3.x allowed.
When I switched to 4.0, there was a different mechanism and I had to adjust.
In fact, I wanted to adjust because it seems better packaged now.

> I think therefore we should go to a monolithic structure where all
> code is in one file.

I don't. :)

65. Re: Good Use of GOTO

• Posted by Jeremy Cowgar <jeremy at ?owgar.?om> Jun 06, 2008
• 810 views

Ok, here are the benchmarks you asked for CK...


[jeremy@jdesk 40goto]$ time exu ffunc.e 

real    0m2.424s
user    0m2.420s
sys     0m0.003s
[jeremy@jdesk 40goto]$ time exu fgoto.e 

real    0m1.142s
user    0m1.143s
sys     0m0.000s

The code is:

ffunc.e  (factorial function)

function factorial(atom a)
	if a < 2 then
		return a
	end if
	return a*factorial(a-1)
end function

object ign

for i = 1 to 1000000 do
	ign = factorial(20)
end for

and

fgoto.e (factorial goto)

function factorial(atom a)
	atom b 
	b = a 
	 
label "start" 
	if a <= 2 then 
		goto "end" 
	end if 
	 
	a = a - 1 
	b = b * a 
	goto "start" 
	 
label "end" 
	return b 
end function 

object ign

for i = 1 to 1000000 do
	ign = factorial(20)
end for

Now, bear in mind, this is an optimization. The non-goto version of factorial is
much simpler, but also much slower. You would only resort to a situation like
this if you have measured speed and speed was not acceptable for your situation.

Goto has been committed as a branch (not part of trunk everyone!) you can
download it, compile and run these benchmarks for yourself. The SVN repo is:

http://rapideuphoria.svn.sourceforge.net/svnroot/rapideuphoria

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

67. Re: Good Use of GOTO

• Posted by c.k.lester <euphoric at ckle?ter.c?m> Jun 06, 2008
• 832 views

Jeremy Cowgar wrote:
> 
> My hope is that at least others have seen some of the pros/cons.

We've all seen the pros/cons and formed our opinions therefrom.

69. Re: Good Use of GOTO

• Posted by Kat <KAT12 at coo?a?s.net> Jun 06, 2008
• 821 views

c.k.lester wrote:
> 
> Jeremy Cowgar wrote:
> > 
> > My hope is that at least others have seen some of the pros/cons.
> 
> We've all seen the pros/cons and formed our opinions therefrom.

No you didn't, you had them before this was brought to vote.

Kat

71. Re: Good Use of GOTO

• Posted by c.k.lester <euphoric at ck?ester?com> Jun 06, 2008
• 809 views

Kat wrote:
> 
> Fine bit of code, Chris, but not what CK asked for. CK said you can't use a
> goto in a for loop that increments the loop var and acts like a continue. Luc
> gave it to CK, and CK hasn't corrected himself yet.

Lucius proved that you can do a continue with GOTO. However,

    The example just using 'continue' is cleaner, and it's probably faster
    without GOTO (one less jump?).

73. Re: Good Use of GOTO

• Posted by c.k.lester <euphoric at ?kl?ster.com> Jun 06, 2008
• 831 views

Jeremy Cowgar wrote:
> > (You must be on a beast of a PC... I get 5.422 and 2.531 for factorial()
> > and factorial_fast().)
> Quad 4 2.4GHz 

Wooooo! That's where the real optimization is... HARDWARE! :)

75. Re: Good Use of GOTO

• Posted by c.k.lester <euphoric at c?lester.?om> Jun 06, 2008
• 841 views

Jeremy Cowgar wrote:
> c.k.lester wrote:
> > How does this compare:
> > function factorial_fast(atom a)
> > end function
> > I show similar improvement vs factorial() without the use of GOTO.
> > 
> 
> I ran it a few times.

So, my factorial_fast() runs in about 1.57s over one million
iterations. GOTO runs in about 1.42s for one million iterations.
So, the GOTO is about 10% faster, right? In this case, I would
use whatever version was in the standard lib. I personally don't have
code that iterates one million times, so it wouldn't matter.
However, 10% improvement is excellent. Alas, a difference of 0.15
seconds is not likely to be noticed by your casual human observer.

77. Re: Good Use of GOTO

• Posted by Chris Bensler <eu at creat?veportal.c?> Jun 06, 2008
• 828 views

c.k.lester wrote:
> 
> Jeremy Cowgar wrote:
> > c.k.lester wrote:
> > > How does this compare:
> > > function factorial_fast(atom a)
> > > end function
> > > I show similar improvement vs factorial() without the use of GOTO.
> > > 
> > 
> > I ran it a few times.
> 
> So, my factorial_fast() runs in about 1.57s over one million
> iterations. GOTO runs in about 1.42s for one million iterations.
> So, the GOTO is about 10% faster, right? In this case, I would
> use whatever version was in the standard lib. I personally don't have
> code that iterates one million times, so it wouldn't matter.
> However, 10% improvement is excellent. Alas, a difference of 0.15
> seconds is not likely to be noticed by your casual human observer.

I had jeremy test the following version and he stated that it was 0.006s faster
than the goto version. Admittedly very marginal, but none-the-less, we are
comparing the speed of existing euphoria against gotos in euphoria.

(Sorry for overstepping you Jeremy, but it would be unfair not to make the best
comparison to something that is being argued as being faster.)

function factorial(atom a)
 atom b   
  b = a   
   
  while 1 do
    if a <= 2 then   
      exit
    end if   
     
    a = a - 1   
    b = b * a   
  end while
  return b   
end function 

Maybe this could be made even faster, I'm no speed freak.

Chris Bensler
Code is Alchemy

79. Re: Good Use of GOTO

• Posted by Derek Parnell <ddparnell at bigpo?d.co?> Jun 06, 2008
• 808 views

Lucius L. Hilley III wrote:
> 
> c.k.lester wrote:
> > 
> > Lucius L. Hilley III wrote:
> > 
> > > for t=1 to 10 next
> > >   if a then
> > >     goto "t_continue"
> > >   else
> > >     -- code
> > >   end if
> > >   label "t_continue"
> > > end for
> > 
> > Good job, Lucius! :) This solidifies my opinion that GOTO is unnecessary.
> > The example just using 'continue' is cleaner, and it's probably faster
> > without GOTO (one less jump?).
> 
> We need goto to be able to jump out of a loop early.
> Redundant if statements are such a pain.
>   Lets add exit to avoid adding goto.
> 
> We want need goto to leap back to the beginning of a for
> loop and keep the index value the same.  We are now trying
> another approach, we changed something else.
>   Lets add retry to avoid adding goto.
> 
> We want need goto in order to proceed through a loop without
> executing any following code within the loop before starting
> the next iteration.
>   Lets add continue to avoid adding goto.
> 
> 
> MORE keywords are CLEANER than one easy to understand KEYWORD?

In this case, yes. 

The main differenmce is that the 'goto' does not tell the code reader what the
intentions of the original coder were. Whereas 'continue', 'exit', etc signal to
the reader what the coder was attempting to achieve.


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

81. Re: Good Use of GOTO

• Posted by Matt Lewis <matthewwalkerlewis at gmail??om> Jun 06, 2008
• 817 views

c.k.lester wrote:
> 
> Jeremy Cowgar wrote:
> > c.k.lester wrote:
> > > How does this compare:
> > > function factorial_fast(atom a)
> > > end function
> > > I show similar improvement vs factorial() without the use of GOTO.
> > > 
> > 
> > I ran it a few times.
> 
> So, my factorial_fast() runs in about 1.57s over one million
> iterations. GOTO runs in about 1.42s for one million iterations.
> So, the GOTO is about 10% faster, right? In this case, I would
> use whatever version was in the standard lib. I personally don't have
> code that iterates one million times, so it wouldn't matter.
> However, 10% improvement is excellent. Alas, a difference of 0.15
> seconds is not likely to be noticed by your casual human observer.

I will just say that I've had code that has had to run many many millions
of iterations.  These are basically custom optimization problems (i.e.,
find the combination such that the objective function is minimized) that
don't easily fit into standard linear/integer programming solutions.

This stuff takes hours to run, and costs money.  So any improvement is a
good thing.  And they already had inline asm for some of the really critical
bit twiddling stuff to optimize.

Matt

83. Re: Good Use of GOTO

• Posted by CChris <christian.cuvier at agriculture.g?uv?fr> Jun 06, 2008
• 843 views

Derek Parnell wrote:
> 
> c.k.lester wrote:
> > It has never been demonstrated that a Euphoria developer needs the ability.
> 
> Here's an idea ... let's compile the definitive list of all Euphoria's
> abilities,
> then divided them into the set that developers need and the set that
> developer's
> don't need. Could be interesting, no?
> 
> > GOTO is simply not needed in Euphoria. It's already blazingly fast enough
> > without adding a construct like GOTO.
> > Show me similar performance benefits for Euphoria.
> > 
> > If you can't, then GOTO should not be added because it's just useless bloat
> > and at least won't be around to trip programmers up.
> 
> Can this rationale be used for all of Euphoria's capabilities?
> 
> If <XXX> doesn't contribute to Euphoria's execution speed, then it is useless
> bloat.
> 
> -- 
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell

I would ad: which speed?

Development speed?
Source interpretation speed?
Bug squashing speed?
Educational reading speed?

And I probably forgot some more.

Excution speed is important.But the time one loses in development by not having
possibly redundant constructs to express one's vision of the code structure into
something the machine will properly translate offses by several orders of
magnitude whatever gainsin execution peed, excep in very massive work like Kat's.

So I'd say: why focus on point #2, if time is crucial, and not consider the
other, where much, much more time is involved?

CChris

85. Re: Good Use of GOTO

• Posted by CChris <christian.cuvier at a?ricult?re.gouv.fr> Jun 06, 2008
• 873 views

Derek Parnell wrote:
> 
> Lucius L. Hilley III wrote:
> > 
> > c.k.lester wrote:
> > > 
> > > Lucius L. Hilley III wrote:
> > > 
> > > > for t=1 to 10 next
> > > >   if a then
> > > >     goto "t_continue"
> > > >   else
> > > >     -- code
> > > >   end if
> > > >   label "t_continue"
> > > > end for
> > > 
> > > Good job, Lucius! :) This solidifies my opinion that GOTO is unnecessary.
> > > The example just using 'continue' is cleaner, and it's probably faster
> > > without GOTO (one less jump?).
> > 
> > We need goto to be able to jump out of a loop early.
> > Redundant if statements are such a pain.
> >   Lets add exit to avoid adding goto.
> > 
> > We want need goto to leap back to the beginning of a for
> > loop and keep the index value the same.  We are now trying
> > another approach, we changed something else.
> >   Lets add retry to avoid adding goto.
> > 
> > We want need goto in order to proceed through a loop without
> > executing any following code within the loop before starting
> > the next iteration.
> >   Lets add continue to avoid adding goto.
> > 
> > 
> > MORE keywords are CLEANER than one easy to understand KEYWORD?
> 
> In this case, yes. 
> 
> The main differenmce is that the 'goto' does not tell the code reader what the
> intentions of the original coder were. Whereas 'continue', 'exit', etc signal
> to the reader what the coder was attempting to achieve.
> 
> 
> -- 
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell

This function is to be performed by the name used in the label.

I had suggested (and implemented in Eu 2.5 source) a labelled goto with a
come_from() feature, which I thought would make development and maintainance
safer, but that hardly ever got noticed anyway.

CChris

87. Re: Good Use of GOTO

• Posted by Jason Gade <jaygade at ya?oo.co?> Jun 06, 2008
• 841 views

Lucius L. Hilley III wrote:
> 
> c.k.lester wrote:
> > 
> > Lucius L. Hilley III wrote:
> > 
> > > for t=1 to 10 next
> > >   if a then
> > >     goto "t_continue"
> > >   else
> > >     -- code
> > >   end if
> > >   label "t_continue"
> > > end for
> > 
> > Good job, Lucius! :) This solidifies my opinion that GOTO is unnecessary.
> > The example just using 'continue' is cleaner, and it's probably faster
> > without GOTO (one less jump?).
> 
> We need goto to be able to jump out of a loop early.
> Redundant if statements are such a pain.
>   Lets add exit to avoid adding goto.
> 
> We want need goto to leap back to the beginning of a for
> loop and keep the index value the same.  We are now trying
> another approach, we changed something else.
>   Lets add retry to avoid adding goto.
> 
> We want need goto in order to proceed through a loop without
> executing any following code within the loop before starting
> the next iteration.
>   Lets add continue to avoid adding goto.
> 
> 
> MORE keywords are CLEANER than one easy to understand KEYWORD?
> 
>     Lucius L. Hilley III - Unkmar

Generally, yes. Because they have context.

There is a point of diminishing returns though (no pun intended).

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

89. Re: Good Use of GOTO

• Posted by c.k.lester <euphoric at ckl?ster.c?m> Jun 06, 2008
• 828 views

jiri babor wrote:

> I am no speed freak either

jiri's just being modest. He's one of Euphoria's best speed freaks. :D

> but the following simpler version is at least twice as fast:

As I suspected, there will probably always be a way to optimize code such
that GOTO is unnecessary /for speed/.

We must now consider other "good uses" of GOTO in Euphoria:

1. porting code from languages that use GOTO
2. giving programmer's an extra tool to use if they want
3. allowing improved structure (in rare cases)

I think the strongest argument for GOTO is #1, but even that is diminished
with the integration of PCRE into the core, and the fact that code with GOTO
has been ported just fine by others in this forum. GOTO can be refactored
into structured code and still maintain its speed.

#2 is not compelling because the same can be said about pointers, etc.

Alas, there remains no good reason to include GOTO.

91. Re: Good Use of GOTO

• Posted by Jim Brown <jbrown105 at lin?xbuddhist?net> Jun 06, 2008
• 824 views

c.k.lester wrote:
> 
> Jim Brown wrote:
> > 
> > Perhaps you could cite the arguments (at least the ones you feel the most
> > pertaint)
> > and give your counter-responses.
> 
> There are counter-arguments to all the arguments in each of those links. No
> need to rehash them here... is there? I simply remain unconvinced.

I read through all three links (the fourth one i visited was some stuff about DB
and SQL...)

There were no successful counter-arguments presented. The conclusion was always
that goto was useful in making code nicer.

> 
> > We keep hearing this, yet when CChris asked for modern examples of spagetthi
> > code abuse from languages which do support goto (such as C), he got nothing.
> > 
> > The burden of proof is now on you to show that this is the case....
> 
> <a
> href="http://en.wikipedia.org/wiki/Spaghetti_code">http://en.wikipedia.org/wiki/Spaghetti_code</a>

The wikipedia link explains the concept but contains no examples (as of the time
of this posting).

> I have no idea what this is saying: <a
> href="http://sourcemaking.com/antipatterns/spaghetti-code">http://sourcemaking.com/antipatterns/spaghetti-code</a>

It appears to describe the pattern, like the wikipedia link, but again has no
real live examples.

Java spagetthi code does not require the use of GOTO, and therefore does not
count.

> <a
> href="http://www.reddit.com/info/6l7dr/comments/">http://www.reddit.com/info/6l7dr/comments/</a>
> 

This last mentions PHP spagetthi code. Like the Java example, non sequtior - it
does not apply. PHP doesn't have a goto statement.

93. Re: Good Use of GOTO

• Posted by Matt Lewis <matthewwalkerlewis at g?ail.c?m> Jun 06, 2008
• 838 views

Jason Gade wrote:
> 
> There were plenty of successful counter-arguments. It's just that neither side
> seems to be listening to the other.
> 
> I thought that the most relevant point was brought up in one of the articles
> where "if C had exception handling then you wouldn't need goto".

Of course, this assumes that exception handling is a good thing.  Also that
the performance hit typically associated with exception handling wasn't 
important.

Matt

95. Re: Good Use of GOTO

• Posted by Derek Parnell <ddparnell at b?gp?nd.com> Jun 06, 2008
• 840 views

Kat wrote:

> I gave code for that also. It involved:
> goto exit
> goto retry
> goto restart
> goto next
> goto cleanup&return
> etc.
> 
> The only way that's not clear is if you don't read english.

For example:

   ----- fileA.e ----
   function qwerty( integer b)
   integer a
   a = b
   label start:
   if a < 10 then
     a = foo(b)
     if a < 0 then
        goto exit  -- Which exit does this go to?
     end if
     b = bar(a)
     goto start    -- which start?
   end if
   label exit:

   label start:
   a = 5
   while a < 10 do
     a = bar(b)
     if a < 0 then
        goto exit
     end if
     b = foo(a)
     foto start
   end if
   label exit:

   return a
   end function

Oh hang on, all labels in the scope must be unique. So now I have to numbering?
them.

   function qwerty( integer b)
   integer a
   a = b
   label start:
   if a < 10 then
     a = foo(b)
     if a < 0 then
        goto exit
     end if
     b = bar(a)
     goto start
   end if
   label exit:

   label start1:
   a = 5
   if a < 10 do
     a = bar(b)
     if a < 0 then
        goto exit1
     end if
     b = foo(a)
     goto start1
   end if
   label exit1:

   return a
   end function

So now not only do I have more to type and more to read I also have to create
unique label names.

Then we've got this sort of problem....

   a = b
   label exit:
   if a < 10 then
     a = foo(b)
     if a < 0 then
        goto start
     end if
     b = bar(a)
     goto exit
   end if
   label start:

Identical syntax from Euphoria's point of view, but very misleading for humans
to read. Yes, I know is a silly example but the point is that it is possible to
use label names that are actually misleading in terms of informing the reader
about the coder's intentions.


The solution we have chosen is this ...

   function qwerty( integer b)
   integer a
   a = b

   while a < 10 do
     a = foo(b)
     if a < 0 then
        exit
     end if
     b = bar(a)
   end while

   a = 5
   while a < 10 do
     a = bar(b)
     if a < 0 then
        exit
     end if
     b = foo(a)
   end while

   return a
   end function

There is no misleading control flow statements now. They are shorter. They
inform you of the coder's intentions. And this is already in Euphoria 3.1


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

97. Re: Good Use of GOTO

• Posted by Jeremy Cowgar <jeremy at cowgar.co?> Jun 06, 2008
• 850 views

c.k.lester wrote:
> 
> So, while I initially thought Kat's solution was pretty good, I now find it
> would be cumbersome to maintain, especially in the context of a large
> program like EuSQL, wxEuphoria, Win32Lib, or BBCMF.
>

What about a large program like the one I maintain that I would like to use
goto's in?

I want to know, how is goto, if never used in your application, going to hurt
you? I have shown you how goto is going to dramatically help me and others. I
have shown you example output code of the euphoria to c translator and applied it
to my situation.

Please, do not say that the added maintence costs of Euphoria because it's not. 
The initial development is the time consuming part. I'll bet the while code has
not been touched in a long, long time because it has not changed. Please do not
say because the interpeter is bloated, because it's not and if you want to fight
what you call bloat, there are many more other areas to cut there.

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

99. Re: Good Use of GOTO

• Posted by Kat <KAT12 at co?sahs.?et> Jun 06, 2008
• 836 views

Derek Parnell wrote:
> 
> Kat wrote:
> 
> > I gave code for that also. It involved:
> > goto exit
> > goto retry
> > goto restart
> > goto next
> > goto cleanup&return
> > etc.
> > 
> > The only way that's not clear is if you don't read english.
> 
> For example:
> 
>    ----- fileA.e ----
>    function qwerty( integer b)
>    integer a
>    a = b
>    label start:
>    if a < 10 then
>      a = foo(b)
>      if a < 0 then
>         goto exit  -- Which exit does this go to?
>      end if
>      b = bar(a)
>      goto start    -- which start?
>    end if
>    label exit:
> 
>    label start:
>    a = 5
>    while a < 10 do
>      a = bar(b)
>      if a < 0 then
>         goto exit
>      end if
>      b = foo(a)
>      foto start
>    end if
>    label exit:
> 
>    return a
>    end function
> 
> Oh hang on, all labels in the scope must be unique. So now I have to
> numbering?
> them.
> 
>    function qwerty( integer b)
>    integer a
>    a = b
>    label start:
>    if a < 10 then
>      a = foo(b)
>      if a < 0 then
>         goto exit
>      end if
>      b = bar(a)
>      goto start
>    end if
>    label exit:
> 
>    label start1:
>    a = 5
>    if a < 10 do
>      a = bar(b)
>      if a < 0 then
>         goto exit1
>      end if
>      b = foo(a)
>      goto start1
>    end if
>    label exit1:
> 
>    return a
>    end function
> 
> So now not only do I have more to type and more to read I also have to create
> unique label names. 
> 
> Then we've got this sort of problem....
> 
>    a = b
>    label exit:
>    if a < 10 then
>      a = foo(b)
>      if a < 0 then
>         goto start
>      end if
>      b = bar(a)
>      goto exit
>    end if
>    label start:
> 
> Identical syntax from Euphoria's point of view, but very misleading for humans
> to read. Yes, I know is a silly example but the point is that it is possible
> to use label names that are actually misleading in terms of informing the
> reader
> about the coder's intentions.
> 
> 
> The solution we have chosen is this ...
> 
>    function qwerty( integer b)
>    integer a
>    a = b
> 
>    while a < 10 do
>      a = foo(b)
>      if a < 0 then
>         exit
>      end if
>      b = bar(a)
>    end while
> 
>    a = 5
>    while a < 10 do
>      a = bar(b)
>      if a < 0 then
>         exit
>      end if
>      b = foo(a)
>    end while
> 
>    return a
>    end function
> 
> There is no misleading control flow statements now. They are shorter. They
> inform
> you of the coder's intentions. And this is already in Euphoria 3.1

Yeas, sure if you are going to intentionally screw things up. 
meuw miaow miaol maol miaol raoul moew mewl moew mew moul miaow rowl reul reu
miao merou?
 miaow meul maouw moau merow rewl maouw rewl rew moew reul miaow meul
 miao mowl merow miao reu merw riaow
 merou. Merou maou rowl
 rew maou moau meul rowr mewl meow rew moew meow mewl
 miaow merw mew merw
 mew reu rowr meuw rowl moul merow maouw miaow miao merou maol
reul moul raoul merw meuw meul miao mew rowl meuw meow rewl miaow moew reu meuw
 meow merw rowr rowl
 maol rowr moau merow miaow riaow meul maol moul merou?
 maou meow moew maou miaow
 miao merw mowl rewl miaow miaol rew meow merw meul moul rowr maol merw miaow
miaow mew merou mowl merow rewl maol miaow moul meul miao riaow mowl maol moul
 riaow meow moau rowl
 moau raoul miaow moul moew merow moew rew riaow
 rew meow maou miaow moul
miaow miaol miaow moau miaow maouw meul miaow meul mewl moul meuw meul moul
 rewl merw mewl riaow
 merou merow maou miaol maouw
 reu moul rew moul meow moau rowr moau rowr mew moew reu maou moew rewl?
 miaow merou meul
raoul merow mowl miao maou mew rowr miaow raoul moul reu miao raoul reul rowr
 maol meow rewl
 mowl rowr mew rew
mewl miao meow merw miaow moul merou rew maouw reul riaow miaol reu rew miaow
 rew

Kat

101. Re: Good Use of GOTO

• Posted by don cole <doncole at pacb?ll.n?t> Jun 06, 2008
• 865 views
• Last edited Jun 07, 2008

Kat wrote:
> 

<Snip>

> Yeas, sure if you are going to intentionally screw things up. 
> meuw miaow miaol maol miaol raoul moew mewl moew mew moul miaow rowl reul reu
> miao merou?
>  miaow meul maouw moau merow rewl maouw rewl rew moew reul miaow meul
>  miao mowl merow miao reu merw riaow
>  merou. Merou maou rowl
>  rew maou moau meul rowr mewl meow rew moew meow mewl
>  miaow merw mew merw
>  mew reu rowr meuw rowl moul merow maouw miaow miao merou maol
>  reul moul raoul merw meuw meul miao mew rowl meuw meow rewl miaow moew reu
> meuw meow merw rowr rowl
>  maol rowr moau merow miaow riaow meul maol moul merou?
>  maou meow moew maou miaow
>  miao merw mowl rewl miaow miaol rew meow merw meul moul rowr maol merw miaow
>  miaow mew merou mowl merow rewl maol miaow moul meul miao riaow mowl maol
>  moul
> riaow meow moau rowl
>  moau raoul miaow moul moew merow moew rew riaow
>  rew meow maou miaow moul
>  miaow miaol miaow moau miaow maouw meul miaow meul mewl moul meuw meul moul
> rewl merw mewl riaow
>  merou merow maou miaol maouw
>  reu moul rew moul meow moau rowr moau rowr mew moew reu maou moew rewl?
>  miaow merou meul
>  raoul merow mowl miao maou mew rowr miaow raoul moul reu miao raoul reul rowr
> maol meow rewl
>  mowl rowr mew rew
>  mewl miao meow merw miaow moul merou rew maouw reul riaow miaol reu rew miaow
> rew
> 
> Kat


   This is the Kat's meow?

Don Cole