'goto" gone from computer languages or is it!

John> Point taken; my first guess was 0 0 0, but it is apparently John> left ambiguous by the standards committee. I did use the term John> "almost always" to hedge, but still, you're right. Actually, I don't think the example was "ambiguous". It's "undefined" which is actually a term with a precise meaning. So you were right -- a program is a precise statement. But for some programs, that precise statement doesn't define just one possible outcome. A number of programming languages intentionally make certain things unspecified, or undefined -- the reason for doing that is to give implementations more choices and allow more efficient implementation. The sample program that started this discussion is one example. C isn't the only language that does this; Algol 68 is another. For example, it quite explicitly and intentionally says that it's unspecified whether the left or the right side of + (or neither) is evaluated first. John> Nevertheless, for any given compiler there is only one John> interpretation. So I hereby clarify my statement to say that John> programming languages as implemented by actual compilers or John> interpreters are the most succinct, clear and unambigious John> specification languages imaginable. Not true. For example, you may have a program in which several things happen in an order that depends on timing, or interrupts, or things like that; if so, you may not get the same answer when you run it twice. Embedded systems programmers are painfully familiar with this. To use Algol 68 as an example again: int i := 0; int j := (i := i+1) + (i := i+1) (which in C could be written as: j=(++i)+(++i) ) On completion, j might be 1 or 2, and i might be 1 or 2 -- and in implementations that take advantage of paralellism, the answer might change from run to run. paul