Alan Zimmerman announced on the haskell-cafe mailing list that
there was a new haskell-ide project, with a new Github repository,
list and an IRC channel. Some people have been concerned that
this effort is fragmenting existing efforts, including with
ide-backend (the open sourced library FP Complete announced earlier
this year). I clarified this on Reddit, but wanted to take the
opportunity to do so on this blog as well (and, additionally, throw
some extra attention on the haskell-ide project).
Alan's announcement did not come in a vacuum; about two weeks
reached out to others for feedback on a potential project.
There were some side channel discussions that I was involved in,
all of which were very much in favor of (and excited about!) this
project. To quote myself from Reddit, we reached the following
Both the ghc-mod and ide-backend maintainers have agreed to
contribute code to this new repository and then rebase the old
repos on this. The reason we're using a new repo instead of
modifying one of the existing ones is so that the existing projects
experience no disruption during this migration process. If this was
a new set of people starting a new project without support from
existing projects, I'd agree with you. But Alan's reached out to
existing players already, which is an important distinction.
Michael Sloan - the current maintainer of ide-backend and one of
the primary developers of both School of Haskell and FP Haskell
Center - is already getting involved in this project. It's too
early to decide exactly what the future of ide-backend will be
relative to haskell-ide, but we're not ruling anything out.
Anything from rebasing ide-backend to use haskell-ide internally,
all the way to deprecating ide-backend in favor of haskell-ide, is
on the table. We'll do whatever makes the most sense to help the
Haskell community create great tooling.
Related to this project: a number of people have been following
the development of stack-ide. We started that project not realizing
how quickly existing tooling (like ghc-mod and hdevtools) would
adopt support for Stack, and certainly not expecting this new
haskell-ide project to offer a unifying force in the Haskell
tooling space. To avoid fragmentation, we're currently holding off
on further word on stack-ide, hoping instead that collaboration
will help improve existing tooling not just for the Stack use case,
but for cabal, cabal sandboxes, and other cases people have been
Since I'm already discussing IDE stuff, let me publicly give an
answer I've given privately to a few people. A number of
individuals have asked about the future of the FP Haskell Center
codebase, and the possibility of open sourcing it. The summary
- Everything related to School of Haskell is being open sourced.
Most of that is done already, the rest is just in the last few
stages of code cleanup.
- The current state of the FP Haskell Center code base is
difficult to simply give out, since it's based on some superseded
technologies. For example, we created it in a world where Docker
didn't exist, and have quite a few LXC scripts to make it work. We
also have some difficult-to-manage build scripts that could be
replaced by Stack. We've cleaned all of this up for School of
Haskell, but have not done the same to the FP Haskell Center
- As a general policy, we don't like to just drop unsupported
code on the community at FP Complete. If there are maintainers that
are interested in taking over the current FPHC codebase, we can
discuss transferring it over. But simply open sourcing without any
support tends not to be a helpful move (instead, it distracts from
other, active projects, which we don't want to do).
- One possibility going forward is that, once the School of
Haskell web service is up, running, and stable, a new IDE project
could be started that targets that same API. We're not planning on
running such a project at FP Complete, but we'd be happy to provide
some feedback, and include necessary changes to the SoH service to
make it work.
I hope this excites others as much as it excites me: some
concerted efforts on improving tooling can hopefully go a long way.
A big thank you to Alan for coordinating this effort, and to
Michael Sloan for leading the charge from the FP Complete side. I'm
optimistic that we'll see some real strides forward in the near
Do you like this blog post and need help with DevOps, Rust or functional programming? Contact us.