Hi, The behavior of instance Monoid ManageHook is unnecessarily complicated. Perhaps the following example can convince you If a and b are defined with some arbitrary a', b' manipulations of the WindowSet like

a :: ManageHook a = do liftIO (putStrLn "a") doF a'

Then

a <+> b

can be written as

do liftIO (putStrLn "a") liftIO (putStrLn "b") doF (a' . b')

Side effects take place from left-to-right. The WindowSet is threaded from right-to-left through the functions (which could be produced as a result of those side effects). Possible correction: 1. Change ManageHook

type ManageHook = Query (Dual (Endo WindowSet))

For: All Monoid instances involved with XMonad would be left-to-right (Data.Map.Map prefering values on the left for duplicate keys doesn't fitting any direction in my opinion) Against: Will break quite a few configurations 2. Change instance Monoid (Query a)

instance (Monoid a) => Monoid (Query a) where mappend = flip (liftM2 (flip mappend))

For: Less code is likely to be broken by flipping the order that IO is run, since much fewer ManageHooks seem to involve liftX or liftIO for changing things that could be read later Against: Left-to-right remains a special case for ManageHook How much would you value consistency when using (<+>) = mappend with nearly all fields in XConfig? Are any current or reasonable uses of ManageHook be impossible if one of the composition orders were changed for consistency? -- Adam