Improving the "Get Haskell Experience"

Michael Snoyman michael at
Thu Jul 23 13:42:52 UTC 2015

On Thu, Jul 23, 2015 at 1:15 AM Heinrich Apfelmus <apfelmus at>

> Mark Lentczner wrote:
> > *tl;dr: We'd like to incorporate stack into Haskell Platform, and stop
> > shipping pre-built packages, so we banish cabal hell, and have a single
> > common way to 'get Haskell' that just works.*
> >
> > [..]
> >
> > We think this plan solves many different community needs:
> >
> >    - We have a clear way to "get Haskell" that works for a wide variety
> of
> >    use cases.
> >    - HP installer gets much smaller, and about as minimal as a working
> >    installation can get.
> >    - By leaving most packages out of the global database, users of
> >    cabal-install, will now have far fewer problems. Sandbox builds
> should now
> >    never give users "cabal hell" like warnings.
> >    - By building and installing the Platform packages into it's own
> package
> >    db, users get the benefit of building and installing these common
> packages
> >    only once per system, yet can easily bypass them for any given
> project if
> >    desired.
> >    - Since the Platform packages are now built and installed as needed,
> >    installing on smaller systems or servers without OpenGL will work.
> Sounds great to me! Personally, I do not mind how the Haskell Platform
> achieves these goals; I will simply adapt to whatever tools the platform
> happens to install on my machine.
> Hopefully, they come with suitable documentation. For instance, one
> thing I don't understand about  stack  yet is in which location it
> "magically" installs GHC and packages, and how I can invoke `ghci` from
> these locations. Somehow, I was unable to understand this from the FAQ.
I think this FAQ entry should help[1] on the first question:

> Note that stack setup installs GHC into
~/.stack/programs/$platform/ghc-$version/ and not a global location.

For the second question: either `stack ghci` or `stack exec ghci` should
achieve what you're looking for. The former is a bit more experimental, and
does more intelligent stuff at the project level as far as loading up your
code. The latter simply runs the ghci command with appropriate PATH and
GHC_PACKAGE_PATH environment variables set.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list