[Haskell-cafe] On Haskell IDEs

[Carter Schonwald]

literally just for sharing the code for that parsing afaik.
I think theres a ticket for doing this.


On Tue, Mar 11, 2014 at 2:48 PM, Bardur Arantsson <spam at scientician.net>wrote:

> 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,
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140311/067db44b/attachment.html>