As described by Chris Done, here, we've gotten a lot of mileage out of using store on existing binary formats. However, that only works well when we can assume a machine architecture (endianness etc).

See #31 for ideas on how to support declaring machine independent serialization. The focus of this issue is on making it safe. Ideally, store would allow you to declare architecture independent serializations in such a way that you have static checking that your serialization is architecture independent. Here's the best scheme I can come up with for this:

1. Choose the behavior on x86_64 machines to be the canonical serialization behavior. So, machine representations will be used on the most common platform.

2. Add new class(es) and types for machine independent serialization. It just occurred to me to name these after the binary types - Rename Peek and Poke to binary / cereal naming #35 . This makes sense, as these are good names for machine independent serialization, and will make it easier to port code from binary / cereal.

class StoreCrossArch where
    putSize  :: Size a
    put :: a -> Put ()
    get :: Get ()

newtype Put a = Put (Poke a)
newtype Get a = Get (Peek a)

(probably split up - #21)

3. On little endian machines with no alignment issues, StoreCrossArch should get implemented and Store defined in terms of it (on a per instance basis). This way the serialization performance should be the same on x86 whether or not you are using the machine independent interface.

4. On big endian machines, Store would be implemented separately from StoreCrossArch. The StoreCrossArch instances would handle endianness flipping. So, put :: Int -> Put () would use a little endian int even though we're on a big endian architecture. poke :: Int -> Poke () would use a big endian int, as that's the machine representation.

Not sure if this will be implemented in the immediate future, but it's rather fun to think about. PRs appreciated!