Home

There are a number of different Haskell IDE projects out there, whether they be standalone or plugins to existing IDEs. The goal of this project is to foster collaboration on components that can be shared among these various efforts. There is also a Haskell IDE Google Group for discussions.

For now, please edit this page and add any thoughts you like. As we get more information, I will refactor this into either a clearer structure or multiple pages.

Relevant efforts

• FP Complete's upcoming IDE
• EclipseFP
• Leksah
• Yi
• Emacs
• Vim

Goals/tools

• Haskell parsing.
  • haskell-src-exts for many tools
  • GHC API for grabbing more detailed information (e.g., types)
• Code building
  • cabal, cabal-dev, etc
• Higher-level wrappers
  • buildwrapper
  • scion
• Code completion
• Live code execution
  • yesod devel (upcoming library-based version)
• Code templates
  • Currently we have yesod init
  • Likely want to create something more modular. Perhaps allow anyone to create a template at a URL and have it pulled in by the tool.
• Code hinting
  • hlint
• Code formatting
  • stylish-haskell (see library pull request)
• Documentation/searching
  • Hoogle
  • scion browser
• Refactoring
  • HaRe

Approach

In general, I would like to try and build these tools as libraries with executable wrappers. This will allow pure-Haskell offerings to get the benefits of calling a library (type safety, purity, and performance) while allowing other non-Haskell codebases to access the code. I like the approach taken by buildwrapper of providing JSON output when possible.

As much as possible, it would be nice to avoid system dependencies. In some cases, we may need to have external tools/files (e.g., it seems that calling the GHC API from the same process can lead to memory leaks, so we may always need to spawn a separate process for it). Upstream changes I've noticed so far:

• hlint seems to have some filesystem dependencies. Building an executable against the hlint library on one system and uploading elsewhere did not work.

We should strive to create wrappers which are as simple as possible, while still remaining general purpose enough to be useful for all projects.