While evaluating the line "import Control.Monad.State" in a Haskell module, GHC gives me the following error:
Could not find module `Control.Monad.State':
it was found in multiple packages: monads-fd-0.0.0.1 mtl-1.1.0.2
Failed, modules loaded: none.
How do I resolve this conflict?
You have several options. Either:
ghc-pkg hide monads-fd. This will cause GHC and GHCi to ignore the presence of the monads-fd by default until you later ghc-pkg expose monads-fd, but software installed by Cabal will still be able to build against it.
Use the {-# LANGUAGE PackageImports #-} pragma, and change your import statement to import "mtl" Control.Monad.State.
Use Cabal to build your project, and specify mtl in the Build-depends line.
The first is best for casual hacking, and the last is best for production builds.
These all assume you want the mtl module and not the monads-fd module; otherwise swap them.
Both packages implement Control.Monad.State and GHC does not know which implementation it should prefer, so you need to hide one of the packages from GHC. Seems like the -ignore-package <name> GHC flag might help you here.
Related
Am working through Real World Haskell and am trying to install regex-posix-0.95.2 from an untar[ed] package by simplying running
cabal install
I then see:
Text/Regex/Posix/Wrap.hsc:141:1: error:
Could not find module ‘Text.Regex.Base.RegexLike’
There are files missing in the ‘regex-base-0.93.2’ package,
try running 'ghc-pkg check'.
Use -v to see a list of the files searched for.
|
141 | import Text.Regex.Base.RegexLike(RegexOptions(..),RegexMaker(..),RegexContext(..),MatchArray)
Despite the fact that I can load this in ghci with
Prelude> :module Text.Regex.Base.RegexLike
Prelude Text.Regex.Base.RegexLike>
Prelude> import Text.Regex.Base.RegexLike(RegexOptions(..),RegexMaker(..),RegexContext(..),MatchArray)
Prelude Text.Regex.Base.RegexLike>
and see it in the module-system.
[warrick#warrick-pc regex-posix-0.95.2]$ ghc-pkg find-module Text.Regex.Base.RegexLike
/usr/lib/ghc-8.6.2/package.conf.d
regex-base-0.93.2
Why is this failing?
What are some more general tips and tricks when trying to debug cabal failures you'd recommend (as this is one instance of many issues I'm consistently having with Cabal)?
This is a linking issue. For example, some distributions like Arch use dynamic linking by default, without static libraries, but without additional configuration, cabal tries to link statically, which results in the kind of message you are seeing. For more information: https://wiki.archlinux.org/index.php/Haskell
I have two packages that provide modules with the same name. When I try to load the module I get an error
Ambiguous interface for ....: It was found in multiple packages.
What should I do to resolve this?
To be specific, both the cryptonite package and crypto-api package provide modules with the name Crypto.Random. How can I specify which package I want to load the module from?
If you happen to be using ghc >= 8.2 and cabal-install >= 2.0, another option is renaming the conflicting modules in the mixins section of the cabal file:
build-depends: base >=4.10 && <4.11,
cryptonite >= 0.24,
crypto-api >= 0.13.2
mixins:
cryptonite (Crypto.Random as CryptoniteCrypto.Random),
crypto-api (Crypto.Random as CryptoAPICrypto.Random)
You can then import the renamed modules:
module Main where
import CryptoniteCrypto.Random
import CryptoAPICrypto.Random
One thing to take into account when renaming this way is that modules that haven't been explicitly renamed become inaccessible.
In fact, ability to rename modules seems to exist since GHC 7.10, through the -package flag and the reexported-modules cabal section. reexported-modules works at declaration-time (when publishing a package) while mixins works at use-time (when depending on a package).
You can use the PackageImports language pragma and explicitly pick the package you mean in your import statement like so:
import "cryptonite" Crypto.Random
Alternatively if you have both installed but are only using one of them, you could explicitly list the dependencies you use in a cabal file and build via cabal.
Suppose I have a library packaged and built using Cabal, and some module Internal is not in my cabal file's Exposed-modules. Does it then make any difference if I specify a pragma
{-# OPTIONS_HADDOCK hide #-}
at the top of Internal.hs, or is it already automatically hidden according to Haddock?
If it does make a difference, what effect does it have?
It does make a difference if the haddocks of the package are created with the --internal flag to cabal haddock.
$ cabal help haddock
Usage: cabal haddock [FLAGS]
Flags for haddock:
-h --help Show this help text
-v --verbose[=n] Control verbosity (n is 0--3, default verbosity
level is 1)
<snip>
--executables Run haddock for Executables targets
--internal Run haddock for internal modules and include all
symbols
<snip>
If the haddocks are created without the --internal flag, the hide module attribute has no effect: no documentation is created for the module anyway.
If --internal is given, then documentation is created for non-exposed modules except those that specify the hide attribute.
In other words, documentation is generated if hide is not set and either --internal is specified or the module is exported.
The use of --internal for cabal haddock can be specified with cabal install --haddock-internal, or when manually invoking cabal haddock, or with the runhaskell ./Setup.hs ... interface.
Most people just run cabal install with the default options, so only few would observe the difference.
I'd like to use Data.HashSet in Haskell. So I put import Data.HashSet at the beginning of my program. GHCi complains: Could not find module Data.HashSet.
My questions are:
How can I get Data.HashSet to work?
I've read somewhere that this is part of a hidden module or package. Why is the module hidden? Does "hidden" mean that I should not use it?
If I should not use it, is there a better alternative for a haskell data structure with a near-constant lookup time?
Data.HashSet is a module in the unordered-containers package, and also in the hashmap package. If you have either package installed,
import Data.HashSet
should work out of the box, since it is an exposed module of both packages. To install it (using unordered-containers, since that is the commonly used one),
cabal update
cabal install unordered-containers --dry-run
-- check that it wouldn't reinstall anything, if all's fine
cabal install unordered-containers
I get this when i want to recompile xmonad to change the configuration:
Implicit import declaration:
Ambiguous module name `Prelude':
it was found in multiple packages: base haskell98-2.0.0.0
Xmonad was installed via pacman. When i got this error i removed xmonad from pacman and then tried to cabal install xmonad. I got the above error again but i was able to solve it by removing haskell98 from the cabal file.
Now i want to reconfigure xmonad with MOD-Q the error reappears and i have no clue how to fix this. Any help appreciated.
I use GHC version 7.0.3 (from Haskell platform)
Try this:
ghc-pkg hide haskell98
In my case hiding haskell98 unfortunately was insufficient, I had to remove the obsolete haskell98 from the build-depends list in my .cabal build file (keeping the base >= 4 of course).
It read before:
build-depends:
base >= 4,
haskell98
... and then ...
build-depends:
base >= 4
With that the error message "Ambiguous module name `Prelude'" above disappeared.
See this GHC bug ticket on the same subject:
GHC starting with version 7.2.1 will not support using the haskell98
package and the base package at the same time. The haskell-src package
has both of these in its build-depends, so it will need to be
modified. Most of the time, what you want to do is remove haskell98
from build-depends, and fix up any imports of Haskell 98 modules to
point to their base equivalents.
The bug ticket was closed (without a fix), and the original filer responded:
Yes, removing haskell98 from .cabal file seems to have fixed it - it
did compile without errors. It looks like it didn't have any imports
to haskell98, because according to comment in .cabal file.