<div dir="ltr">>It integrates ghc-mod, hdevtools, cabal<br>...<br>> Alexandr started a project called "hsdev"<br>(https://github.com/mvoidex/hsdev)<br><br>This is an excellent illustration of how fragmentation in this specific area hurts community. Not only you are forced to use 3 different tools (ghc-mod, hdevtools, cabal) each of which basically provides the same service but in an incompatible and incomplete way. But you decided to create yet another one instead of contributing to the ones you already use (they are all open source)<br><br>The problem here is that most of IDE features require some environment that loads and keeps track of the entire project information. Unfortunately approach of creating separate small utilities not gonna work in this case, because each utility would have to load entire project to be able to provide some useful functionality.<br><br>This is clearly the case where concerted community effort is required, similar to cabal.<br><br>And we do have a good base for it: ghci<br><br>On Monday, March 10, 2014 10:35:19 AM UTC-7, Niklas Hambüchen wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 10/03/14 16:22, Michal Antkiewicz wrote:>

<br>>

<br>>     I would say making ghci a full-blown IDE backend akin lisps

>     slime-swank or clojure nrepl would be the best approach.

<br>>

<br>> there's already hdevtools which plays that role - it provides all sorts

> of information to an IDE, like types, location of declarations, etc.

<br>> It's a background process and it's quite responsive (tries to be

<br>> incremental). I don't know how it is implemented and whether it is a

> wrapper around GHCi.

<br>>

<br>> But I agree that all IDEs should simply use GHCi as the official IDE

<br>> backend. Maybe some parts from scion/hdevtools/ghc-mod/etc. could be

> pulled back into GHCi?

<br>>

<br>> Michal

<br>

<br>Mateusz just clarified that his proposal is more about improving Yi as

<br>an editor than making it more of a Haskell IDE, so I am replying to this

in a new thread.

<br>

<br>Alexandr Ruchkin and me maintain SublimeHaskell, the most-used Haskell

plugin for Sublime Text.

<br>

<br>It integrates ghc-mod, hdevtools, cabal etc. and can do things like

<br>showing compile errors, completing imports, displaying the type of an

expression in the buffer or insert it over a function declaration.

<br>

<br>When we want to change a Haskell file's content, we get the relevant

<br>info from, say, ghc-mod and then do the actual modification logic in the

editor scripting language (in our case Python).

<br>We recognise that this logic is duplicated in pretty much every editor

<br>with such Haskell features, and at the same think that Haskell is a much

<br>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.

<br>

<br>That's why we seem to move more and more to do the actual modifications

<br>in an external Haskell program, and have the part in the actual editor

<br>be as minimal as possible. Alexandr started a project called "hsdev"

<br>(<a href="https://github.com/mvoidex/hsdev" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fmvoidex%2Fhsdev\46sa\75D\46sntz\0751\46usg\75AFQjCNGJbt8ZBQwS14v_p5iiUw8-6mV6mQ';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fmvoidex%2Fhsdev\46sa\75D\46sntz\0751\46usg\75AFQjCNGJbt8ZBQwS14v_p5iiUw8-6mV6mQ';return true;">https://github.com/mvoidex/<wbr>hsdev</a>) for that. It is very editor-agnostic

<br>and we think that sharing something like that across editors makes sense

<br>since it could save plugin writers a lot of time. The ideas is that you

<br>would tell this tool to perform an action, e.g. "import missing imports"

<br>or "go to declaration", and it would do it for you instead implementing

the buffer changes in your editor plugin.

<br>

<br>There is one problem with that: Editors don't deal well with other

<br>programs editing currently opened files. In Sublime's case, the buffer

<br>will automatically refresh, but it is very well possible that your caret

position and undo history get lost, which totally interrupts the work flow.

<br>

<br>So I was wondering what the most minimal interface would be that allows

<br>your editor to be aware of the changes that an external program (HaRE,

hsdev, etc.) would like to make to your code base.

<br>

<br>At the moment we consider having hsdev outputting a diff format that

<br>describes the changes, and then each editor would have to implement a

simple interpreter that goes through the files, applying the changes.

<br>

<br>That way we can avoid an external file change and the problems that come

with it.

<br>

<br>The Sublime-related discussion about this is at

<a href="https://github.com/SublimeHaskell/SublimeHaskell/pull/132#issuecomment-33888678" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2FSublimeHaskell%2FSublimeHaskell%2Fpull%2F132%23issuecomment-33888678\46sa\75D\46sntz\0751\46usg\75AFQjCNEP5uk9BbdYj258x6AObtfPfr4sXQ';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2FSublimeHaskell%2FSublimeHaskell%2Fpull%2F132%23issuecomment-33888678\46sa\75D\46sntz\0751\46usg\75AFQjCNEP5uk9BbdYj258x6AObtfPfr4sXQ';return true;">https://github.com/SublimeHaskell/SublimeHaskell/pull/132#issuecomment-33888678</a>.

<br>

<br>I think that IDE-style "smart language features" might have a better

<br>place in cross-editor tools than in the editors themselves. ghc-mod is a

successful example.

<br>

<br>I also think that most Haskell-IDE maintainers would agree (please

<br>correct me otherwise) that doing program transformation features is much

<br>more pleasant to do in Haskell than in Elisp, Vimscript, Python or Java,

<br>and that specifying out a cross-editor "modification description" and

<br>implementing the smart parts in a shareable tool might save us all a lot

of time.

<br>

<br>It looks like Scion (<a href="http://code.google.com/p/scion-lib/" target="_blank" onmousedown="this.href='http://code.google.com/p/scion-lib/';return true;" onclick="this.href='http://code.google.com/p/scion-lib/';return true;">http://code.google.com/p/<wbr>scion-lib/</a>) followed

<br>similar goals, but doesn't seem to have found wide adoption and no real

development for multiple years.

<br>

<br>I would welcome a discussion about why past attempts to this failed,

<br>whether you think that having a monolithic Haskell-IDE-tool output diffs

<br>for any editor to apply would lower the barriers for making editors

<br>Haskell-smart, and if you are an editor plugin maintainer, if you agree

that sharing common functionality is worth it.

<br>______________________________<wbr>_________________

<br>Haskell-Cafe mailing list

<br><a href="javascript:" target="_blank" gdf-obfuscated-mailto="gtocs138w_0J" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">Haskel...@haskell.org</a>

<br><a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fwww.haskell.org%2Fmailman%2Flistinfo%2Fhaskell-cafe\46sa\75D\46sntz\0751\46usg\75AFQjCNHiVycCM53czUVzPma4Fkb_wPqP2A';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fwww.haskell.org%2Fmailman%2Flistinfo%2Fhaskell-cafe\46sa\75D\46sntz\0751\46usg\75AFQjCNHiVycCM53czUVzPma4Fkb_wPqP2A';return true;">http://www.haskell.org/<wbr>mailman/listinfo/haskell-cafe</a>

<br></blockquote></div>