[xmonad] Inconsistencies in `instance Monoid ManageHook'

[Adam Vogt]

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