On Sun, Feb 22, 2009 at 5:23 PM, Marc Weber
I usually use Data.Binary for serialization. Sure. But you can't derive Data.Binary easily for NominalDiffTime. That's the point. You can only do so by using toReal or by adding data MyOwnPico = MyOwnPico only to create serialization instances. I don't like this kind of code duplication..
Marc
One advantage of the current system is that is preserves data abstraction. For example, right now NominalDiffTime is declared
newtype NominalDiffTime = MkNominalDiffTime Pico
so it would be possible for GHC or another automated tool to derive an instance of Read, Show, Binary, whatever for it. However, what if, in the future, the maintainer of the Time library wanted to change this to
newtype NominalDiffTime = MkNominalDiffTime Double
? Now your derived instance wouldn't be the same, so your serialized data would not be compatible even between the same version of your library even if the version of your library stayed the same because the time library version had same. Even worse, what if the Time library maintainer changed it to
newtype NominalDiffTime = MkNominalDiffTime (Int -> Pico)
? Now you can't make a derived instance at all! There's no really good reason why they would make these changes; it seems reasonable that the Time library will stay in much the same form for the forseeable future. However, the whole point of abstract datatypes is that the maintainer can change the internals without disrupting dependent packages, as long as the accessor functions has the same semantics. In order for this to work, you can't have any external code - even derived instances - relying on the internal structure of abstract datatypes. Alex