On 2014-03-11 09:20, JP Moresmau wrote:
Unifying all the different tools underlying IDEs has been talked again before, because the pain is real. For example, see https://github.com/fpco/haskell-ide/wiki. I've written about the GHC API in that wiki, and some of the issues that it has for such tools. Currently EclipseFP uses buildwrapper, which is a backend I wrote because I was dissatisfied with scion. It integrates the GHC API and Cabal, so that it aims to give the same results that running cabal configure/build. It usually run as a shortlived executable but for performance reason it is possible to have a long lived session to avoid reloading the modules in GHC all the times. Yes, GHC depends on the Cabal API for some types, which causes untold woes when you use buildwrapper after upgrading Cabal, for example. There is a bug report to remove that dependency but I had no time yet to work on it, so far I've used dynamic-cabal in buildwrapper to allow a newer version of Cabal, at the price of more complexity. But a complete tool would need to integrate both, so it can't be ghci only, otherwise Cabal and GHC would become really stuck together. The GHC API uses some global settings, which means you sometimes have no choice (if stcouldatic flags change) than to respawn a new process. This could probably be improved since it's not really the way a well behaved Haskell program should act. Memory usage is also a concern.
So I think there should be two lines of work here: one would be to improve the GHC API and/or the ghci interface, to make it more IDE friendly, the other would be to unify all these tools like scion/buildwrapper/ghc-mod in one tool that would hopefully provide all services an IDE needs, and that would allow easy plugin of additional functionality (so for example HaRe could easily add its refactoring capabilities to it). I would happily switch from buildwrapper to another community supported tool if all the functionality I currently have is kept in one form or another.
Since you've obviously been doing a lot of investigation here, I thought I might ask: What is GHC using Cabal for in *functional terms*, i.e. what actual functionality is it using? Is it just parsing package information files? What is it using that information for? Would it be possible to supply that information via other mechanisms than GHC snooping in the files? I'm thinking something along the lines of pkg-config here. (I understand the build system is a different issue, let's just ignore that completely.) Regards,