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