Cannot install Haskell package stream-fusion-0.1.2.5: Ambiguous occurence - haskell

I'm trying to build the project Barbarosa which requires the package stream-fusion-0.1.2.5. However cabal install fails with the following
[3 of 3] Compiling Control.Monad.Stream ( Control/Monad/Stream.hs, dist/dist-sandbox-8bb5b9c9/build/Control/Monad/Stream.o )
Control/Monad/Stream.hs:136:10:
Ambiguous occurrence ‘MonadPlus’
It could refer to either ‘Control.Monad.Stream.MonadPlus’,
defined at Control/Monad/Stream.hs:124:1
or ‘GHC.Base.MonadPlus’,
imported from ‘GHC.Base’ at Control/Monad/Stream.hs:80:1-15
Control/Monad/Stream.hs:140:10:
Ambiguous occurrence ‘MonadPlus’
It could refer to either ‘Control.Monad.Stream.MonadPlus’,
defined at Control/Monad/Stream.hs:124:1
or ‘GHC.Base.MonadPlus’,
imported from ‘GHC.Base’ at Control/Monad/Stream.hs:80:1-15
I'm using GHC version 7.10.2 on OS X 10.11, installed via Haskell Platform.
It seems that the only dependency of stream-fusion is base whose version should be fine, so I'm not sure what's wrong here.

I was able to get things to compile by replacing the three occurrences of
import Data.List.Stream
with:
import Data.List
and removing stream-fusion from the build-depends: section of the cabal file.

Related

Why is GHC not importing Semigroup ((<>))

I've been given code by my lecturer that doesn't build in GHCI. As far as I know, it has been building correctly for my classmates.
The code I'm refering to is
import Data.Semigroup (Semigroup ((<>)))
GHCI is throwing this error at me
Module ‘Data.Semigroup’ does not export ‘Semigroup((<>))’
Should this work? Is there perhaps something wrong with my version of GHC? All other import statements are working.
Final Edit
Is there perhaps something wrong with my version of GHC?
Absolutely yes, there is something wrong, is too old, to be precise:
GHC-6.12 / base-4.2 (from 2010, which is the time of the Semigroup package) -- thanks so much #leftaroundabout and #Thomas M. DuBuisson for the contribution!
And that package has not the (Semigroup ((<>))) function. Hence the error you see.
Edit 2
After comments, I tried to reproduce the OP environment to reproduce the error too, I installed in stack the ghc version 7.10.3, this is how looks the stack.yaml file:
resolver: lts-6.27
system-ghc: false
packages:
- .
And after ruining a base stack project with a Main.hs file containing:
module Main where
import Data.Semigroup
main :: IO ()
main = do
putStrLn "Hello"
putStrLn "World"
the error I got is
/home/damian/test-semigroup/app/Main.hs:3:8:
Could not find module ‘Data.Semigroup’
Use -v to see a list of the files searched for.
-- While building package test-semigroup-0.1.0.0 using:
/home/damian/.stack/setup-exe-cache/x86_64-linux/Cabal-simple_mPHDZzAJ_1.22.5.0_ghc-7.10.3 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.22.5.0 build lib:test-semigroup exe:test-semigroup-exe --ghc-options ""
Process exited with code: ExitFailure 1
The same happend with older versions:
LTS 3.22 for ghc-7.10.2,
I couldt try with:
LTS 2.22 for ghc-7.8.4, published 4 years ago
Because they where to old to run with cabal
and
- LTS 0.7 for ghc-7.8.3, published 5 years ago
Because they I cannot install it in a 64bit OS...
So, to be absolutely sure I tried with all the newer LTS versions one by one, yes... one by one, It took some time but worth the shot:
LTS 13.29 for ghc-8.6.5, published today
LTS 13.19 for ghc-8.6.4, published 3 months ago
LTS 13.11 for ghc-8.6.3, published 4 months ago
LTS 12.26 for ghc-8.4.4, published 7 months ago
LTS 12.14 for ghc-8.4.3, published 9 months ago
LTS 11.22 for ghc-8.2.2, published 11 months ago
LTS 9.21 for ghc-8.0.2, published a year ago
LTS 7.24 for ghc-8.0.1, published 2 years ago
None of those ghc version could reproduce your log error, so I thought to try a typo maybe:
import Data.Semigroup (Semigroup ((<$>)))
or
import Data.Semigroup (Semigroup ((=>>)))
And those gave me your error:
/home/damian/test-semigroup/app/Main.hs:3:24: error:
Module ‘Data.Semigroup’ does not export ‘Semigroup(())’
That means, that the Data.Semigroup module exists in your ghc
Semigroup((<>)) is not part of that module
Meaning, you must have one of the oldest ghc versions...
So, I just can think that you can try:
Reinstall your ghc, and try it to run it again.
Please, consider using some tool such as stack
Check your code, look out for some typos or something odd
I stand that my first answer was close though:
Edit 1
It has been added in ghc version 8.0.1
A quick search in hoogle always helps:
Here first link is semigroup <>, (<>) :: Semigroup a => a -> a -> a
and it says:
This versions is able since May 2016, and it ghc version is 8.0.1.
To see all versions of ghc with its base versions:
https://wiki.haskell.org/Base_package
ThomasM.DuBuisson found what must have been the problem (discussion in comments): there are three different packages defining a Data.Semigroup module –
base. As of GHC-8, Haskell ships with the semigroup class and -module out of the box, so you don't need to take care for anything. See Damian Lattenero's answer for details.
semigroups. In GHC-7, there was no semigroups class in base but the semigroups package was semi-official part of the base libraries. In fact, this exact module was just copied over to base. The way to write really backwards-compatible code with semigroups is still to depend on the semigroups package: when compiling against new GHC versions, that package just uses the base module, only in old versions does it provide the module itself. See the .cabal configuration
if impl(ghc < 7.11.20151002)
-- starting with GHC 8 these modules are provided by `base`
hs-source-dirs: src-ghc7
exposed-modules:
Data.Semigroup
Data.List.NonEmpty
Semigroup is an obsolete package back from 2010. It too exports a Data.Semigroup module, but unlike the semigroups one this is not compatible with the official base module. It does have a Semigroups class, but its method is called .++. rather than <> (probably, to not clash with the operator from Data.Monoid – that is by now not an issue, because in very new versions <> is now in the prelude and already works on semigroups).
So, what happened for you is probably the following:
You tried to compile your code
GHC complained Could not find module ‘Data.Semigroup’. That's because you're running an old compiler.
At this point, what you should have done would be installing/depending on the semigroups package. Instead you installed the Semigroup package, which is unfortunately incompatible.
There are two solutions:
Use Cabal-install and allow for your old compiler. IMO this is ok, though you should be prepared to run into other dependency troubles in the future. If you do this, you need to add the semigroups package in the build-depends of your .cabal file.
Or use Stack to enforce a recent compiler. Select e.g. lts-12.14.

Text/Regex/TDFA/NewDFA/Engine.hs:13:33: parse error on input ‘#’

I have been trying to run a simple Haskell program using TDFA. The program is as follows:
import Control.Monad
import Data.Array
import qualified Data.Text as T
import Text.Regex
import Text.Regex.TDFA
import Text.Regex.Base
str = "abbbbaab" :: String
regex = "(a+)(b+)" :: String
main = do
if str (=~) :: regex then putStrLn "matched" else putStrLn "no matches"
when I try to run the above program using the command like: ghc test.hs -o test and then I am getting the following error (test.hs is the Haskell program which contains the above code):
Text/Regex/TDFA/NewDFA/Engine.hs:13:33: parse error on input ‘#’
Note that I have the latest version of TDFA installed on my pc. I did it by following ways:
ghc --make -o setup Setup.hs
Also, I did the following:
user#user-VirtualBox:~/regex-tdfa-master$ sudo cabal install regex-tdfa
[sudo] password for user:
Resolving dependencies...
All the requested packages are already installed:
regex-tdfa-1.2.2
Use --reinstall if you want to reinstall anyway.
I even tried it with the Makefile which I got from TDFA's github repository:
user#user-VirtualBox:~/regex-tdfa-master$ make
ghc -o setup --make ./Setup.hs
./setup clean
cleaning...
./setup configure --prefix=/Users/user/local/devel/trl --enable-library-profiling --user
Configuring regex-tdfa-1.2.2...
./setup build
Building regex-tdfa-1.2.2...
Preprocessing` library regex-tdfa-1.2.2...
[ 1 of 23] Compiling Text.Regex.TDFA.NewDFA.Uncons ( Text/Regex/TDFA/NewDFA/Uncons.hs, dist/build/Text/Regex/TDFA/NewDFA/Uncons.o )
...........(Skipped to make the things short here)..............................
[23 of 23] Compiling Text.Regex.TDFA ( Text/Regex/TDFA.hs, dist/build/Text/Regex/TDFA.o )
Text/Regex/TDFA.hs:60:8:
Could not find module ‘Text.Regex.Base’
Perhaps you haven't installed the profiling libraries for package ‘regex-base-0.93.2#regex_47KXx9dLqeO8MNJeizLKhP’?
Use -v to see a list of the files searched for.
Text/Regex/TDFA/ByteString.hs:24:8:
Could not find module ‘Text.Regex.Base.Impl’
Perhaps you haven't installed the profiling libraries for package ‘regex-base-0.93.2#regex_47KXx9dLqeO8MNJeizLKhP’?
Use -v to see a list of the files searched for.
Text/Regex/TDFA/CorePattern.hs:37:8:
Could not find module ‘Control.Monad.RWS’
Perhaps you haven't installed the profiling libraries for package ‘mtl-2.2.1#mtl_Aue4leSeVkpKLsfHIV51E8’?
Use -v to see a list of the files searched for.
Text/Regex/TDFA/ReadRegex.hs:13:8:
`Could not find module ‘Text.ParserCombinators.Parsec’`
Perhaps you haven't installed the profiling libraries for package ‘parsec-3.1.9#parse_EE5NO1mlYLh4J8mgDEshNv’?
Use -v to see a list of the files searched for.
Text/Regex/TDFA/String.hs:23:8:
Could not find module ‘Text.Regex.Base.RegexLike’`
Perhaps you haven't installed the profiling libraries for package ‘regex-base-0.93.2#regex_47KXx9dLqeO8MNJeizLKhP’?
Use -v to see a list of the files searched for.
Text/Regex/TDFA/TDFA.hs:10:8:`
Could not find module ‘Control.Monad.State’
Perhaps you haven't installed the profiling libraries for package ‘mtl-2.2.1#mtl_Aue4leSeVkpKLsfHIV51E8’?
Use -v to see a list of the files searched for.
Makefile:16: recipe for target 'build' failed
make: *** [build] Error 1
user#user-VirtualBox:~/regex-tdfa-master$
However, nothing worked. Hence, any help would be so appreciated...
Text/Regex/TDFA/NewDFA/Engine.hs:13:33: parse error on input ‘#’
On an initial note, this error points to a module of the regex-tdfa package, so you should have gotten it when building the package, rather than when building your test.hs, unless you were trying to build test.hs after putting it within the package source tree. In any case, line 13 of the mentioned file is:
import GHC.Prim(MutableByteArray#,RealWorld,Int#,sizeofMutableByteArray#,unsafeCoerce#)
The # names require the MagicHash GHC extension to be enabled. As there is no {-# LANGUAGE MagicHash #-} pragma at the beginning of the file, one should assume the extension is enabled through the .cabal file of the package, and that is indeed the case. That being so, your problem seems to be that you are attempting use the package modules straight from the source tree, without using an appropriate build tool such as Cabal. (Note that if you did successfully run cabal install regex-tdfa there should be no need of dealing with the source tree: ghc --make -o test test.hs should be enough.)
P.S.: There is an error in your test.hs. The last line should be...
if str =~ regex then putStrLn "matched" else putStrLn "no matches"
(I did manage to run it after this correction.)
It looks like you are compiling your program from within Regex-TDFA source code. I am able to reproduce your problem if I do cabal unpack regex-tdfa && cd regex-tdfa-1.2.2 && ghc --make test.hs.
The error happens because when GHC finds Regex-TDFA source files in the current directory, it just picks them and tries to compile, as if they were ordinary source files belonging to your project. However, Regex-TDFA cannot be built with simple ghc --make: in order to build it, you have to run cabal first. Cabal will read regex-tdfa.cabal file that contains the list of the necessary GHC extensions.
In particular, parse error happens because GHC extension MagicHash is missing (that's where the hash # comes from).
The "fix" is to move your test.hs to some other location: then GHC will use system package for Regex-TDFA.

Craft3e: cabal install not in scope: Applicative

I am attempting to install the code for "Haskell: The Craft of Functional Programming", 3rd edition.
I'm using GHCi, version 7.6.3 on Centos version 7.
Then:
cabal unpack Craft3e
cd Craft3e-0.1.1.0/
cabal install
...
[29 of 67] Compiling CalcParseLib ( Calculator/CalcParseLib.hs, dist/build/CalcParseLib.o )
Calculator/CalcParseLib.hs:132:10:
Not in scope: type constructor or class `Applicative'
Failed to install Craft3e-0.1.1.0
cabal: Error: some packages failed to install:
Craft3e-0.1.1.0 failed during the building phase. The exception was:
ExitFailure 1
I have attempted this installation multiple times, but cannot
overcome this error.
Could I use something other than "cabal install"?
I have plenty to learn about Haskell before I get to this example,
but it would be great to know the installation is fine! :)
You have three options:
Install an older version of the Craft3e package, with e.g. cabal unpack Craft3e-0.1.0.10.
Find Calculator/CalcParseLib.hs in the source files you have downloaded with cabal unpack and add a...
import Control.Applicative
... line next to the other import lines at the beginning. I suspect you will have to do the same with other modules, if the same error shows up elsewhere after you do this change, and there might be other issues of a similar nature.
Install a newer version of GHC (7.6.3 is from 2013). Though the default CentOS repositories won't offer that, there are other options, such as an unofficial Fedora repository and a manual installation. See this page for instructions.
#3 is the definitive solution. If you just want to get started with the book right now, though, you can go for #1 and leave the reinstall for later.
For the sake of reference, here is a brief explanation of the problem (I will use some unfamiliar terms, but you will soon enough learn about them as you study Haskell). There is an important type class called Applicative which, for historical reasons, wasn't as well integrated with the rest of the core libraries as it should be. This situation was corrected in GHC 7.10, which both included Applicative in the Prelude (the module which is imported by default in Haskell programs) and made it necessary to add Applicative instances in a number of places where they were missing. The code in the Craft3e package was updated so that these Applicative instances were in place (cf. this entry in the book's blog), but the import Control.Applicative line, which would be necessary to make the updated code work in older GHCs that do not have Applicative in the Prelude, wasn't added, leading to the error that you are seeing.

Cabal fails to install dependencies, but can install them if asked directly

I've seen a very strange recurring problem with Cabal that's interfering with my ability to get repeatable Haskell builds. I have a cabal project with a sandbox. If I do cabal install, I get errors of the form
Y failed during the building phase. The exception was:
ExitFailure 1
X depends on Y which failed to install.
where X is a direct dependency of my project and Y is some transitive dependency. However, if I just type cabal install X, then it works!
Here's a specific example: my project depends on the interpolate package. When I do cabal install --allow-newer, I get errors like this:
Resolving dependencies...
Configuring haskell-src-meta-0.6.0.9...
Building haskell-src-meta-0.6.0.9...
Preprocessing library haskell-src-meta-0.6.0.9...
[1 of 6] Compiling Language.Haskell.TH.Instances.Lift ( src/Language/Haskell/TH/Instances/Lift.hs, dist/dist-sandbox-d2861272/build/Language/Haskell/TH/Instances/Lift.o )
[2 of 6] Compiling Language.Haskell.Meta.Syntax.Translate ( src/Language/Haskell/Meta/Syntax/Translate.hs, dist/dist-sandbox-d2861272/build/Language/Haskell/Meta/Syntax/Translate.o )
[3 of 6] Compiling Language.Haskell.Meta.Parse ( src/Language/Haskell/Meta/Parse.hs, dist/dist-sandbox-d2861272/build/Language/Haskell/Meta/Parse.o )
[4 of 6] Compiling Language.Haskell.Meta.Parse.Careful ( src/Language/Haskell/Meta/Parse/Careful.hs, dist/dist-sandbox-d2861272/build/Language/Haskell/Meta/Parse/Careful.o )
[5 of 6] Compiling Language.Haskell.Meta ( src/Language/Haskell/Meta.hs, dist/dist-sandbox-d2861272/build/Language/Haskell/Meta.o )
[6 of 6] Compiling Language.Haskell.Meta.Utils ( src/Language/Haskell/Meta/Utils.hs, dist/dist-sandbox-d2861272/build/Language/Haskell/Meta/Utils.o )
src/Language/Haskell/Meta/Utils.hs:67:1:
Duplicate instance declarations:
instance Typeable Q
-- Defined at src/Language/Haskell/Meta/Utils.hs:67:1
instance Typeable Q -- Defined in ‘Language.Haskell.TH.Instances’
src/Language/Haskell/Meta/Utils.hs:71:1:
Duplicate instance declarations:
instance Typeable QuasiQuoter
-- Defined at src/Language/Haskell/Meta/Utils.hs:71:1
instance Typeable QuasiQuoter
-- Defined in ‘Language.Haskell.TH.Instances’
Failed to install haskell-src-meta-0.6.0.9
...
haskell-src-meta-0.6.0.9 failed during the building phase. The exception was:
ExitFailure 1
interpolate-0.1.0 depends on haskell-src-meta-0.6.0.9 which failed to install.
However, if I proceed to type cabal install interpolate-0.1.0, the installation succeeds and I'm able to keep installing my project.
This is frustrating because I have to "manually" install several packages before I can get all my dependencies installed. The fact that the original installations fail with compiler errors seems to suggest that the compiler is configured differently somehow?
I'm using GHC 7.8.3 and cabal-install 1.22.4.0 (version 1.22.3.0 of the Cabal library). Many thanks for any help!
Actually it's not a problem with the version of haskell-src-meta but rather with the version of its dependency th-orphans.
haskell-src-meta (versions 0.6.0.8 and 0.6.0.9) has an upper bound th-orphans <0.12.
With --allow-newer you told Cabal to ignore version upper bounds, so Cabal decided to use th-orphans version 0.12.0, since it's newer and presumably better. But, in fact, haskell-src-meta really does not build with th-orphans version 0.12.0, as you found out.
Unrestricted use of --allow-newer is likely to run into this kind of problem in general. It's better to specify the packages whose upper bounds you want to ignore with --allow-newer=base,containers,..., though in some cases doing so can be rather tedious.
In the first sentence of your question you mentioned repeatable builds. If that is what you want, there is no substitute for simply recording the exact versions that you want of all of your direct and indirect dependencies.

Ambiguous module name `Prelude'

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.

Resources