Consider adding Data.Sequence.{splitAtR, takeR, dropR}

[JLimperg]

I was recently surprised by the lack of splitAtR, takeR and dropR in Data.Sequence when takeWhileR and dropWhileR are available. Taking this question to Stack Overflow, a simple implementation of splitAtR in terms of splitAt and length was suggested by SO user chi. Would you consider adding these functions?

[treeowl]

In general, the way to get things added to containers is to start by sending a proposal to libraries@haskell.org. The only real exception I know of is if you're looking to add an obvious instance declaration.

[foxik]

Personally I am not sure whether these functions would benefit the API. Sure, I understand the consistency argument. On the other side, having a lot of functions can be a bit overwhelming and complicated for the users to find what they like.

As the suggested functions just "reverse" the index given to them (to index from right instead of left), I would personally not include in the API (it is trivial to implement them by yourself, and I do not think they are used very frequently). Note that that is not the case with takeWhileR and dropWhileR, which cannot be implemented efficiently using takeR and dropR.

[JLimperg]

@treeowl: If I understand the process correctly, a proposal should start out with an issue on the tracker; this is that.

@foxik: For what it's worth, I did not see the solution, though that may be indicative of my problem solving skills more than the API quality. ;) Seeing that Data.Sequence generally provides functions for both ends of the sequence, I assumed that takeR and dropR only admitted an inefficient implementation and were therefore not present (though I was suspicious enough to ask the SO question).

If you don't consider these functions worth adding, would you accept a doc patch that points out how to implement them?

[foxik]

@JLimperg It is my personal view that the functions you are suggesting are not worth adding -- but others may feel differently. Therefore do not hesitate to ask on libraries@haskell (or somewhere else) and if more people would like to have the functions in the API, I will gladly add them.

As for the doc patch, that we can surely add.

[treeowl]

It's my personal view that these functions are worth adding, but I agree with @foxik that the matter should be raised on the libraries list.

[meooow25]

This was requested again in #884, and treeowl and I are both in favor of adding the variants. A PR would be welcome.