1. [GEN] gotos revisited yet again
<rant mode>
I can see both the pros and the cons to the infamous goto statement. Exits,
loops, returns, elsifs, and the like are already a form of goto in a controlled
state. But when you get into nested statements seven or ten levels deep, getting
back to the first or second level can be a nightmare. I've seen people argue
against a goto statement, but in the same sentence argue for a named exit. That
seems a bit contradictory to me.
Our mission critical software package is written in Business Basic. Many of the
programs which use goto statements are more spagettified than Pasta Blitz (a
popular restaurant around these parts). And this was done by highly paid
professional consultants. The potential for abuse even by good programmers is
enormous.
But it seems to me, all these arguments aside, that the biggest problem with
implementing a goto statement is *not* the goto statement. The biggest problem
is how to tell the program where to go. Put a label in the program and goto it,
you say? So what data type is the label? Is it a routine? A variable? A
comment? A keyword? Oh, boy, we need an entirely new symbol table just for
labels. Okay. Assume for a moment that adding a new symbol table is not the
troublesome task that it is. Now, what happens if we goto a label outside the
current routine? Do we return an error message? Do we go ahead an goto it come
what may? What if the label is in a different file? Now we get into the
namespace issue.
What if we say, let's limit the scope of a label to the routine it's contained
in. Well, that would make it easier, but then we'd have to have yet another
run-time error check to make sure we're in scope. Force the labels to be static
like routine names, and perhaps we could move the checking to compile time.
Now what symbology do we use for labels? How does that affect the parser? We
could use :label: in the first column of a line. But what happens if the label
is in the middle of a multi-line statement? Syntax error, of course. But what
do we do with labels just before and end or elsif? Are they part of the if or
part of the else? Can we now jump from an if to an else inside the same routine?
And you thought adding a goto would be such a simple thing.... 
</end rant mode>
Michael J. Sabal
2. [GEN] gotos revisited yet again
Mike Sabal wrote:
> So what data type is the label?
A 'goto' is a statement, not a data type.
> Assume for a moment that adding a new
> symbol table is not the troublesome task
> that it is.
Hrm? I don't see how it's a "troublesome task"; it's typically fairly simple
to implement.
> What if we say, let's limit the scope of a
> label to the routine it's contained in.
> Well, that would make it easier, but then
> we'd have to have yet another run-time error
> check to make sure we're in scope.
No, not really. At the end of the scope (routine, module, whatever), just
check to see if the label has been resolved. If not, generate an error. So
the resolution is at compile time.
Robert already does similar checks if you declare a variable, but never
assign it. In comparison, this is trivial.
> Now what symbology do we use for labels?
Why is this so difficult? The syntax:
label:
is well accepted; there's no need to invent something new.
> But what do we do with labels just before
> and end or elsif? Are they part of the
> if or part of the else? Can we now jump from
> an if to an else inside the same routine?
I hate to say it, but this looks more like FUD than a reasoned argument
against gotos. To hear you tell it, this is all uncharted territory. But
just look at any of the major languages that implement gotos: C, Basic, etc.
Virtually every question has a trivial (and tested) answer.
You seem to imply that the goto 'breaks' Yet consider the 'include'
statement. You can't place it in a loop or a routine:
-- no can do!
for i = 1 to 10 do
include file.e
end for
and despite the rule that Euphoria ignores white space, you can't write:
include
myfile.e
>From a 'how do we add it to the grammar' point of view, I don't see any
serious issues.
-- David Cuny
