ghc-mod
ghc-mod copied to clipboard
DanielG
GHC 8.2.1 support
There seems to have been some attempts to get ghc-mod working with 8.2.1; curious what the status of that work is. Thanks for this great software; now that I upgraded to 8.2.1, I'm really missing it!
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.
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.
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:
https://github.com/DanielG/ghc-mod/pull/922#issuecomment-353896120
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
ghc802branch for 8.2, andmasterfor 8.0.
It's less confusing if you're already used to __GLASGOW_HASKELL__'s numbering convention... :-)
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
There is a way to add tarballs via a http url to stack.yaml but according to the docs the tarball will be cached forever so you might have to find and delete it manually if and when you want to update to the latest package candidate.
Thanks to @DanielG hints, I managed to stack build ghc-mod in my project after adding this to stack.yaml:
extra-deps:
- https://hackage.haskell.org/package/ghc-mod-5.9.0.0/candidate/ghc-mod-5.9.0.0.tar.gz
- cabal-helper-0.8.0.0
- extra-1.5.3
- monad-journal-0.7.2
- optparse-applicative-0.13.2.0
- either-4.4.1.1
I was able to get ghc-mod to compile using stack and the extra-deps provided. However, ghc-mod version 5.9.0.0 compiled with GHC 8.2.2 still continues to generate the could not find $libexecdir/cabal-helper-wrapper error.
Hooray! I confirm that this branch is buildable on Windows with LTS-10.7 (GHC 8.2.2). But 21 tests fail.
@varosi interresting on Linux there are only three failing tests remaining: https://gitlab.com/dxld/ghc-mod/-/jobs/52021481. If you could try again with ~master~ the latest commit from the gh802 branch and open a new issue with the whole test output I'd be grateful.
Just to pointed out in case someone face the same issue and regarding @tsabirgaliev comment with stack i could managed to get it work with the following extra-deps in my stack.yaml file.
extra-deps:
- https://hackage.haskell.org/package/ghc-mod-5.9.0.0/candidate/ghc-mod-5.9.0.0.tar.gz
- cabal-helper-0.8.0.2
- extra-1.5.3
- monad-journal-0.7.2
- optparse-applicative-0.13.2.0
- either-4.4.1.1
- free-4.12.4
- haskell-src-exts-1.19.1
- hlint-2.0.11
As you can see i need to add the following deps to @tsabirgaliev's list:
- free-4.12.4
- haskell-src-exts-1.19.1
- hlint-2.0.11
FYI haskell-ide-engine also supports the various recent flavours of GHC (not 8.4.1)
See
- https://github.com/haskell/haskell-ide-engine/blob/master/stack-8.0.2.yaml
- https://github.com/haskell/haskell-ide-engine/blob/master/stack-8.2.1.yaml
- https://github.com/haskell/haskell-ide-engine/blob/master/stack.yaml
The gh802 branch needs further changes for GHC 8.2.2, something to do with transformers-compat:
ghc-mod$ cabal install
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: ghc-8.2.2/installed-8.2... (dependency of ghc-mod-5.9.0.0)
next goal: transformers-compat (dependency of exceptions-0.8.3)
rejecting: transformers-compat-0.5.1.4/installed-5tm... (conflict: ghc =>
transformers==0.5.2.0/installed-0.5..., transformers-compat =>
transformers==0.5.5.0/installed-1bb...)
trying: transformers-compat-0.6.0.6
trying: transformers-compat-0.6.0.6:-two
trying: transformers-compat-0.6.0.6:-three
trying: transformers-compat-0.6.0.6:+mtl
rejecting: transformers-compat-0.6.0.6:-five (conflict: ghc =>
transformers==0.5.2.0/installed-0.5..., transformers-compat-0.6.0.6:five =>
transformers>=0.4.1 && <0.5 || >=0.3 && <0.4 || >=0.2 && <0.3 || >=0.5.3 &&
<0.6)
rejecting: transformers-compat-0.6.0.6:+five (manual flag can only be changed
explicitly)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: ghc-mod, ghc-mod-core
Note: when using a sandbox, all packages are required to have consistent
dependencies. Try reinstalling/unregistering the offending packages or
recreating the sandbox.
exit code 1
@infinity0 we've split ghc-mod into two packages in that branch now, you need to install ghc-mod-core seperately or use cabal sandbox add-source ./core if you use sandboxes. With cabal new-build it just works FYI but there isn't a new-install yet.
The error message is quite unhelpful unfortunately, I was quite confused too when I saw it.
Thanks, add-source in a new sandbox worked for me.
In terms of running it in emacs, 'haskell-process-load-file keeps failing with Unexpected response from haskell process. after the last file gets compiled and then some stuff like 'haskell-mode-jump-to-def fails to work with certain external symbols, but other stuff like C-c C-t is working.
I can compile ghc-mod on the 802 branch just fine, but when I ghc-mod check something creates a directory ~/.cache/cabal-helper and tries to build that with Cabal-2.2.0.1, which then fails, although cabal-helper is already installed in the user-wide db with Cabal-1.24.2.0. I have no idea why ghc-mod is trying to compile dependencies at runtime. What is this?
https://gist.github.com/hasufell/eff8ad280c2ec2538fe488ea489bf136
I can't even edit the file that fails to build, because it is randomly overwritten.
Quite interesting why it's attempting to build against an unsupported Cabal version.
@hasufell please read cabal-helper's README, it explains why we do this.
The Cabal version number comes from what is in dist/setup-config, you can check it with something like head -n1 dist/setup-config. This is usually the Cabal library version built into your cabal executable. You can check that with cabal --version.
As for how to avoid this compilation, let me quote cabal-helper's output:
If you want to avoid this automatic installation altogether install
version 2.2.0.1 of Cabal manually (into your user or global package-db):
$ cabal install Cabal --constraint "Cabal == 2.2.0.1"
As for how to avoid this compilation, let me quote cabal-helper's output:
Cabal doesn't fail to build. cabal-helper does, because it's still built against an incompatible version of Cabal.
I followed the suggestion from cabal-helper output and this is what I get:
$ ghc-mod check Prepare.hs
[1 of 4] Compiling CabalHelper.Shared.Sandbox ( /home/hasufell/.cache/cabal-helper/cabal-helper0.8.0.2-Cabal2.2.0.1.build/CabalHelper/Shared/Sandbox.hs, /home/hasufell/.cache/cabal-helper/cabal-helper0.8.0.2-Cabal2.2.0.1.build/CabalHelper/Shared/Sandbox.o )
[2 of 4] Compiling CabalHelper.Shared.InterfaceTypes ( /home/hasufell/.cache/cabal-helper/cabal-helper0.8.0.2-Cabal2.2.0.1.build/CabalHelper/Shared/InterfaceTypes.hs, /home/hasufell/.cache/cabal-helper/cabal-helper0.8.0.2-Cabal2.2.0.1.build/CabalHelper/Shared/InterfaceTypes.o )
[3 of 4] Compiling CabalHelper.Shared.Common ( /home/hasufell/.cache/cabal-helper/cabal-helper0.8.0.2-Cabal2.2.0.1.build/CabalHelper/Shared/Common.hs, /home/hasufell/.cache/cabal-helper/cabal-helper0.8.0.2-Cabal2.2.0.1.build/CabalHelper/Shared/Common.o )
[4 of 4] Compiling Main ( /home/hasufell/.cache/cabal-helper/cabal-helper0.8.0.2-Cabal2.2.0.1.build/CabalHelper/Runtime/Main.hs, /home/hasufell/.cache/cabal-helper/cabal-helper0.8.0.2-Cabal2.2.0.1.build/Main.o )
/home/hasufell/.cache/cabal-helper/cabal-helper0.8.0.2-Cabal2.2.0.1.build/CabalHelper/Runtime/Main.hs:47:1: error:
Failed to load interface for ‘Distribution.PackageDescription.Parse’
It is a member of the hidden package ‘Cabal-1.24.2.0’.
Use -v to see a list of the files searched for.
ghc-mod: readCreateProcess: /home/hasufell/git/ghc-mod2/.cabal-sandbox/libexec/x86_64-linux-ghc-8.0.2.20170314/cabal-helper-0.8.0.2/x86_64-linux-ghc-8.0.2.20170314/cabal-helper-0.8.0.2/cabal-helper-wrapper "--with-ghc=ghc" "--with-ghc-pkg=ghc-pkg" "--with-cabal=cabal" "/home/hasufell/git/haskell-prepare" "/home/hasufell/git/haskell-prepare/dist" "package-db-stack" "flags" "compiler-version" "ghc-merged-pkg-options" "config-flags" "non-default-config-flags" "ghc-src-options" "ghc-pkg-options" "ghc-lang-options" "ghc-options" "source-dirs" "entrypoints" "needs-build-output" (exit 1): failed
As you can see, the result is completely unchanged. Also see: https://github.com/DanielG/cabal-helper/pull/51
The logic still seems broken. The cabal definition from here https://github.com/DanielG/cabal-helper/blob/master/cabal-helper.cabal#L148 seems to not apply properly
Ah, indeed. I overlooked that. The runtime compilation doesn't go through cabal for various reasons, so the cabal file just doesn't apply there. We could quite easily compile-in the version bounds and check them at runtime though.
We could quite easily compile-in the version bounds and check them at runtime though.
I haven't had a look at the code yet that does that, but we don't want it to just say whether the right version exists, but pick the right version based on Cabal < 2.1 && >= 2.0 || < 1.26 && >= 1.14. In this case, it should have picked Cabal-1.24.2.0, which existed.
Or... do we want to fail hard if the requested version that matches the cabal-install binary cannot be satisfied?
@mrkgnao @jwiegley could either of you possibly provide a working overlay with a ghc-mod that works for 8.2 ? That would be really great..
@hasufell we have to fail hard. The version we get is dictated by the cabal executable version the user used when running cabal configure (or something that does that internally like cabal build). We can't change that version.
The usual way this sort of situation happens is the user upgrading/reinstalling cabal-install without also upgrading cabal-helper. So we should throw a helpful error explaining the situation and how to uprgade. Not much else we can do really given the position of cabal-helper in the API.
If you'd like to tackle this and have further questions, which I'd be happy to answer, I'd suggest you open an issue over at https://github.com/DanielG/cabal-helper so we can de-noise this thread :)
Since #909 was closed in favor of this issue, I'll report it here: ghc802 branch fails with cabal version 2 with cabal: The 'repl' command does not support multiple targets at once., see haskell/cabal#4602 for more details.
@infinity0 the issue you refer to talks about cabal repl how exactly is that related to building ghc-mod? If you want to use the repl just specify which component you want like for example: cabal repl lib for the library component.
@gilligan I haven't been using ghc-mod, so I have no working Nix expression for you yet.
@DanielG my mistake, I thought ghc-mod was responsible for it but I was referring to haskell-mode's "interactive mode" which runs cabal repl. I am probably using an old version too, the one from Debian's package repository.
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.
@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.
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:
- use vscode
- 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.
Another interesting actively developed and supported project is Intero - https://github.com/commercialhaskell/intero
It works with most GHC versions and it’s interactive. Currently it works with latests GHC. Haskell is really good language to try! You just need right setup. For older GHC versions ghd-mod sandboxed with Stack for the proper GHC version worked really well. Now for latest GHCs you need either HIE or Intero. If you like console based programming, you could just open GHCi as a separate window and learn its commands via :help command or plenty of lectures in YouTube.
Cheers! На пт, 28.12.2018 г., 15:12 ч. Mark Laws [email protected] написа:
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 https://github.com/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.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/DanielG/ghc-mod/issues/900#issuecomment-450357271, or mute the thread https://github.com/notifications/unsubscribe-auth/AFxXhrlKWxYaUfiwJ7-UltrdPROlNolBks5u9hjOgaJpZM4OjYEd .
@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
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:
- just use something different, probably with far less features
- write a better tool and fix all problems once and for all
- raise awareness about these issues e.g. on haskell-cafe mailing list
- 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.
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)