OpenEuphoria

RE: fixed windows

• Posted by kbochert at copper.net Aug 06, 2003
• 406 views

On 6 Aug 2003 at 11:27, Peter Willems wrote:

> 
> > goto has nothing to do with speed. Its sole purpose is to express
> > control flow  in a clearer way. 
> 
>     How can you express control in a clearer way then without goto.
>     I'm realy curious, maybe you can give an example.
>
Its very difficult to spell out actual code because it is quite rare
and tends to occur only in complex code.
As an example, a bytecode interpreter (EU's for instance), consists of
a while statement that contains a switch statement with maybe 200 cases.
Many of these are a page long (even when written with macros!) and
contain additional structures.
When, inside a for, inside a switch, inside a  while, on page 36, I see
    if ( x != 0 )
        goto type_error;
I know immediately the programmers intentions.
It is as clear, concise and meaningful as 'get_cnt();'
would be.
The structured equvalent:
    if ( x != 0 ) {
        type_error = TRUE;
        break;
        }
Is more wordy, uses data-coupling (does anyone else
modify type_error?) and sprinkles error handling code
through-out the code. (Each nested loop checks the flag)

If I need to know what happens on type_error, it is
located in a single place.
Replace 50 'goto type_error's; and 'goto range_error;'s'
with the equivalent flags and structured code is a mess.
A compiler back end is very complex. It can be structured
to put the complexity in in-line code, or in macros, or in
objects, or in structures, but it remains hard to grasp.
The best solution always seems to be to handle some
of the detail with data structures, some with careful code
structure, some with macros, and some with a few
well-chosen goto's.  (A C++ programmer would probably
add templates, classes etc. to that list).

I will admit that since adding goto to Bach, I have found not a
single case where I have wanted to use it. (But then I haven't
written a complex program with Bach, either)

> > When misused, it has great potential to
> > obfuscate code, but when well used it can clarify the designers 
> > intentions.
> 
>     Again, I can't see how the designers intentions would be
>     better clarified my means of using goto. In my little corner
>     of the programming universe, the developers intentions are
>     made visible by means of inline documentation... lot's of it 
>
>     And again, an example would be appreciated.

I have far too often seen complex code which is so well
clarified with sometimes incorrect comments, that only a few
lines of code remained on each page. This was just barely
acceptable when the code was correct, intolerable if it had
bugs. (Its also very! hard to erase a comment )
In-line comments can be invaluable, but they can also be a trap.
In-line comments that recapitulate the code are an abuse.

goto's can be easily abused, but in my experience, 
incorrect comments and mis-indenting are far more serious
problems.

I think that Dijkstra has scared programmers enough that
they use goto verrry carefully.

Thats a lot of opinion, held for (I think) non-trivial reasons.
I care greatly about the clarity of code ( I rank it above
correctness! ) and my experience and taste tell me that goto
is  useful in a few cases.

Karl Bochert