Replying to [comment:8 dfeuer]:
However, the above `dropWhileEndLE` appears to be faster than the double reverse in all cases. So I'll add it to the utilities module and use that instead.
Since `dropWhileEndLE` is both faster and has less surprising semantics (spine-strict instead of element-strict), I think that the standard
#9623: Use Data.List.dropWhileEnd -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries | Version: 7.8.3 (other) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:9 refold]: library should be changed to use this version. And we should also add `takeWhileEnd` while we're at it. It seems to be faster in the common case of trimming spaces from fairly short strings. It would be pretty bad for cutting a little bit off the end of a lazily-read file. I would be in favor of adding `dropWhileEndLE` (by some name) to `Data.List`, and perhaps deprecating the name `dropWhileEnd` in favor of something less confusing like `takeUntilLast = dropWhileEnd . not`, but just changing the semantics of an existing function seems generally frowned upon. That said, the semantics of `Data.Text.Lazy.dropWhileEnd`, that someone suggested I check into, are much more confusing to me so far, so there may be a bit of room to wiggle things around. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9623#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler