[GHC] #9623: Use Data.List.dropWhileEnd

[GHC]

#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]:
 > 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
 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