This is a funny idea about a programming language where arguments can sometimes commute. This allows you to forget the order in which arguments are supplied to functions (except when that order is really meaningful).

Suppose you have a function call like f(x, y, z), where x is a Dog, y is a Cat, and z is a Lizard. However, the declaration of f is like this:
function f(Cat c, Lizard d, Dog e)
One way for a compiler to deal with these mismatched types is to simply signal an error. However, in this case the programmer had just forgotten the order of arguments to f; what he meant is unambiguous. Instead of signaling an error, the compiler could simply reorder the call to look like f(y, z, x), which is just what the programmer would have had to do manually. If the compiler does that, then f becomes commutative in all 3 arguments.

However, it's undesirable for arguments to always commute. For instance, a function divide(a, b) that returns a/b should not commute, and the programmer does need to remember the order of arguments in this case. The right thing to do is to reorder the arguments so that all types match, but to preserve the respective order of variables of the same type. So if a function has type signature A, B, B, C, and the programmer supplies arguments w, x, y, z of types B, C, A, B, then the compiler should reorder the arguments to y, w, z, x (and not y, z, w, x).