Replying to [comment:10 dfeuer]:
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
#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:11 refold]: the end of a lazily-read file.
Hmm, I see now. That's because
{{{ dropWhileEnd isSpace ("foo\n" ++ undefined) == "foo" ++ undefined }}}
but
{{{ dropWhileEndLE isSpace ("foo\n" ++ undefined) == undefined }}}
so the `LE` version would need to read the whole file in memory.
IMO the `LE` version is more practical since you usually do stuff like
`return . map (dropWhileEnd isSpace) . lines =<< readFile "foo"` instead of just dropping the end of the file.
For reference: the original discussion on the libraries list is
[http://www.haskell.org/pipermail/libraries/2011-September/016829.html here]. I see now that Roman Leshchinskiy [http://www.haskell.org/pipermail/libraries/2011-September/016841.html proposed] precisely the definition of what I call `dropWhileEndLE`. It looks like there was a lot of confusion back then about the exact laziness properties of the different proposed definitions, and it appears no one recognized the significance of the order of `&&` operands to the semantics. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9623#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler