#3379: GHC should use the standard binary package -------------------------------------+------------------------------------- Reporter: igloo | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ulysses4ever): Hey, Ben, I missed the second part of your last post, unfortunately (read the email notification where it only shows the first version). I think there is an interesting design task here. You see, `Data.Binary` deals solely with serialization while GHC's Binary has serialization to the particular type of storage (`BinHandle` structure). As the first step, I think, we could factorize `GHC.Binary` to just use `Data.Binary` instead of trying to completely remove the former at once. For that, something like {{{#!haskell instance Data.Binary a => GHC.Binary a where ... }}} could work? My impression is that most of the instances of `GHC.Binary` are really boring, and all clever business is done directly with `BinHandle`s inside `Iface`-related modules. Discalaimer: I'm not totally sure what this `BinHandle`-related business is about. I read some Notes in the sources but didn't get much. The `IORef BinArray` part makes sense, but the rest… For now, I'm stuck with the error I listed above. Strangely enough, when doing `make test` on my brunch with `Data.Binary`-derived instance of `GHC.Binary ArgFlag`, I randomly get either that one error I mentioned above, or 518 errors (including the one above), all are with "bad stderr" or "bad stdout". -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/3379#comment:19 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler