1

I need to serialize a DAWG (provided by this library) to a bytestring. As I saw in the documentation that there is an instance (Ord b, Binary b) => Binary (DAWG a b) which seems to provide support for this, I tried directly to use encode:

import qualified Data.DAWG.Dynamic as Dawg
import qualified Data.Binary as Bin

Bin.encode $ Dawg.fromList [("foo",1),("bar",2)]

But GHC complains that there is no instance for (Bin.Binary (Dawg.DAWG Char b0)). I get the point that it is necessary to tell GHC what data types the graph contains, but then, how is it done? And if I'm wrong, what am I supposed to do instead?

Edit : Stack trace for Bin.encode $ Dawg.fromList [("foo"::String,1::Int),("bar",2)]:

<interactive>:19:1:
    No instance for (Bin.Binary (Dawg.DAWG Char Int))
      arising from a use of `Bin.encode'
    Possible fix:
      add an instance declaration for (Bin.Binary (Dawg.DAWG Char Int))
    In the expression: Bin.encode
    In the expression:
      Bin.encode
      $ Dawg.fromList [("foo" :: String, 1 :: Int), ("bar", 2)]
        In an equation for `it':
        it
          = Bin.encode
            $ Dawg.fromList [("foo" :: String, 1 :: Int), ("bar", 2)]
michaelmeyer
  • 7,985
  • 7
  • 30
  • 36
  • Without the complete error I can't be sure, but probably you're being bitten because `1` and `2` are polymorphic. Give one of them a type signature (e.g. `:: Int`) and see what happens. – Daniel Wagner Jan 19 '14 at 13:27
  • Have you tried to `Bin.encode $ Dawg.fromList [("foo",1::Int),("bar",2::Int)]`? I think `Binary` needs a concrete type in order to automatically serialize numbers. – Danny Navarro Jan 19 '14 at 13:28
  • I just tried this, but GHC still complains (though it know recognizes the graph type to be `Dawg.DAWG Char Int`). – michaelmeyer Jan 19 '14 at 13:34
  • It's hard to guess what's going on without seeing the error... Maybe you have `OverloadedStrings` enabled? What about `Bin.encode $ Dawg.fromList [("foo"::String,1::Int),("bar",2)]`? – Danny Navarro Jan 19 '14 at 13:42
  • @doukremt, I can't reproduce your error. Are you just doing what you wrote? Do you have any additional code? – Danny Navarro Jan 19 '14 at 14:09
  • @doukremt: I also can't reproduce. I have a file with the imports you have above and the line `test = Bin.encode $ Dawg.fromList [("foo"::String,1::Int),("bar",2)]` and it compiles and runs fine. Try posting a complete file which has the problem. Also the output of `cabal info dawg` may help (to check what version you are using). – David Miani Jan 19 '14 at 14:15
  • Just posted the full dump here: http://pastebin.com/HPC47rNy. Perhaps my version of GHC is messed up? I go trying another one. – michaelmeyer Jan 19 '14 at 14:28
  • @doukremt With the full dump it still works for me. I have the same version `dawg`. – Danny Navarro Jan 19 '14 at 14:36
  • My suspicion would be that you have two versions of `binary` installed, and that `dawg` is compiled against another version than the one you end up using by default. You can figure out the one `dawg` is compiled against by saying `ghc-pkg describe dawg` and looking for version and hash in the `depends:` field. Similarly, you can check if `ghc-pkg describe binary` lists multiple versions of the `binary` package. – kosmikus Jan 19 '14 at 14:39
  • I just checked the hashes: they are identical. I also tried reinstalling the package, without effect. This is becoming frustrating :). – michaelmeyer Jan 19 '14 at 15:07
  • 1
    Well, you'd definitely have an instance of `binary` with a matching hash. The question is whether you also have another one. How many `binary` packages does `ghc-pkg list binary` show? – kosmikus Jan 19 '14 at 15:16
  • @kosmikus: Aha, it seems you got it! I have two versions `binary-0.5.1.1` and `binary-0.7.1.0`. – michaelmeyer Jan 19 '14 at 20:24
  • @kosmikus: I unregistered the old version following `http://stackoverflow.com/questions/10576868/how-can-i-uninstall-a-version-of-a-cabal-package` and it now works. Could you post an answer so that I can upvote you? – michaelmeyer Jan 19 '14 at 20:29

1 Answers1

2

A problem like this can be caused when two or more versions / instances of the same package are installed.

Package dawg might be compiled against a particular instance of the package binary, let's call it binary-A. It's possible you have a second instance of binary, binary-B installed as well. Now if GHCi decides to import Data.Binary from binary-B, then its Binary class will be considered different from the Binary class that dawg defines an instance for.

The solution is to explicitly select the correct binary instance, for example using the -package-id flag. If you use cabal for your project, then it will automatically try to resolve the dependencies for your project in such a way that consistent versions of all involved packages are selected.

kosmikus
  • 19,549
  • 3
  • 51
  • 66