Re: GOTO (warning: A long response follows)
One of the main purposes of a Programming Language is to make programs
understood by people. That is to say, the primary audience of a program
source code file is a person rather than a computer. Its the job of the
compiler/interpreter to make the same program understood by the computer.
If this is true, then the language should be structured so that the
program's intent and behaviour are easily understood by reading the source
code. It should also make it hard to write bugs and, paradoxically, easy
to find bugs. When a programming language supports an unfetted GOTO, it
breaks the goals mentioned above.
A piece of code containing a GOTO often becomes ambiguous because the true
intent is masked by the mechanics of a logic-flow jump. For example, in
the recent discussion, a GOTO has been suggested as a suitable way to
prematurely exit a loop construct. But when using a GOTO, one may become
unsure if the author's real intent was to jump to a specific named
location or just to exit the loop. The difference lies in whether or not
one can insert code between the end of the loop construct and the named
location without introducing a bug.
The program's behaviour also becomes harder to determine if one cannot be
sure of the logic paths used to reach any given line of code. This
phenomena gives rise to the term "spaghetti code" because the logic paths
become so intertwined that it starts to resemble a bowl of spaghetti.
This effect also is one of the larger sources of bugs. Simply put, the
more potential logic flows then more complex the software, and the more
complex the software, the easier it is to create mistakes (and harder to
find them).
More thought needs to be invested into making a programming language's
syntax more capable of expressing the author's intent. A side effect of
this is that compilers and interpreters can introduce more effective
run-time optimisations, if they can "see" what the author was really
trying to achieve.
But back to the GOTO discussion...
It seems that everyone feels that there is a need for a premature exit
from a loop construct. Some also feel that we need to be able to
prematurely start the next iteration of a loop. I'd also like to add the
possibility of restarting a loop and restarting the current iteration of a
loop. In each of these situations, I suspect that we would do this when
some exception condition occurred. That is, the body of the loop would
handle the normal conditions, but one or more exceptional conditions would
trigger the premature exit/next/restart/retry behaviour.
Could I suggest that these four new keywords be added to the Euphoria
language to express the author's intent.
Further, if these keywords could have optional modifiers that identified
which loop construct to act on, it would be even more useful to the
author. This implies that we need to be able to uniquely identify loop
constructs. Either Mark's or Everett's syntax would be sufficient for
this. It would be important that the loop's id would only be scoped to the
loop itself, that is no code outside the loop could reference the loop's
id.
example.
while:Customer x = 1 do
while:Order y = 2 do
while:Line z = 3 do
...
if condition1 then next:Line
if condition2 then exit:Order
...
end while
...
if condition3 then next:Customer
end while
...
end while
While I support the minimalist philosophy of Euphoria (I just love Forth),
it must be weighed against the usablility of the language (this is where
Forth fails us too). Some happy medium must exist.
cheers,
Derek Parnell
Melbourne, Australia
|
Not Categorized, Please Help
|
|
