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é > > > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe