Re: [Haskell-cafe] Unexpected type error

On Mon, Jun 13, 2011 at 1:00 PM, Alexander Solla wrote:

On Mon, Jun 13, 2011 at 10:45 AM, Antoine Latter wrote:

...

On Mon, Jun 13, 2011 at 12:34 PM, Alexander Solla wrote:

...

On Sun, Jun 12, 2011 at 7:12 PM, Antoine Latter wrote:

...

Types from differing versions of the same module are specifically not compatible - even if they are defined identically (in this case they are different, though).

You can do one of two things:

1. Edit the package description of the package that wants the older version of parsec to allow to use the new one. Also, it helps to slightly bump the version number of the package when you do this.

2. Use the older version of parsec in your software. You already have it installed (or else the package you want to use wouldn't be able to load!). If you're using ghci you can start it with the option '-package parsec-2.1.0.1'.

I understand that types from different versions of a module are incompatible.  What I don't understand is why one module is using a new version of Parsec when it is constrained to use the "old" one (I control both modules.  Their package descriptions contain the same line).  Is this a cabal-dev bug? I'll try the "-package parsec-2.1.0.1" tip, but this is /not/ a long term solution to my problem.

I think I might be mus-understanding your problem.

Which module is producing the error message? In which package? How are you compiling this module? What should be constraining it to the older version of parsec?

I'd been assuming that you were getting this message from compiling your own modules by hand, or in GHCi.

I am working on "Lime", an unreleased module.  It depends on "Lime-Utility", which is also under my control.  Lime's package description contains the Build-Depends constraints (among many others): Lime-Utility  >=0.1  && <0.2 parsec         >=2.1 && <2.2 Lime-Utility's package description contains the Build-depends constraint: parsec         >=2.1 && <2.2

I am using cabal-dev to maintain a package database in my Lime.Blah working directory.  I get a compilation failure (based on mismatched types, based on different versions of Parsec) when I use: $ cabal-dev ghci

...

:cd src :l Lime.Data.IPAddress Interestingly, if I do: $ cabal-dev clean && cabal-dev configure && cabal-dev clean Lime.Data.IPAddress compiles.

The command 'cabal-dev ghci' does not use the cabal package description to figure out which dependencies to pull in - if the module you're loading asks for module 'A.B' it loads the most recent version found in the local cabal-devel packages database - even if that same module, when compiled with cabal, would pull in a different package. In your case I'm guessing that something you do later on with cabal-dev pulls in a package which requires parsec-3, which then causes ghci to pull in parsec-3 as its newest version. Getting a proper 'cabal ghci' that passes command-line flags to ghci (along the lines of the -package parameter I gave you above) is something that the cabal folks know people are interested in, but it isn't something we have today. Does that make sense? Antoine