Thanks! On 06-10-2012 23:07, Yuras Shumovich wrote:
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-f... http://stackoverflow.com/questions/12576817/couldnt-match-expected-type-with...
Thanks, José
-- José António Branquinho de Oliveira Lopes Instituto Superior Técnico Technical University of Lisbon