I don't have any plans to work on it myself in the near future and I don't know of anyone who is but patches are welcome and I'd be happy to help on IRC.

PR: #911

(I wonder when ghc-mod is available for GHC-8.2.1)????

This is blocking on cabal-helper support for Cabal-2.0 currently.

Most of the boring busy work on that front is already done, the CI is green for all currently supported Cabal versions and we have a straight forward test case which fails with Cabal-2 but works with older versions. Basically removeInplaceDeps needs to be adapted to Cabal-2's way of doing inplace dependencies.

Firstly we need to support internal libraries which the code currently just ignores and secondly we need to figure out what to do when we get backpack stuff (ModuleRenaming etc.)

The current implementation is a hack since we're inlining the GHC options for multiple components into one GHC invocation. That worked pretty well before backpack but now -package flags can specify module renamings which we can't express just by merging include dir (-i) AFAICT and other options in the right order as we were doing before.

Looks like that cabal-helper:master now works with Cabal-2.0 and GHC-8.2.2 🎉

Hi, it's a kind inquiry on what's remained to be done for it to support ghc 8.2.2?

@HuStmpHrrr and everyone else: you can now build ghc-mod for 8.2.2 with cabal-helper master, as outlined here:

#922 (comment)

I have it working successfully on NixOS.

@mrkgnao Can you share the expression you're using? I can't seem to find a combination that works. Thanks.

I use rien (which is just a few Nix scripts) to do the overriding of cabal-helper with my local checkout, which essentially copies what Gabriel does here.

I then just add ghc-mod as a dependency in shell.nix for my projects, like so. This should be easy to replicate in your setup. :)

ghc-mod just has a couple fiddly dependencies removed (e.g. shelltest):

{ mkDerivation, base, binary, bytestring, Cabal, cabal-doctest
, cabal-helper, containers, criterion, deepseq, directory
, djinn-ghc, doctest, extra, fclabels, filepath, ghc, ghc-boot
, ghc-paths, ghc-syb-utils, haskell-src-exts, hlint, hspec
, monad-control, monad-journal, mtl, old-time, optparse-applicative
, pipes, process, safe, semigroups, split, stdenv, syb
, template-haskell, temporary, text, time, transformers
, transformers-base
}:
mkDerivation {
  pname = "ghc-mod";
  version = "5.8.0.0";
  src = ./.;
  isLibrary = true;
  isExecutable = true;
  enableSeparateDataOutput = true;
  setupHaskellDepends = [
    base Cabal cabal-doctest containers directory filepath process
    template-haskell transformers
  ];
  libraryHaskellDepends = [
    base binary bytestring cabal-helper containers deepseq directory
    djinn-ghc extra fclabels filepath ghc ghc-boot ghc-paths
    ghc-syb-utils haskell-src-exts hlint monad-control monad-journal
    mtl old-time optparse-applicative pipes process safe semigroups
    split syb template-haskell temporary text time transformers
    transformers-base
  ];
  executableHaskellDepends = [
    base binary deepseq directory fclabels filepath ghc monad-control
    mtl old-time optparse-applicative process semigroups split time
  ];
  testHaskellDepends = [
    base cabal-helper containers directory doctest fclabels filepath
    ghc ghc-boot hspec monad-journal mtl process split temporary
    transformers
  ];
  testToolDepends = [ ];
  benchmarkHaskellDepends = [
    base criterion directory filepath temporary
  ];
  homepage = "https://github.com/DanielG/ghc-mod";
  description = "Happy Haskell Hacking";
  license = stdenv.lib.licenses.agpl3;
}

cabal-helper is vanilla cabal2nix:

{ mkDerivation, base, bytestring, Cabal, cabal-install, containers
, directory, exceptions, filepath, ghc-prim, mtl, process
, semigroupoids, stdenv, template-haskell, temporary, transformers
, unix, unix-compat, utf8-string
}:
mkDerivation {
  pname = "cabal-helper";
  version = "0.8.0.0";
  src = ./.;
  isLibrary = true;
  isExecutable = true;
  setupHaskellDepends = [ base Cabal directory filepath ];
  libraryHaskellDepends = [
    base Cabal directory filepath ghc-prim mtl process semigroupoids
    transformers unix unix-compat
  ];
  executableHaskellDepends = [
    base bytestring Cabal containers directory exceptions filepath
    ghc-prim mtl process template-haskell temporary transformers unix
    unix-compat utf8-string
  ];
  testHaskellDepends = [
    base bytestring Cabal directory exceptions filepath ghc-prim mtl
    process template-haskell temporary transformers unix unix-compat
    utf8-string
  ];
  testToolDepends = [ cabal-install ];
  doCheck = false;
  description = "Simple interface to some of Cabal's configuration state, mainly used by ghc-mod";
  license = stdenv.lib.licenses.agpl3;
}

@jwiegley you may have to jailbreak cabal-helper, I think, like I do here:

https://github.com/mrkgnao/preposterous/blob/5b03968d4bf9d206417daa3d562fd16119c57fd6/shell.nix#L13

I was able to get ghc-mod building for both 8.0 and 8.2:

https://github.com/jwiegley/nix-config/blob/master/overrides.nix#L249

Oddly, I need to use the ghc802 branch for 8.2, and master for 8.0.

Oh, yes, the original instructions specify that:

git clone [email protected]:ariskou/ghc-mod.git -b ghc802

It confused me too.

@DanielG It seems that everything is ready, I wonder when ghc-mod is available for GHC-8.2.1 :)

Oddly, I need to use the ghc802 branch for 8.2, and master for 8.0.

It's less confusing if you're already used to __GLASGOW_HASKELL__'s numbering convention... :-)

Oh, hey, that makes total sense @hvr! :)

Since cabal-helper-0.8.0.0 is on Hackage now I've decided to upload a very preliminary package candidate of ghc-mod to make it easier for people to install before its properly released:

$ cabal install https://hackage.haskell.org/package/ghc-mod-5.9.0.0/candidate/ghc-mod-5.9.0.0.tar.gz

Note that https support in cabal-install is relatively recent, AFAIK its available since 2.0.0.0.

I'm using this on GHC 8.2 myself, older versions of GHC are not tested yet however so don't expect them to work. I will try to keep the candidate version updated as we're inching towards a release so expect it to change.

@DanielG great news!

Any hints on how to pull this into a stack based project? With previous versions I just did stack build ghc-mod

@drvink After reading your comment I tried haskell-ide-engine, unfortunately I ran into this error : it seems multi-project support is not there yet!

Also having trouble with ghc-8.2.2. Fresh install of haskell-stack (via brew) fails to
stack install ghc-mod

With error here: https://pastebin.com/YS2GUt6n
Including the line:
ghc-8.2.2 from stack configuration does not match >=7.6 && <8.2

I'm absolutely boggled as to why there's no mention in this thread that haskell-ide-engine works with GHC 8.2.x and 8.4.x, especially given that it uses ghc-mod as a backend.

It doesn't have one of the most fundamental features, which is "show me the type of an arbitrary expression". Until that it isn't really usable.

is this likely to happen any time soon, given that this issue has been open for a year and the last commit on this repo was in january?

It doesn't have one of the most fundamental features, which is "show me the type of an arbitrary expression". Until that it isn't really usable.

It does. With the VS Code plugin you can mark any given sub-expression and get the type for it ("on hover"). How to plug into that with, for example, the neovim language client is a mystery, because while you can call hover on a visual selection it fails when getting the documentation for that selection and doesn't continue after.

So I would consider this not working a client issue, not an issue with HIE.

For Haskell beginners like me who found this thread while attempting to get ghc-mod editor extensions to work (like Haskell ghc-mod for vscode) but maybe don't need the latest and greatest, downgrading to the previous Stackage snapshot worked like a charm. The stackage home page says the previous LTS release is 9.21, so I changed line 21 in stack.yaml to:

resolver: lts-9.21

and ran $ stack setup to install the snapshot. The ghc-mod build succeeded after that:

$ stack build ghc-mod

Then I added this line to my user settings in vscode:

"haskell.ghcMod.executablePath": "stack",

and reloaded the editor. Success!

The Using with stack section of the Atom Haskell docs was helpful.

I'll check back in a year...

default.nix.txt
nix-trace.txt

This is a total disaster for any beginner trying to use Haskell with atom and stack. I lost half a day trying to work out what I did wrong. I've learned way too much about nix, stack and Atom, and still I can't get a basic IDE which would be expected in any other language community. I shouldn’t have to know ghc-mod even exists.

For new users - the defaults must behave well for a beginner. How can a configuration marked LTS be released if stack build ghc-mod doesn’t execute without error in a default configuration?

This must work:
https://atom.io/packages/atom-haskell

@pjgoodall, for now the options are:

1. use vscode
2. stick to GHC 8.0 or older

And no need for rage :), this is documented in atom-haskell official docs:

Please bear in mind that official release ghc-mod v5.8.0.0 doesn’t support GHC 8.2. If installing GHC separately, make sure to get GHC 8.0, otherwise, you might run into problems.

The problem is that it should either work or not rather than half work and lead someone who is new to the software down a dead end and waste hours of their life for no particular reason. If it's not going to be updated, make it not work with the newer software so people don't fall in to it's trap. Who wants to use an old version of GHC?

I suggest the project be closed down if it's not going to be updated. It will just become more and more of a disaster as time goes on and waste more and more peoples time. If a proper Haskell IDE can't be had then my solution is simply not to use Haskell... Modern compilers need modern IDE's... as coding becomes more complex the tooling needs to be able to manage the complexity... else it just becomes a rats nest of BS.

What an ungrateful attitude. The people investing their own free time to make your experience better, owe absolutely nothing to you or anyone else. You're acting as if someone on your payroll isn't doing their job properly.

While I think it's obvious where your frustration comes from, this is no way to manage it. There are alternatives to ghc-mod that work with Atom. There are alternative ways of working with Haskell that don't include IDE-like tooling. And, as you said yourself, there are surely alternative languages that might make you happy.

On the constructive side, https://github.com/haskell/haskell-ide-engine is a better interface for beginners than ghc-mod and it works well. I've packaged it for Nix: https://github.com/domenkozar/hie-nix

Yes, haskell tooling is fundamentally broken. That has a lot of reasons, some are intrinsic to the language, some are intrinsic to GHC and the unstable API ghc-mod uses. If you want something that works (ish) and doesn't blow up on large projects (no, haskell-ide-engine is not any better), go for codex https://github.com/aloiscochard/codex and a ghci repl. That gives you a lot of things already.

Otherwise you have no option except write something better. I personally don't think the ghc-mod codebase is worth maintaining. Too much legacy code and no one really understands it anymore.

But if you want someone to fix it, better provide help or donations.

@Aphexus I do sympathize with your frustration. I have had my share in the past as well. It took me many hours to understand what the problem is, and how to fix it, and just like you I regret that it costs so much time. That being said, I do not agree with the voice you give your frustration. Everyone involved with this project and every participant in this discussion (and many other people as well!) actually do care about these problems. Speaking with hurtful tone can damage the spirit that brought forth such wonderful tools as this one.

@LukaHorvat Actually, I do think there are ways to manage these frustrations.

The main issue I see is a mismatch between expectations of users of editor plugins and, well, reality. Many users (rightly) expect these plugins to just work. Most do not dig through documentation first (I'm not sure, but it could very well be true that I discovered the relevant line in the atom-haskell documentation only after many days, or even weeks). In the case of ghc-mod, the naive approach leads to compile errors, and then perhaps confusing internet search results.

Could users perhaps be notified earlier of the way to success? An easy workaround for GHC 8.2 support not existing is using an earlier GHC version, which is easily done by using lts-9.21 or earlier. Would it be possible to have this information be a prominent part of the compile error? Editor plugins could maybe help as well, by giving the same advice.

Not sure how feasible this all is though.

There have been ghc-mod patches/repos that have tracked current GHC releases for a while now. Regardless of what anyone’s “tone” might be, the frustration is understandable, as the least @DanielG could do would be to update the README to point people to them if he’s no longer interested in maintaining ghc-mod instead of leaving people to hunt fixes for the past ~2 years.

@DanielG just to clarify, my previous remark was not meant to suggest that you've been negligent or an absentee maintainer, but I think people would appreciate it greatly if you could indicate either in the relevant issue threads and/or the README that there exists a branch in your own repo that works with GHC 8.6.2, not to mention the branches that have existed for previous GHC versions as well. All of them have worked without issue for me once I discovered they existed, so even if you don't want to merge them for some reason, letting people know that they exist would at the very least reduce the number of entitled freeloaders (like myself :)) demanding hot 0-day ghc-mod warez.

@tsabirgaliev Frustration - not rage. But it may get that way ;-)

Its all very well for people with deep knowledge of a system to imagine beginners can survive on their crumbs. But it ain't so. I've been programming a long time and the GHC ecosystem is one of the crankiest I've seen.

Try videoing - lets say a java programmer of a couple of years - trying to get an IDE for GHC going.

Yes and I've tried vs-code, which normally is fairly likeable - it blows up with errors that I've tried to fix. Which of the probably 73 plugins are compatible with each-other? What prerequisites do they need from Linux? INSTALLING BINARY DEPENDENCIES :-))

I've been trying to get comfortable with Haskell for months. It's a beautiful language but I just get fed-up with trying to get a stable development environment. And no, I'm not going to use Emacs. Going to emacs from Smalltalk is like poking your own eyes out. Going to file-based development is enough punishment.

I tried atom-haskell after a long trail of broken development configs, because it looked like it was going to make a decent effort to get the pre-requisites sorted, and had a reasonable list of new-world features.

If you want a language to prosper, you need to make the cost of entry lower than the near-term joy gained by using it.

xx

@pjgoodall -- I get your frustration, but don't forget Haskell's motto: avoid success at all costs (by SPJ), so comparing it to Java is not fair ))

@tsabirgaliev
Oh dear, I wouldn’t compare anything I like to Java. I meant the ‘java programmer’ to represent an ordinary person trying to reach enlightenment.

Guys, ghc-mod is not an official project. It has no affiliation with the GHC or the language developers. These are community complaints that partly don't really belong in this issue tracker.

Your options are:

1. just use something different, probably with far less features
2. write a better tool and fix all problems once and for all
3. raise awareness about these issues e.g. on haskell-cafe mailing list
4. ask companies like fpcomplete or well-typed why they don't fix this (those are consulting companies that heavily participate in the haskell ecosystem)

ghc-mod is causing tears to stain keyboards everywhere.
https://github.com/begriffs/haskell-vim-now
What are the alternatives?

For general configuration I think I like nix + stack, but have had struggles with that too, about to retry.
https://chris-martin.org/2017/nix-for-stack-users
https://docs.haskellstack.org/en/stable/nix_integration/

What are the alternatives?

haskell-ide-engine, intero, dante and codex. Only the last one works with non-trivial projects. All others blow up your memory (haven't tried dante, because it's emacs only). If you're a beginner, memory might not be a problem.

@hasufell
Sorry man, I can’t do those mailing lists any more. Its an awful interface for discussion.

I've seen announcement in haskell-cafe of a fork that works in all ghc-8.* versions: https://github.com/kazu-yamamoto/hhp
I haven't tried it, since I am really happy with using ghcid which let you be free of these problems.

Thanks everyone...

Please note ghc-mod (as a development tool) is no longer supported: https://github.com/DanielG/ghc-mod#legacy.

I'm going to be working on refining our software-stack[1] for use with haskell-ide-engine instead. Especially working on cabal new-build support and legacy cleanup now that we don't need to spoon feed ghc-mod's legacy bits.

[1]: cabal-helper+ghc-mod(lib)+haskell-ide-engine(tool)