On Thu, Apr 21, 2005 at 02:28:52PM +0100, Matthew Walton wrote: > > On Thu, Apr 21, 2005 at 11:45:27AM +0200, Paul Johnson wrote: > > > It certainly makes more sense to me that the answer would be 2 2. But > > however it ends up, so long as we know what the answer will be, we can > > utilize it effectively in our programs. > > The trick with this construct usually in C is that the C standard doesn't > specify the order of evaluation of function arguments, so you can never be > sure if you'll get the same result if you compile it other than on your > development system (different compilers may evaluate them in a different > order). The Pugs example given in the original post seems to me to be > fairly sane, as it shows left-to-right evaluation. The Perl 5 example, as > far as I can tell, shows left-to-right for the first case and > right-to-left for the second case, which is just odd... please correct me > if I'm wrong, but that seems the only way those answers could have been > arrived at. > So really, what needs to be said is how Perl 6 is supposed to evaluate the > arguments to function calls, then we can know if the current behaviour in > Pugs is correct.
That "trick" in the C language is not an accident, but deliberate. Leaving the result undefined allows compiler writers to choose the definition that fits best for that compiler's internal structure and/or the target hardware architechture. Thus, when people write code that doesn't happen to care about the abiguity in the spec, it is processed (run/compiled) in the best way the compiler writer can provide. In C, at least, you can't always tell whether a particular statement is ambiguous (e.g. "i = *p1++ + *p2++" - do p1 and p2 always point to different memory locations?) and the cost of treating it in an ambiguity-safe manner might be significant, since C tends to get used for low level critical operations. The approach is: make the programmer handle the rare tough cases himself and let the compiler do the common job really well. That is similar to "easy things should be easy, hard things should be possible" but C puts more emphasis on run time speed than programmer utility in how it applies its philosophy. --
