[xmonad] Inconsistencies in `instance Monoid ManageHook'
Adam Vogt
vogt.adam at gmail.com
Tue Aug 3 00:57:39 EDT 2010
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
More information about the xmonad
mailing list