3
votes

I'm getting an error that says the module doesn't exist when I try to runhaskell. It's odd because I try to install it first and says its up to date. Any idea how to fix this? enter image description here

2
You probably need to add a dependency in your cabal file. - dfeuer
i.imgur.com/nNaeODy.png I added this to my cabal file and ran cabal configure, cabal build, and cabal install. I got this error at cabal install: i.imgur.com/6zATtvu.png - Matthew Lu
runhaskell calls GHC which doesn't expose modules by default. Why are you using runhaskell if you have a cabal file? Can you not cabal run? - Thomas M. DuBuisson
The license error just says you need a license file touch LICENSE to make a blank one. I dislike this cabal behavior but am sure there is a long argument on the issue tracker. - Thomas M. DuBuisson
How can I make ghc expose modules? I'd rather use runhaskell - Matthew Lu

2 Answers

4
votes

You could try creating the package environment in the local directory that holds your project, like this:

c:\Users\...\ex1haskell> cabal install --lib --package-env . QuickCheck

This should create a file of the form .ghc.environment.xxx in ex1haskell, which hopefully should be picked up by runhaskell/ghci/ghc invocations.

In ghci sessions, a sign that the environment is being picked up is the following message while starting:

Loaded package environment from ...

When the --package-env location is not given explicitly, a default location is used. According to the docs:

By default, it is writing to the global environment in ~/.ghc/$ARCH-$OS-$GHCVER/environments/default. v2-install provides the --package-env flag to control which of these environments is modified.

But it seems that runhaskell is having problems to find the environment file in that default location.

Note. When creating a package environment, it's possible to specify multiple packages simultaneously, like this:

cabal install --lib --package-env . QuickCheck random aeson transformers

Also, package environments are just text files, so local environments can be deleted and recreated at will. The actual package binaries reside elsewhere and can potentially be reused by cabal.

2
votes

A Common Environment

It is hard to debug if/when the actual tooling differs so let's first get a unified setup. I'll use docker to get GHC 8 and Cabal 3.x:

docker run --rm -it haskell bash

Understand that this isn't arbitrary or even preemptive. What you have shown - cabal install --lib ... and runhaskell ... does work for sane tool installations. You might have a bad installation or an old version of a tool that has different behavior.

Running a single file with runhaskell

Now we need a project:

root@8a934c302dba:/# mkdir Ex1
root@8a934c302dba:/# cd Ex1
root@8a934c302dba:/Ex1# cat <<EOF >Main.hs
> import Test.QuickCheck
>
> main :: IO ()
> main = print =<< (generate arbitrary :: IO Int)
> EOF

And test failure:

root@8a934c302dba:/Ex1# runhaskell Main.hs

Main.hs:1:1: error:
    Could not find module `Test.QuickCheck'
    Use -v (or `:set -v` in ghci) to see a list of the files searched for.
  |
1 | import Test.QuickCheck

And install the library:

root@8a934c302dba:/Ex1# cabal update && cabal install --lib QuickCheck

And successful run:

root@8a934c302dba:/Ex1# runhaskell Main.hs
15

So my comment above was wrong - we don't need to explicitly list the package as it is already exposed after installation.