[Haskell-cafe] Unexpected type error
aslatter at gmail.com
Mon Jun 13 22:27:32 CEST 2011
On Mon, Jun 13, 2011 at 1:00 PM, Alexander Solla <alex.solla at gmail.com> wrote:
> On Mon, Jun 13, 2011 at 10:45 AM, Antoine Latter <aslatter at gmail.com> wrote:
>> On Mon, Jun 13, 2011 at 12:34 PM, Alexander Solla <alex.solla at gmail.com>
>> > On Sun, Jun 12, 2011 at 7:12 PM, Antoine Latter <aslatter at gmail.com>
>> > 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-22.214.171.124'.
>> > 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-126.96.36.199" 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
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?
More information about the Haskell-Cafe