Change the argument order of vec::foldl

[brson]

This function has it's arguments in the haskelly order that is analogous to the direction that is being folded - initial value, then the vector to fold. While this is kind of nice, it's contrary to our standard argument order of taking the vector being operated on first, and different from the order used by the iter library. Also the function that is taken as the third argument should probably have it's arguments switched. Essentially, I think foldl and foldr should have the same signature, in vec, iter and std::list

[catamorphism]

Is there a rationale behind putting the vector first? It trips me up every time.

[brson]

Do you mean putting the vector first in general? It's because the vector is the object being operated on, like a this pointer. What trips you up?

[catamorphism]

In Haskell, the operator (in things like map, filter, and so on) comes first because you're more likely to want to curry (map f) and use it on different lists than to curry (map xs) and map different functions over xs. It's not a really big deal, but I often write it the wrong (Haskell) way and it usually takes me a second to figure out what's wrong when it doesn't compile.

[catamorphism]

To me, (map f xs) is more natural since English is "noun verb object" rather than "noun object verb". But maybe that's just a backjustification for what I'm used to ;-)

[brson]

I see your point. Regarding the operator, we have been pretty committed to putting it last to accommodate our block sugar syntax.

[catamorphism]

No big deal.

[brson]

The discussion on IRC just now:

12:22 < brson> I'm trying to decide what to do about the argument order to vec::foldl - it has a different order than iter::foldl and list::foldl, but it
               arguably has the most natural order for 'foldl'
12:22 < brson> it takes the list second
12:23 < brson> soliciting opinions
12:24 <@graydon> I think usually we make the functions come last so we can support foo(x) { | x, y | ... } form
12:25 < brson> yes, I agree
12:25 < brson> but vec::foldl looks like fn foldl<T: copy, U>(z: T, v: [const U], p: fn(T, U) -> T) -> T
12:25 < brson> and we usually also make the vector come first
12:26 <@graydon> ah
12:26 <@graydon> in the case of a fold I think this is to match the binary-operator-ness of the function
12:26 < brson> yeah
12:26 <@graydon> list goes the other way?
12:26 < brson> list goes the other way
12:27 <@graydon> weird. hmm. fold is a rare beast in this respect, but I think I _slightly_ prefer what vec is doing over what list is doing.
12:27 < brson> iter also goes the other way, but it's because of the self argument, and since that's implicit maybe it doesn't matter
12:27 <@graydon> not a strong opinion
12:28 < brson> oh, actually no. iter has an actual function with an argument called 'self', so both list and iter do it backwards

[brson]

I guess I'm currently leaning toward changing list and iter to be like vec

[brson]

@nikomatsakis opinion?

[nikomatsakis]

I personally prefer the vec order, since otherwise I have a hard time remembering what's happening. The iter functions use a first parameter named self because I intended to make them into actual methods at some point...

[brson]

I swapped the arguments in list::foldl and left iter alone.