Re: Goto (Was Re: Open Source)
Kat wrote:
>
> Juergen Luethje wrote:
> >
> > Me wrote:
> >
> > > Pete Lomax wrote:
> > >
> > > > Juergen Luethje wrote:
> > > > >
> > > > > This whole discussion is not logical for me. Someone asks for
> > > > > intrducing
> > > > > GOTO into Euphoria, and other people make suggestions how to limit the
> > > > > damage then.
> > > > > The first question should be: Why does someone want GOTO, and exactly
> > > > > _for what purposes_? I'm pretty sure then we can find more appropriate
> > > > > constructs for the desired purposes -- high level constructs for the
> > > > > high level language Euphoria.
> > > > >
> > > > Since you ask, I would say to translate a working program written in
> > > > another
> > > > language to Eu.
> > >
> > > This is a concrete reason which provides a solid basis for discussing,
> > > thanks.
> > >
> > > > As I recently said, I am not advocating goto, just not standing
> > > > against it. Here is one case you probably already saw:
> > > >
> > > > int parse()
> > > > {
> > > > Token tok;
> > > >
> > > > reading:
> > > > tok = gettoken();
> > > > if (tok == END)
> > > > return ACCEPT;
> > > > shifting:
> > > > if (shift(tok))
> > > > goto reading;
> > > > reducing:
> > > > if (reduce(tok))
> > > > goto shifting;
> > > > return ERROR;
> > > > }
> > >
> > > If I didn't make a mistake, this translates to the following Eu program:
> > > }}}
<eucode>
> > > procedure foo ()
> > > Token tok
> > >
> > > while 1 do
> > > -- reading
> > > tok = gettoken()
> > > if tok = END then
> > > return ACCEPT
> > > end if
> > >
> > > while 1 do
> > > -- shifting
> > > if shift(tok) then
> > > exit
> > > end if
> > > -- reducing
> > > if not reduce(tok) then
> > > return ERROR
> > > end if
> > > end while
> > > end while
> > > end procedure
> > > </eucode>
{{{
> >
> > Must of course be 'function', not 'procedure'.
> >
> > I actually would prefer to write the code this way:
> > }}}
<eucode>
> > function foo ()
> > Token tok
> >
> > tok = gettoken()
> > while tok != END do
> > while not shift(tok) do
> > if not reduce(tok) then
> > return ERROR
> > end if
> > end while
> > tok = gettoken()
> > end while
> > return ACCEPT
> > end function
> > </eucode>
{{{
> >
> > Now this is short and pretty clear. Without using GOTO, the structure of
> > the program (2 nested loops) is directly visible. So the "nature" of the
> > program can be understood immediately and intuitively.
>
>
> Not me.
> So i can assume you'll go with this construct and we'll never get a goto.
>
> Kat
>
> > Regards,
> > Juergen
Simple examples like this always convert nicely. "hello world" programs almost
always look simple in any language. Then real programming comes in and makes a
difference.
Compiler writers will tell you that they need programs to be written using high
level constructs, because this makes verifying code correctness simply possible.
And a vast class of problems indeed doesn't need goto, so you'll see plenty of
examples taken from that area which "prove" that you can do without goto in even
very complicated algorithms - but well chosen -.
They have an extra point in that less many random branch instructions allow
optimising CPU register use, since some repeated assignments can be dealt with by
using the right register once and moving the now invariant instruction out of a
loop, for greater efficiency.
Additionally, it is true that, in theory, you can almost always do without goto
indeed. The cases you cannot are too close to machine level tweaking to be
handled by anything else than assembly language. This powerful argument is also
used to discourage using goto, since - ALLEGEDLY - too many people use it in
cases a high level construct would do as well, or even better, leading straight
to the lair of the dreaded Spaghetti Ness monster.
Personally, I have hardly ever seen such code. Perhaps because it's a Basic
specific disease and I hardly ever looked at Basic code except for ripping
constants out of them. While I can understand that students may be tempted to use
goto and not learn the necessarily more complex higher level syntax. this
argument loses its value past the classroom door. This spaghetti thing is really
crying for a wolf who is no longer there. And as I said, bad/hard to maintain
code hardly survives anyway, so why care?
Many - certainly not all - programming problems use a finite automaton model and
logic. Such problems are described by a list of:
if state is this, then do that and change to that state.
transition rules. goto is the natural thing to use then. When things start being
a little complex, translating to loops is hazardous, and you wind up with a ton
of flags which have to be kept in sync. This is a thriving nest of bugs, and
usually not easy to hit.
For this kind of programming task, using goto will avoid a lot of bugs because
there won't be a huge distorsion between the coder's view of the problem and the
code itself. Some code optimisations will be lost. The resulting program will
have a more convoluted flow, but obfuscating further by loops that have no
equivalent in the task description doesn't make it any easier to understand. In
that framework, code using goto will be actually easier to maintain.
As I said in earlier posts, I usually need goto mostly to exit loops and if
blocks. goto inside a select ... case statement would be useful too - after all,
that's how the Eu VM works. I'd consider it more as a useful development tool,
while its use in released code should be kept to a minimum, or to zero with the
addition of more flow control structures/instructions than we currently have.
CChris
|
Not Categorized, Please Help
|
|
