[xmonad] darcs patch: Replace custom forever_ with library equivalent

[Gwern Branwen]

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 ()
>>       where
>> 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.
>
> Thoughts?
>

Ping.

-- 
gwern