[Haskell-cafe] On Haskell IDEs

[Niklas Hambüchen]

On 10/03/14 16:22, Michal Antkiewicz wrote:>
>
>     I would say making ghci a full-blown IDE backend akin lisps
>     slime-swank or clojure nrepl would be the best approach.
>
> there's already hdevtools which plays that role - it provides all sorts
> of information to an IDE, like types, location of declarations, etc.
> It's a background process and it's quite responsive (tries to be
> incremental). I don't know how it is implemented and whether it is a
> wrapper around GHCi.
>
> But I agree that all IDEs should simply use GHCi as the official IDE
> backend. Maybe some parts from scion/hdevtools/ghc-mod/etc. could be
> pulled back into GHCi?
>
> Michal

Mateusz just clarified that his proposal is more about improving Yi as
an editor than making it more of a Haskell IDE, so I am replying to this
in a new thread.

Alexandr Ruchkin and me maintain SublimeHaskell, the most-used Haskell
plugin for Sublime Text.

It integrates ghc-mod, hdevtools, cabal etc. and can do things like
showing compile errors, completing imports, displaying the type of an
expression in the buffer or insert it over a function declaration.

When we want to change a Haskell file's content, we get the relevant
info from, say, ghc-mod and then do the actual modification logic in the
editor scripting language (in our case Python).
We recognise that this logic is duplicated in pretty much every editor
with such Haskell features, and at the same think that Haskell is a much
nicer language to program this logic. Technically, it is also less error
prone to work with ghc-mod's API than with its command line interface.

That's why we seem to move more and more to do the actual modifications
in an external Haskell program, and have the part in the actual editor
be as minimal as possible. Alexandr started a project called "hsdev"
(https://github.com/mvoidex/hsdev) for that. It is very editor-agnostic
and we think that sharing something like that across editors makes sense
since it could save plugin writers a lot of time. The ideas is that you
would tell this tool to perform an action, e.g. "import missing imports"
or "go to declaration", and it would do it for you instead implementing
the buffer changes in your editor plugin.

There is one problem with that: Editors don't deal well with other
programs editing currently opened files. In Sublime's case, the buffer
will automatically refresh, but it is very well possible that your caret
position and undo history get lost, which totally interrupts the work flow.

So I was wondering what the most minimal interface would be that allows
your editor to be aware of the changes that an external program (HaRE,
hsdev, etc.) would like to make to your code base.

At the moment we consider having hsdev outputting a diff format that
describes the changes, and then each editor would have to implement a
simple interpreter that goes through the files, applying the changes.

That way we can avoid an external file change and the problems that come
with it.

The Sublime-related discussion about this is at
https://github.com/SublimeHaskell/SublimeHaskell/pull/132#issuecomment-33888678.

I think that IDE-style "smart language features" might have a better
place in cross-editor tools than in the editors themselves. ghc-mod is a
successful example.

I also think that most Haskell-IDE maintainers would agree (please
correct me otherwise) that doing program transformation features is much
more pleasant to do in Haskell than in Elisp, Vimscript, Python or Java,
and that specifying out a cross-editor "modification description" and
implementing the smart parts in a shareable tool might save us all a lot
of time.

It looks like Scion (http://code.google.com/p/scion-lib/) followed
similar goals, but doesn't seem to have found wide adoption and no real
development for multiple years.

I would welcome a discussion about why past attempts to this failed,
whether you think that having a monolithic Haskell-IDE-tool output diffs
for any editor to apply would lower the barriers for making editors
Haskell-smart, and if you are an editor plugin maintainer, if you agree
that sharing common functionality is worth it.