std.range: Order of arguments unluckily chosen?

[Timon Gehr]

>From my code:

writeln(reduce!"a+b"(stride(take(recurrence!"a[n-2]+a[n-1]"(2,3),31),3)));
(This solves project euler problem 3);

I think that should look more like:

writeln(reduce!"a+b"(stride(3,take(31,recurrence!"a[n-2]+a[n-1]"(2,3)))));

rationale:
The second version is WAY easier to read, all the information needed is there
without having to jump around in the code:

1st version translated to English:
Sum up every j-th element of the first i elements of fib, which is computed by
the recurrence a[n]=a[n-2]+a[n-1] with a[0]=2 and a[1]=3, where i=31 and j=3.

2nd version translated to English:
Sum up every 3th element of the first 31 elements of fib, which is computed by
the recurrence a[n]=a[n-2]+a[n-1] with a[0]=2 and a[1]=3.

1st version English is even better than the code, because you can search the
text for 'i' or 'j'. In the code you have to count parentheses.

Yes, changing the order would break UFCS. But UFCS works with arrays only, all
the other use cases are broken. (that are most cases)
Also, there is a function takeOne. That is more similar to take(1,...) than
take(...,1). The amount of elements taken should be closer to the name of the
action, because it is needed to fully describe it. (take!31(fib) would be even
closer, but that does not work with runtime values.)

I think the order should be swapped. It is also the way functional language
libraries handle it. It works better with currying too.

Any comments/arguments on why the current order is the right order?


Timon