'goto' - the debate between 'human' vs 'machine' programming

Well, I'm not sure what a Belgian horse is. But yes, using a goto can indeed be wrong even when it gets you out of a jam. If it really is true that the program in question is going to be written all at once and never modified, then there probably is almost no price to a goto. (Only "almost" no price because when a goto is the answer the question has usually been misunderstood, so using a goto often carries the price of writing code that solves the wrong problem.) But if the program is going to be maintained, either by another person or by its original author after a significant time - say, more than a month - then using a goto carries a significant maintenance cost. Occasionally this cost is less than the various costs associated with other ways of writing a solution to the problem, but far more often not, at least in my experience. My experience has also been that to a first and almost even a second approximation, _no_ programs are written all at once and never modified, and the few exceptions are trivial little hacks that don't involve the sorts of problems that tempt one to use gotos anyway. Again, this is allowing exceptions for cases where a structured construct is written with a goto, such as when writing in gcc and using a goto to throw out of a nested function, or when the code isn't really the source code humans work with, as with mechanically or semi-mechanically generated programs. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B