[Haskell-cafe] Unexpected type error

[Antoine Latter]

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>
>> wrote:
>> >
>> >
>> > 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-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