[xmonad] XMonad.Config.Prime, a monadic config syntax

[Devin Mullins]

On Mon, Oct 1, 2012 at 2:31 PM, Brent Yorgey <byorgey at seas.upenn.edu> wrote:
> Just looking at the Haddocks, I like it very much!

Thanks!

On Mon, Oct 01, 2012 at 02:40:57PM -0400, Brandon Allbery wrote:
> On Mon, Oct 1, 2012 at 2:31 PM, Brent Yorgey <byorgey at seas.upenn.edu> wrote:
> 
> > Can you say a bit more about exactly why TH is required?  I get that
> > fclabels depends on it, but why do you have to turn on the
> > TemplateHaskell flag in your xmonad config?  (I haven't actually
> > looked at the code.)

> > > +-- >   $(modifyLayout [| smartBorders |])
> 
> This strikes me as somewhat unfortunate, but it's possible that we can't do
> better given that layouts are rather ugly type-wise currently.

Yeah, the problem is that the XConfig is parameterized on the layout
type, and the State monad can't vary the type of its state. So I wrap
the layoutHook in the Layout existential and mess with it that way.
You don't _need_ TH. You could write this in your config:
  layoutHook =. (\(Layout l) -> Layout (l ||| simpleTabbed))
The TH is just to hide that nastiness so you can write:
  $(addLayout [| simpleTabbed |])
instead.

(Unfortunately, due to Haskell magic I don't understand, I can't just
write an 'fmap' for existentials. Though I just discovered the exists
package. Maybe it has the magic I desire...)

I've long considered layout persistence via Show/Read to be a hack
(seems like we could represent layouts with a single type), but changing
that would be a much bigger thing. :)

fclabels, OTOH, is no big thing. I'm not really using the
TemplateHaskell part of it (just a smidge), and the rest I could just
reimplement.