[Haskell-cafe] Cabal dependencies

[Yuras Shumovich]

On Sat, 2012-10-06 at 22:40 +0200, José Lopes wrote:
> OK. Got it!
> 
> Do you have any suggestions to install xmobar in this particular case?

In case of executables I usually rm -rf ~/.ghc, cabal install,
and rm -rf ~/.ghc again. Executables are still here (in ~/.cabal/bin),
but all libraries are lost. Warning: it may break your development
environment, so make sure you know what you are doing.

Better solution could be sandbox tools like cabal-dev. They alloy you to
setup development environment per project.

> 
> Thanks,
> José
> 
> On 06-10-2012 19:08, Yuras Shumovich wrote:
> > On Sat, 2012-10-06 at 18:25 +0200, José Lopes wrote:
> >> OK.
> >>
> >> But, wouldn't it be possible for xmobar to use mtl-2.0.1.0 and for
> >> parsec to use mtl-2.1.1, while xmobar would use this parsec version?
> >> In this case, I am assuming that mtl-2.0.1.0 and mtl-2.1.1 are
> >> considered two different libraries.
> > Usually it leads to "strange" compilation errors.
> >
> > E.g.
> > Package A:
> >    data AA = AA String
> >    func0 :: Int -> AA
> >    func0 n = AA $ replicate n "A"
> >    func1 :: AA -> Int
> >    func1 (AA str) = length str
> >
> > Package B:
> >    import A
> >    func2 :: AA -> Int
> >    func2 aa = func1 + 1
> >
> > Package C:
> >
> >    import A
> >    import B
> >    func3 :: Int -> Int
> >    func3 n = func2 $ func0 n
> >
> > If C and B are compiled with different versions of C,
> > then func3 will not compile. Compiler will say that
> > AA returned by func0 doesn't match AA expected by func2
> >
> > More real examples:
> > http://stackoverflow.com/questions/11068272/acid-state-monadstate-instance-for-update
> > http://stackoverflow.com/questions/12576817/couldnt-match-expected-type-with-actual-type-error-when-using-codec-bmp/12577025#12577025
> >
> >
> >> Thanks,
> >> José
> >
>