[Haskell-cafe] ghc-mod and IDE / plugin integration
michael at snoyman.com
Wed Oct 14 09:20:24 UTC 2015
Thanks for kicking off this thread Alan. I'm 100% behind the idea of
working on unified tooling, and am happy to participate in making that
JP: You're right to bring up ide-backend. Let's start a real discussion (as
part of what Alan's kicked off here) about what the best future for these
projects would be. I don't want to predetermine the outcome of that
conversation now, but I can say that anything up to merging ide-backend
into ghc-mod and deprecating ide-backend as a separate project would be
acceptable to me. Whatever makes the most sense for improved community
tooling is what we should do.
As for stack-ide, we already have slowed down development on it as a result
of the changes to ghc-mod recently. None of us on the project had a chance
yet to really analyze the situation and sync up with the ghc-mod team yet
(mostly due to some travel), but at least IMO the ideal will be a single
tool that supports multiple project structures (cabal, cabal sandbox,
stack, etc) and various editor frontends.
I don't have much structured thought right now on what the end game of all
of this should look like, but I'll be happy to be part of the conversation
and help get us to that better tooling future.
On Wed, Oct 14, 2015 at 11:19 AM, JP Moresmau <jpmoresmau at gmail.com> wrote:
> ide-backend (https://github.com/fpco/ide-backend) provides a JSON layer (
> https://github.com/commercialhaskell/stack-ide). I haven't tried it,
> since it requires stack and it's asking me to install the latest GHC 7.10.2
> (sorry, I just wanted to have a look at the API, not reinstall a complete
> Haskell stack again), but maybe there are some good ideas there.
> But before talking about API, shouldn't we talk about why we have ghc-mod
> and ide-backend? Can we merge them, or be clear what are their differences
> and when/why we should use one and not the other? We don't have
> fragmentation at the compiler level itself (with the dominance of GHC) but
> we seem to have some at the "nicer API on top of GHC" level.
> Or maybe, should we have something in GHC itself, something like a GHC
> service that we could talk to via JSON or something, without having to use
> the complex, changing with each release GHC API, and have that part of GHC
> instead of having another tool to install?
> My 2 cents,
> On Tue, Oct 13, 2015 at 9:55 PM, Alan & Kim Zimmerman <alan.zimm at gmail.com
> > wrote:
>> Historically ghc-mod provided (and still does) support for emacs and vim
>> as part of its distribution.
>> It is also used by a number of other IDE backends to provide a way of
>> getting information about a project without worrying too much about the
>> details of how the project is organised on the file system.
>> There is currently a discussion between various interested parties about
>> adjusting the way ghc-mod communicates with the IDE, to make it simpler to
>> provide this support for other environments.
>> This should end up with a definition of a protocol that ghc-mod can
>> expose, which should also allow tools (such as HaRe) to be plugged into it,
>> so that IDE integration can be handled by the various IDE integrators in a
>> clean, common way.
>> This is all just hand waving at the moment, so if anyone would like to
>> get involved I am proposing that we revive the "Haskell IDE
>> implementation" google group/mailing list to host the discussion.
>> The new design is/will be captured here 
>>  https://groups.google.com/forum/#!forum/haskell-ide
>>  https://github.com/kazu-yamamoto/ghc-mod/wiki/Library-API-Redesign
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
> JP Moresmau
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe