Split up store typeclass

[mgsloan]

What if we split up the store typeclass into separate poke and peek portions? There are a couple reasons for this:

• store is already useful for defining serialization and deserialization for existing binary formats, even though this wasn't our immediate goal. For these applications, you might only care about reading or writing some particular data, and not both. I think @chrisdone in particular will agree this should be split up.
• I suspect that the approach for speeding up compilation time described in Compilation for big datatypes with Generics is quite slow #5 is not just specific to generics, and may apply to any multi method typeclass (maybe only in the presence of aggressive inlining?). This remains to be measured.

So, to me, it seems like we should split it up. The only downside is that it takes a bit more boilerplate to define both instances, even with generics. However, the TH magic should be able to be just as concise.

All that's left is bikeshedding. What do we call these classes? Maybe something like:

-- Constraint synonym
type Store a = (Peekable a, Pokeable a)

class Peekable a where peek :: Peek a
class Pokeable a where
    size :: Size a
    poke :: a -> Poke ()

Other possibilities are StorePeek and StorePoke, or instead perhaps HasPeek and HasPoke.

It may even be worthwhile to split out the size method, but I think I prefer it bundled with poke, since that's what it's used for.

@snoyberg @chrisdone @kantp @bitonic Thoughts on this bikeshed? :)

[chrisdone]

I'm fine with Peekable/Pokeable. One of our clients has indeed a codebase which has a Peek but no Poke.

[kantp]

I'd be more than happy if this would indeed speed up the compilation!

As for the bikeshedding, I agree that Peekable/Pokeable is fine.