Loop iterator - example.txt

[Derek Parnell]

On Sun, 30 Apr 2006 20:06:34 -0700, Walter Bright wrote:

> Derek Parnell wrote:
>> The use of 'goto' has an inherinent cost in terms of ongoing maintenance 
>> of code. 

...

>> I'm not sure if there are any other situations it is cost-justified.
 
> A goto is also useful:

Thanks Walter. I don't want to take up any of your time so feel free to
ignore this response.

I just want to repeat that my concern with the use of 'goto' and labels is
that they add to the cost of maintaining source code. If that cost can be
justified or offset by something else then fine. Otherwise just don't do
it.

> 1) to avoid excessive diffs caused by refactoring code

If by 'refactoring' code you mean reorganizing it so that its structure is
improved then I don't see how adding 'goto' is going to achieve that. But
even if it did, is the ongoing cost of cosmetic 'goto' statements worth the
once-off cost of a manually review of a large diff due to lots of code
movement? If it is then fine, use goto, otherwise suck it up and get on
with improving the source code for future maintainers.

> 2) when one wants to build a control structure that just doesn't fit 
> into the usual if-else, while, for, etc.

This is a common excuse for goto usage. But again if the special structure
is justified in terms of ongoing maintenance costs then everything is just
fine. However I suspect that in most cases the 'special' is not worth it.
But also, this could be used as an example of a missing construct in the
language and that this is emulated using uncontrolled goto statements. Such
is the case with a 'retry' concept and that's why I think it would be a
useful addition to D.

> 3) to avoid the creation of silly 'flag' state variables

Yes. Knuth often points to this situation as a reason to use goto. The
'flag' variable is conceptually redundant and can be expensive to use at
run-time. And I see this as another opportunity for a language to evolve so
that such 'flags' are both avoided and the 'goto' used in their absence is
also avoided. It would be *not* hard to generalize this situation so that a
new syntax could be introduced to cater for it, as it is fairly common.

> 4) to create an efficient state machine

Even though state machines are reasonably rare, they are very handy in some
situations. Again, it would not be hard for a language to come up with a
decent syntax to help people encode a state machine without uncontrolled
goto statements and to help the compiler generate efficient object code. If
there is specific syntax for state machines, it will reduce maintenance
costs and might even help people see where they can use them rather than
some other construct.

> 5) as output from program generators

The output from these are not usually designed for human readers nor
designed to be directly maintained. Therefore the use of goto statements
has some place in this sort of output. In fact, it is metaphorically
machine code.

> 6) to, for instance, collect all error handling code in one spot in a 
> function

Yes, this is a very common usage for goto statements. Not so much as a
performance enhancer because errors are supposed to be infrequent, but to
improve source code maintainability. However, I believe that the benefit of
goto usage here is lost due to the 'uncontrolled' nature of it. It
introduces labels that can theoretically be reached from places other than
the error handlers. In spite of that, I feel that this is a prime candidate
for new syntax to deal with the problem of consolidating error handling
code. It could be thought of an extension to D's 'try-catch' and 'scope'
constructs, so I would encourage you to consider further evolving D into a
language to delight code authors and maintainers, and also compiler
writers.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
1/05/2006 2:12:33 PM