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

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.

Related

How does stack resolve dependencies? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
How does stack resolve dependecy conflicts?
I just started off with Haskell and I have few questions on how stack resolves dependencies.
Let's say my project requires lib A and lib B.
Internally, lib A requires lib X-1.9.0 and lib B requires lib X-2.0.0, how would stack resolve this?
stack documentation says they use snapshots to resolve conflicts, how does that work? Does it mean authors of lib A and lib B decide on a version of lib X which works with both of them? If so, what happens when I use a newer version of lib A or lib B or if either of them are not in the snapshots?
How are snapshots actually made?
Stack by default installs packages globally. What happens when a Project A requires lib Y-1.0 and Project B requries lib Y-1.1? How does this gets taken care of?
How does one use packages at "stackage.org"?
I was trying to install beam-core and google took me to https://www.stackage.org/package/beam-core where there's no mention of the command which installs it or what is the latest version. I could not find the version number anywhere expect in github releases.
With both pip and npm, it's quite straight forward and all the information on how to install and use is available on package's page. For example both,
https://pypi.org/project/bencode.py/
https://www.npmjs.com/package/projects
contains version number and install command, even though they are quite obvious.
I often get errors related to 'stack-configuration' when I try to install a package. I don't what 'stack-configuration' is?
What does all these errors mean and how to resolve them in context with all the above questions?
Performing stack install beam-core or stack repl --package beam-core --package beam-sqlite --package sqlite-simple --package beam-migrate --package text results in
`Users/username/Documents/beam-learn/beam-learn.cabal was modified manually. Ignoring /Users/username/Documents/beam-learn/package.yaml in favor of the cabal file.
If you want to use the package.yaml file instead of the cabal file,
then please delete the cabal file.
Stack has not been tested with GHC versions above 8.6, and using 8.8.2, this may fail
Stack has not been tested with Cabal versions above 2.4, but version 3.0.1.0 was found, this may fail
Error: While constructing the build plan, the following exceptions were encountered:
In the dependencies for hashable-1.2.7.0:
base-4.13.0.0 from stack configuration does not match >=4.4 && <4.13 (latest matching version is 4.12.0.0)
needed due to beam-core-0.8.1.0 -> hashable-1.2.7.0
Some different approaches to resolving this:
* Set 'allow-newer: true' in /Users/username/.stack/config.yaml to ignore all version constraints and build anyway.
* Build requires unattainable version of base. Since base is a part of GHC, you most likely need to use a different GHC version with the matching base.
Plan construction failed.`
For question #1:
Stack is designed around the concept that, for a given Stack project, only one version of a given package will be used. So, if you have a project that requires libraries A and B, and each of them depend on different versions of library X, then you cannot build your project as-is with Stack.
Snapshots are constructed by building collections of versions of packages (with exactly one version per package) such that all inter-package dependencies can be satisfied. This is done by the Stackage "curators" as described here using the curator tool. The curator tool uses the index of packages available on Hackage to construct a set of versions of packages (exactly one version per package) that are compatible in the sense that all package interdependencies are satisfied.
So, the library authors don't need to decide on a version of X that works with both. Rather, they need to specify a range of versions of X that their package works with, and the curator tool selects the most recent version of X that works with both their packages, as well as everyone else's packages that depend on X or on which X has a dependency.
If you want to use a newer version of library A or B that isn't in the snapshot, you add it as an extra dependency in your build plan (i.e., in the extra-deps section of your stack.yaml file). If the new version can't be built with the snapshot's version of X, you need to add an extra dependency for X too. If that breaks other packages and you can't find a set of extra dependencies that resolves all conflicts, you're out of luck.
In practice, because most packages have relatively generous ranges of dependencies and, for actively maintained packages, those ranges are generally kept up to date with newer compatible dependency versions, you don't often run into unresolvable conflicts, but it does happen.
For question #2:
Stack doesn't really install packages globally. It installs snapshot packages in a global cache (on Linux, in the directory ~/.stack) organized by snapshot. So, multiple versions can be installed in this cache under different snapshots, and the project will use whichever version is appropriate for the project's selected snapshot.
For question #3:
On the Stackage page for beam-core, you can see that the most recent LTS snapshot that contains it is lts-14.27. You can create a new project using this resolver with:
$ stack new --resolver lts-14.27 my-beam-project
To add beam-core to your project, edit my-beam-project/package.yaml and add a dependency:
dependencies:
- base >= 4.7 && < 5
- beam-core # <-- add this
Now, run stack build in your my-beam-project directory:
$ cd my-beam-project
$ stack build
It will build beam-core and all its dependencies which takes a few minutes, unless you've built beam-core for this snapshot before.
You can fiddle around with beam-core by running stack ghci in your project:
$ stack ghci
...
Configuring GHCi with the following packages: my-beam-project
GHCi, version 8.6.5: http://www.haskell.org/ghc/ :? for help
[1 of 2] Compiling Lib ( /u/buhr/src/overflow/my-beam-project/src/Lib.hs, interpreted )
[2 of 2] Compiling Main ( /u/buhr/src/overflow/my-beam-project/app/Main.hs, interpreted )
Ok, two modules loaded.
Loaded GHCi configuration from /tmp/haskell-stack-ghci/e5a80991/ghci-script
*Main Lib> import Database.Beam
*Main Lib Database.Beam> :t fieldName
fieldName
:: Functor f =>
(text-1.2.3.1:Data.Text.Internal.Text
-> f text-1.2.3.1:Data.Text.Internal.Text)
-> TableField table ty -> f (TableField table ty)
*Main Lib Database.Beam>
and, of course, you can add code in src/Lib.hs and/or app/Main.hs using the beam-core package.
For question #4:
As noted in a comment, I believe the problem you're encountering is that the most recent LTS is lts-15.3, and beam-core is not currently being built for this snapshot.
Because beam-core was built for previous snapshots but isn't being built for the current snapshot, there's probably a good reason it's been left out. In this case, it looks like the maintainer has not upgraded it to work with the latest GHC versions. Specifically, the latest version of beam-core-0.8.0.0 requires a version of hashable < 1.3, but the latest version satisfying that constraint is hashable-1.2.7.0 which requires base < 4.13. And, while it's far from obvious, that means it doesn't work with GHC 8.8, only GHC 8.6, so you have to go back to a GHC 8.6-series Stackage snapshot.

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.

Haskell cannot import GHC.SrcLoc

I can't get module "GHC.SrcLoc" in package "srcloc" on Ubuntu Haskell ...
-- "import" works on Windows, but not on Ubuntu 14.04
-- Module name is "GHC.SrcLoc"
-- Cabal build error below
Take 2: tried adding package "srcloc" to Cabal dependencies
^ Adding "srcloc" to dependencies causes "cabal configuration failed". ^
GHCI version...
$ ghci --version
The Glorious Glasgow Haskell Compilation System, version 7.6.3
Please help
https://hackage.haskell.org/package/base-4.8.2.0/docs/GHC-SrcLoc.html
My Haskell Code...
https://github.com/JohnReedLOL/HaskellPrintDebugger
* Attempt #1 *
:~/IdeaProjects/IntelliJHaskellPrintDebugger$ cabal install srcloc
Resolving dependencies...
All the requested packages are already installed:
srcloc-0.5.1.0
Use --reinstall if you want to reinstall anyway.
* Attempt #2 *
-- Tried replacing "import GHC.SrcLoc" with "import Data.Loc", but failed.
-- Tried adding "srcLock" to "build-depends" in .cabal, but failed.
^ Hopeless
Since Data.SrcLoc is a part of the GHC distribution and it wasn't added until (I believe) GHC 7.10.1, it will not exist in GHC 7.6.3. If you install the latest version of GHC, this should work fine.
The package you are seeing that is called srcloc appears to be unrelated to what you want, and does not provide the GHC.SrcLoc module. The GHC.SrcLoc module is instead provided by the GHC base standard library, which is included in (and requires) a newer version of GHC.
Newer versions of GHC also include a lot of other nice features that 7.6.3 (which was released more than 2 years ago) doesn't have.
You also mentioned stack traces, so you might be interested in this.
You must install the srcloc package; in the simple case where you are not using sandboxes, this is done by running cabal install srcloc at the command line.

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

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.

Cabal failing to install vector-space package

When I try to install the spacepart package using cabal install it tries to compile a dependency vector-space but when vector-space tries to compile a module it exports "Data.LinearMap" I get the error "Not in scope type constructor or class "HasTrie". After I did some digging HasTrie is a class exported by the MemoTrie package. Thing is I have MemoTrie installed and MemoTrie exports "HasTrie". What is wrong here?
Also this stack overflow post doesnt help so this isnt a duplicate question: Haskell package vector-space fails at compile time
-Thank you for your time
As far as I can see from browsing on Hackage, spacepart is fixed to use a very old version of vector-space (0.5.*), and that version's Data.LinearMap contains the suspicious import line
import Data.MemoTrie ((:->:)(..))
which simply doesn't import HasTrie. My guess is that at some time in the past, this actually worked, because (:->:) is a data family defined inside HasTrie, but that GHC has since been changed so it doesn't.
Possible dirty fix: I note that until 0.5.2, it simply says
import Data.MemoTrie
I just tried installing with
cabal install spacepart vector-space-0.5.2
and it seemed to work.

Resources