[Haskell-cafe] Cabal dependencies
jose.lopes at ist.utl.pt
Sat Oct 6 23:10:27 CEST 2012
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.
>> On 06-10-2012 19:08, Yuras Shumovich wrote:
>>> On Sat, 2012-10-06 at 18:25 +0200, José Lopes wrote:
>>>> But, wouldn't it be possible for xmobar to use mtl-220.127.116.11 and for
>>>> parsec to use mtl-2.1.1, while xmobar would use this parsec version?
>>>> In this case, I am assuming that mtl-18.104.22.168 and mtl-2.1.1 are
>>>> considered two different libraries.
>>> Usually it leads to "strange" compilation errors.
>>> 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:
José António Branquinho de Oliveira Lopes
Instituto Superior Técnico
Technical University of Lisbon
More information about the Haskell-Cafe