std.range: Order of arguments unluckily chosen?

[Andrei Alexandrescu]

On 06/04/2011 03:11 PM, Timon Gehr wrote:
>  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?

Well this hurts. With the same in mind as you, I initially defined take 
to take the number first. But OO people wanted to write array.take(3), 
so I changed the order. Don't forget that UFCS is still on the table.

Impossible to please everybody!

I don't know what to do to improve the situation.


Andrei