Skip to content

Add takeEnd to Data.Sequence #884

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
noughtmare opened this issue Dec 21, 2022 · 4 comments
Closed

Add takeEnd to Data.Sequence #884

noughtmare opened this issue Dec 21, 2022 · 4 comments

Comments

@noughtmare
Copy link

noughtmare commented Dec 21, 2022

The Data.Sequence module is missing the common function takeEnd :: Int -> [a] -> [a] where takeEnd n xs = drop (length xs - n) xs.

I think it is important to include this function because manually calling the length and drop functions can be error prone (I just fixed a bug in my own code).

This function is present in other sequence-like libraries, most notably:

I believe the only reason it is not in Prelude is that this operation is not efficient on lists.

It was almost accepted into Data.Vector, but the implementor didn't have time to finish the work.

@treeowl
Copy link
Contributor

treeowl commented Dec 21, 2022

Right idea, yes, but is it the right name? I think some libraries list discussion might be in order. The module currently has dropWhileL, dropWhileR, etc. Do we want to use your proposed convention or that one? Personally, I don't care, but I'd love to see what others think.

@noughtmare
Copy link
Author

noughtmare commented Dec 21, 2022

Hmm... I think indeed the naming convention should ideally be consistent within this library, so that would mean we would add takeL and takeR (and deprecating take?).

I guess it makes sense that the naming scheme of bytestring and text is asymmetric because their data has a clear left-to-right ordering. In contrast Data.Sequence (and arguably Data.Vector) don't have such a bias.

@treeowl
Copy link
Contributor

treeowl commented Dec 21, 2022

I don't want to deprecate take and drop; that seems far too disruptive with too little gain. But I'd be open to adding the L/R labeled variants. We're mostly unbiased, but we do follow the original paper in optimizing constant factors for |> and viewl.

@meooow25
Copy link
Contributor

Previously requested in #159.
I wouldn't mind adding the R variants.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants