X.U.ExtensibleConf: New helper module for extensible config

[liskin]

Description

It's often difficult to make contrib modules work together. When one depends on a functionality of another, it is often necessary to expose lots of low-level functions and hooks and have the user combine these into a complex configuration that works. This is error-prone, and arguably a bad UX in general.

This commit presents a simple solution to that problem inspired by "extensible state": extensible config. It allows contrib modules to store custom configuration values inside XConfig. This lets them create custom hooks, ensure they hook into xmonad core only once, and possibly other use cases I haven't thought of yet.

This requires changes to xmonad core: xmonad/xmonad#294

A couple examples of what this gives us:

• X.H.RescreenHook can be made safe to apply multiple times, making it composable and usable in other contrib modules like X.H.StatusBar

• withSB from X.H.StatusBar can also be made safe to apply multiple times, and we can even provide an API similar to what we had before if we want (probably not, consistency with the new dynamic status bars of Dynamic Status Bars support for XMonad.Hooks.StatusBar #463 is more important)

• The X.H.EwmhDesktops refactor can possibly be made without breaking the ewmh/ewmhFullscreen API. And we will finally be able to have composable EWMH hooks.

Related: xmonad/xmonad#294

Checklist

• I've read CONTRIBUTING.md

• I've considered how to best test these changes (property, unit, manually, ...) and concluded:

  There's a unit test. As the code deals with dynamically typed data, I actually needed the test to get it right. :-)

• I updated the CHANGES.md file

• I updated the XMonad.Doc.Extending file (if appropriate)

---

(draft as it overrides CI instructions temporarily)

TODO

• merge Add support for extensible config in contrib modules xmonad#294
• bump xmonad core version (0.16.99 ?) and bump lower bound here
• we will no longer be able to test xmonad-contrib against both latest hackage release and git master: decide what to do

[slotThe]

This is really cool! 👍

I played around with the low-level primitives a bit because

lookup c = let x = fromConfExt =<< typeRep x `M.lookup` extensibleConf c in x

kind of broke my brain for a while; here's what came of it. I don't know if this is correct (the tests pass, at least :))

Needs

{-# LANGUAGE AllowAmbiguousTypes #-}
{-# LANGUAGE FlexibleContexts    #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeApplications    #-}

and

theType :: forall a. Typeable a => TypeRep
theType = typeRep (Proxy :: Proxy a)

[slotThe]

Suggested change

	lookup :: Typeable a => XConfig l -> Maybe a
	lookup c = let x = fromConfExt =<< typeRep x `M.lookup` extensibleConf c in x
	lookup :: forall a l. Typeable a => XConfig l -> Maybe a
	lookup c = fromConfExt =<< theType @a `M.lookup` extensibleConf c

[slotThe]

Suggested change

	alter :: Typeable a => (Maybe a -> Maybe a) -> XConfig l -> XConfig l
	alter f c = c{ extensibleConf = M.alter f' t (extensibleConf c) }
	where
	f' :: Maybe ConfExtension -> Maybe ConfExtension
	f' = fmap ConfExtension . f . (>>= fromConfExt)
	t = typeRep (f undefined)
	alter :: forall a l. Typeable a => (Maybe a -> Maybe a) -> XConfig l -> XConfig l
	...
	t = theType @a

(perhaps we can even inline t now)

[slotThe]

Suggested change

	once :: (Semigroup a, Typeable a)
	=> a -- ^ configuration to add
	-> (XConfig l -> XConfig l) -- ^ 'XConfig' modification done only once
	-> XConfig l -> XConfig l
	once x f c = add x $ maybe f (const id) (lookup c `asTypeOf` Just x) c
	once :: forall a l. (Semigroup a, Typeable a)
	...
	once x f c = add x $ maybe f (const id) (lookup @a c) c

[slotThe]

Suggested change

	onceM :: (Applicative m, Semigroup a, Typeable a)
	=> a -- ^ configuration to add
	-> (XConfig l -> m (XConfig l)) -- ^ 'XConfig' modification done only once
	-> XConfig l -> m (XConfig l)
	onceM x f c = add x <$> maybe f (const pure) (lookup c `asTypeOf` Just x) c
	onceM :: forall a m l. (Applicative m, Semigroup a, Typeable a)
	...
	onceM x f c = add x <$> maybe f (const pure) (lookup @a c) c

[slotThe]

The tests don't catch the (stupid) error of using the same type representation for everything. I'd add something like

    let a = XC.add @[Int]  [1] def
        b = XC.add @String "b" a
    specify "lookup @String . add @String . add @[Int]" $
        XC.lookup @String b `shouldBe` Just "b"
    specify "lookup @String . add @String . add @[Int]" $
        XC.lookup @[Int]  b `shouldBe` Just [1]

here (needs TypeApplications)

[liskin]

I added a similar test: feb8086

I can't decide about the rest. :-/
Some people seem to have strong opinions, but I don't. I wish it was possible to write once without messing with the types. Then I'd just say that the low-level code won't be modified anyway and push whatever a dice roll tells me to push. But as this abstraction leaks into higher levels, it may be worth debating a little bit. Just a little bit though… ;-)

[slotThe]

Well, I suppose my opinion should be obvious—I think the version with TypeApplications is much more readable. I will, however, gladly open this up to some productive bike-shedding :>

[liskin]

So how about this:

I pushed ee35ad6, which uses TypeApplications, but doesn't define theType (if Haskell gods wanted us to have forall a. Typeable a => TypeRep, they'd have put it in base). If people oppose that impl, they're free to comment constructively here.

[slotThe]

Works for me 👍

(if Haskell gods wanted us to have forall a. Typeable a => TypeRep, they'd have put it in base)

One could argue that that's just a mistake in base :P