[xmonad] darcs patch: Replace custom forever_ with library
gwern0 at gmail.com
Sat Mar 27 11:14:11 EDT 2010
On Thu, Mar 25, 2010 at 9:32 AM, Gwern Branwen <gwern0 at gmail.com> wrote:
> On Mon, Mar 22, 2010 at 4:28 PM, Gwern Branwen <gwern0 at gmail.com> wrote:
>> On Fri, Jan 16, 2009 at 3:38 PM, Daniel Schoepe <asgaroth_ at gmx.de> wrote:
>>> Replaced a custom forever implementation in Main.hsc by the equivalent
>>> from the standard libraries. I guess it was legacy code, since forever
>>> wasn't in Control.Monad in ghc 6.6 as far as I know.
>>> Wed Jan 14 22:55:56 CET 2009 Daniel Schoepe <asgaroth_ at gmx.de>
>>> * Replaced custom forever_ by library function
>> hunk ./XMonad/Main.hsc 146
>> userCode $ startupHook initxmc
>> -- main loop, for all you HOF/recursion fans out there.
>> - forever_ $ prehandle =<< io (nextEvent dpy e >> getEvent e)
>> + forever $ prehandle =<< io (nextEvent dpy e >> getEvent e)
>> return ()
>> hunk ./XMonad/Main.hsc 150
>> - forever_ a = a >> forever_ a
>> -- if the event gives us the position of the pointer, set mousePosition
>> prehandle e = let mouse = do guard (ev_event_type e `elem` evs)
>> return (fromIntegral (ev_x_root e)
>> This patch still applies to core.
>> I think it ought to be applied. Besides the general goodness of not
>> rolling our own and duplicating libraries, the chief objection was
>> people might not be using GHC 6.8 or newer.
>> But that was more than a year ago, and even Debian stable is using 6.8.2:
>> - http://packages.debian.org/search?keywords=ghc6
>> - http://packages.debian.org/lenny/ghc6
>> And I strongly suspect that we already broke GHC 6.6 compatibility in
>> several many ways.
>> So there's no downside to applying this, and only upside.
More information about the xmonad