Argument Processing Order

BlitzMax Forums/BlitzMax Programming/Argument Processing Order

Otus	(Posted 2008) [#1]

I find it counter intuitive that function arguments are processed right to left. Is this common in many computer languages?

Function TakesTwo(i1:Int, i2:Int)
  Print i1+i2
End Function

Function Me:Int(i:Int)
  Print i
  Return i
End Function

TakesTwo Me(1), Me(2)
Rem
Output:
2
1
3
End Rem

Czar Flavius

(Posted 2008) [#2]

Why, because you read left to right? Is that any more or less intuitive as right to left? It has to start from one end :P

Your program should be designed so that the order function arguements are processed does not matter, to avoid confusion. If it does matter, store them in temp variables first, in the required order, and then pass these.

Gabriel

(Posted 2008) [#3]

I was under the impression that function arguments might be processed in any given order and that you should always code such that the order doesn't matter.

Otus	(Posted 2008) [#4]

Why, because you read left to right? Is that any more or less intuitive as right to left? It has to start from one end :P

Functions in expressions are processed left to right, why should arguments not?

Your program should be designed so that the order function arguements are processed does not matter, to avoid confusion. If it does matter, store them in temp variables first, in the required order, and then pass these.

Yeah, it is probably bad coding style. However, it allows for shorter notation. You could argue the same for expressions: Never call multiple functions in an expression, but store them in temporary variables.

I was under the impression that function arguments might be processed in any given order and that you should always code such that the order doesn't matter.

Ok, that's good to know! I was actually first going to fix my problem by reversing the function parameters, but now I'm not going to do that...

This kind of things should be mentioned in the docs :p

Floyd

(Posted 2008) [#5]

Writing code which depends on arguments being evaluated in a specific order is bad programming practice. In C/C++ you are explicitly told that the order is undefined. The compiler can do anything it wants. The order might even change with different levels of optimization.

Blitz languages are not defined in such detail. The order will probably never change in the future, but you are not promised this.

Gabriel

(Posted 2008) [#6]

This kind of things should be mentioned in the docs :p

It would be good to have a section devoted to this sort of stuff, I agree. It could include the way floating point numbers are handled internally, the way in which object casts are performed, all those sort of internal things which the beginner won't need to know but a moderate to experienced programmer would find invaluable.

Czar Flavius

(Posted 2008) [#7]

You could argue the same for expressions: Never call multiple functions in an expression, but store them in temporary variables.

It depends whether the order of the functions matters. In your Me example, if the order in which they are called doesn't matter, there is no need to worry. The order they do matter is usually if they are changing global variables or altering things that are sent as parameters by reference.

Otus	(Posted 2008) [#8]

Are you saying even the order functions in expressions are processed is not set in stone?

EDIT: No, it has to be. Simply for If Some() And ...

Czar Flavius

(Posted 2008) [#9]

Are you saying even the order functions in expressions are processed is not set in stone?

Ahhh it's a kind of is and isn't thing :)

It might be... but it doesn't HAVE to be..

It's set in stone in that it always does it in the same order in Blitz at the moment (going by what you say, not tested it myself) however it is NOT set in stone in that it is a 'rule' of the language. Although unlikely, it's entirely possible that in any future update of Blitz the order will change, which might break your program if it depends upon the order.

So it depends if you want to program 'pratically' or 'theoretically' :)

For example say you have an And in an If. The computer runs the first function and it returns false. Now whatever the second function is, it doesn't matter the If will still be false (because And needs both to be true) so a smart thing to do would be to simply ignore the second condition - there is no need to waste time checking it. The only problem is, if the act of checking alters the results (quantum mechanics here we go!) and so the program logic might break because a vital function has not been ran. I hope I'm explaining this in a good way.

C++ has lots of little optimizations like this, one reason why it's so fast, and that's why C++ programmers are extra careful about making sure things are done 'properly'. I don't know if Blitz uses this optimization or not, but if it doesn't, and Mark decides to add it later, you'll be in trouble if you previously relied upon it not being there!

Otus	(Posted 2008) [#10]

Yeah, I know what you mean. That's the current behaviour, at least to my knowledge: Ands and Ors are optimized so that if the leftmost suffices, the right one is not evaluated. I'm guessing there's some code relying on this, whether it's good habit or not.

I can understand the optimization argument with expressions, but cannot see a reason why one order were better with arguments. But, well, I don't know that much about assembly languages so there may well be many.

In any case, it's good to know these things. This far I've mainly guessed+tested how things work, but as Gabriel said above:

Koriolis

(Posted 2008) [#11]

Concerning Ands and Ors: because they use short circuit, you are guaranteed about the order of the whole And/Or sub-expression with other sub-expressions. However, this gives no guarantee about the order in which the two operands are evaluated.

Otus	(Posted 2008) [#12]

Could you elaborate? That was rather confusing.