HIDE

I'd like to start a discussion on the development of an IDE for Haskell which for the moment we will call hIDE 2.x.

There is another wiki page (HaskellIde) on Haskell IDEs in general, however here I'd like to focus the discussion on more specific proposals for the development of an IDE.

There is also a hIDE page at haskell.org where developers may blog, comment on blogs, executables will be available for Windows users, tarballs for geeks, etc...

If you're looking for specific low-level details of hIDE itself, try the HIDE/Design page.

So let me (DuncanCoutts) start with my own personal views.

A Manifesto for hIDE 2.x

• Free Software, not based off proprietary IDEs
• Written in Haskell
• Extensable plugin-based design using hs-plugins (like lambdabot)
• Distributed development using darcs (again like lambdabot)
• Attractive UI using Gtk+ 2.x and the Glade visual GUI builder)
• Internal editor also written and extensible in Haskell, based on Yi
• Build system based on Cabal
• Integration with other tools, haddock, analysis and refactoring etc. through plugins
• Use the new GHC internal interface to provide tight integration with the editor and other parts of the IDE

BulatZiganshin: how about targeting competition with Emacs, VIM and other wide-spread IDEs/editors? i think now it's the right time to roll up Haskell-based killer app :) DonStewart: I think we are doing this, yes, since Yi already attempts to provide emacs/vim/... interfaces

Development style

Now you may notice that I'm mixing features with implementation choices (eg using Gtk+). To justify this I would appeal to the open source idea to release early and the importance of getting a base platform working to gain momentum and mindshare. Therefore we should not necessarily try to generalise too much too early but to get the basics working quickly.

However the other thing to avoid is going all out for features and neglecting the structure and organisation of the code necessary to allow sustained growth. This is one of the main lessons we must take from hIDE 1.x. So the modular development by plugins is important to allow distributed and parallel development. So for example it needs to be possible to develop components and then swap them out later for improved versions. For example suppose we start by using an editor component based on the GtkSourceView widget, it should be possible to develop another editor component based on Yi while the default remains as GtkSourceView and to have them both plugins loaded at the same time. Then when the new component is deemed to be better then the default implementatin can be changed over. That way we do not need to hold up immediate practicalty by waiting for more advanced implementations.

Why now?

Because we have the technology and there is demand for tools to make writing and maintining Haskell code easier.

• We now have distributed development with darcs.
• We now have hs-plugins and the techniques for building fully dynamic modular applications. http://www.cse.unsw.edu.au/~dons/papers/SC05.html
• We now have the GHC interface so we can get really good integration with the compiler.
• We now have mature GUI libraries.
• We now have an editor written in Haskell being developed.
• There is a VisualStudio plugin being written and we don't want Free software for Haskell development to be left behind.
• The Haste developers demonstrated that it's possible to build an IDE shell in a couple months with inexperienced Haskell developers.

Why in Haskell?

• Because Haskell developers know Haskell and not elisp/Java/C++/COM/C#. Therefore we are only likely to be able to get Haskell developers to help out by writing extensions if they can do so in Haskell.
• It means we do not have to live with the requriements and limitations of IDEs that are primarily aimed at other languages or written in other languages.
• Let me repeat a point: The Haste developers demonstrated that it's possible to build an IDE shell in a couple months with inexperienced Haskell developers.

Potential contributors

Since this is supposed to be a distributed development thing I thought it'd be nice if we start a list of people who have expressed any interest in contributing in any fashion.

So the list of potential contributers. Use you name and/or irc nick. If you have any specific ideas for what you might be interested in constibution then feel free to mention them. Or perhaps any skills you think would be useful.

• DuncanCoutts (dcoutts): I work on Gtk2Hs so I know a bit about Gtk+ programing in Haskell. I think I know a little abut GUI design (but maybe I'm just opinionated and igonrant). I used to work on hIDE 1.x. I would be interested in looking at GUI issues and general design and management issues.
• DavidHimmelstrup (Lemmih): I've written parts of hs-plugins and I'm fairly familiar with GHC's internal interface.
• NeilMitchell (ndm): I like IDE's. I also like Windows so will keep it compiling on that.
• DonStewart (dons): I hacked up hs-plugins and Yi, developed the dynamic architecture stuff, and am interested in pushing Haskell as a dynamic extension language.
• SamGoldman (Speck): I'm a relative newbie with Haskell, but I could test for OS X. I am also good with web apps and aesthetics/ergonomics stuff.
• Gour (gour): I'm also Haskell newbie, but can help test on amd64, web stuff...more after acquiring some Haskell-related skills.
• LyndonTremblay (humasect): Into realtime use for completely synthetic and dynamic audio and graphics processing, sometimes synaesthetically, so anywhere between general advisory to overt hack contributioning related to concurrent development, in place editing slash modifying of code and/or data link up slash external tool integration.
• DominicFox (poetix): Would like to build and test periodically on Linux, maybe assist with documentation.
• DavidWaern (davve): Was a member of the Haste project. Interested in the general design and most coding parts of the project. You can read about my experiences when developing Haste.
• LennartKolmodin (kolmodin): Member of the Haste project (developer log) when it was active. Would like to look into general design and "code aware" features along with overall hacking.
• JeanPhilippeBernardy: I hacked the emacs keybindings of Yi. I'm looking forward to perfect those.

Useful contributions may be in many forms, not just coding:

• Coding (well obviously we need some coding!)
• Ideas requriements and design
• GUI design - yes this is important
• Web stuff
• Graphics - eg logos maybe other stuff
• Documentation
• Cheerleading!

Development issues

Feel free to extend any of these with your own opinions.

There is now a hIDE/Design page for documenting the internal design.

The Windows question

ie "will it run on Windows?"

I don't see any reason why it shouldn't. All the basic parts we are using are cross-platform. Gtk2hs and hs-plugins run on Unix, Windows and Mac OS X.

That's not to say that every plugin will necessarily build on every platform. In fact we can use the plugin architecture to our advantage here to use different technologies to implement components on different platforms and to get better platform integration. For example consider the configuration subsystem; we might want to use GConf when using the Gnome platform but the Windows registery on Windows (or a simple file based implementaion on Windows and non-Gnome Unix platforms if people hate those sort of technologies).

However I don't expect that the plugability would extend to the basic graphical toolkit that is used. Though I do expect that many plugins would not need to be directly linked to a GUI toolkit if they do not need complicated user interaction.

BulatZiganshin: if using GTK will lead to need of installing additional software for Windows users of IDE, then it will be better to use wxWindows?

The GHC question

ie "how much GHC integration?"

The concern here is about a potential tradeoff between advantages of integration well with GHC (eg using it's API to get lots of info) and the disadvantage that it might become too hard to use anything other than GHC for the build.

It think that its clear that hIDE itself will require GHC to build because at the moment hs-plugins and Gtk2Hs do not support any other Haskell system. However if we can use different build systems or Cabal then it should be quite possible to target other Haskell systems like hugs,nhc,jhc etc. It may well be that we rely on GHC for some of the IDE features like error reporting and jump to definition etc.

Yhc is in the process of defining a Yhc API, if the list of features required was specified somewhere, perhaps with some abstract API that meets HIDE's needs, I'm sure Yhc could support it too (in time).

BulatZiganshin: there must be standard interface to compilers with one implementation using GHC, another - HUGS and so on

The license question

ie "What license? GPL? LGPL? Other?"

Personally I would normally pick GPL for applications, however this would not be a normal application.

In this instance I would suggest LGPL for the core components since we want people to contribute extensions for their favourite tools. This may necessitate linking against existing code under other licenses. Authors may be reluctant to effectively relicense any code they include as GPL. IANAL but I believe LGPL would allow combining plugins with different licenses.

However of course we can only accept plugins in the official collection/distribution that are Free Software (since otherwise of course we cannot legally distribute them).

BulatZiganshin: are BSD license not appropriate?

Plugins

Record of a stuff from #haskell. TODO: Format this better as issues get worked out.

<Lemmih> dcoutts: Do we need to handle editor plugins differently from non-editor plugins
         or can we device some universal plugin API which handles both? Can plugins depend
         on each other? Can two editor plugins be loaded at the same time?
<dcoutts> Lemmih, I don't think there is  single plugin API, there is a set of plugin
          interfaces. Some plugins will provide interfaces that other plugins can use. Yi
          would be one such example. The IDE shell would be another
<dcoutts> plugins must be able to depend on each other
<dcoutts> wether more than one plugin of the same variety can be loaded at once depends on
          the provider of the interface
<dcoutts> eg how does an editor plugin hoist itself in? probably by registering itself with
          the IDE shell. So if the IDE shell allows more than one they yes.
<dcoutts> I expect that for some kinds of plugins it'll make perfect sense to have multiple
          ones loaded at once, others it might be only one at once with a user preference
          to select which and others might be fixed (eg core plugins, or platform support
          plugins)
<dcoutts> Lemmih, so the whole thing is a bunch of modules, there's no base app with a
          single unified plugin interface. The whole thing is plugin modules.
<dcoutts> plugins can be linked against each other so they canprovide interfaces to each other
<dcoutts> each plugin gets an initialisation function. That allows it to register with any
          interfaces it intends to implement
<dcoutts> eg the core IDE shell plugin will provide interfaces for adding menu items and such
          like other plugins will linkagainst the IDE shell plugin and use it's public
          interface to register hooks like menu items

BulatZiganshin: see FreeRIDE below, they already developed powerful and flexible plugin architecture

UI ideas

Most IDE user interfaces look pretty similar these days. That's no bad thing particularly. It certainly gives us a good place to start and plenty of suggestions to think about. Here's a breif list of other IDEs that it would be worth gathering ideas from:

* Eclipse - a highly extendable IDE for Java and other language. There is a detailed and interesting UI design document available.
* Anjuta - a Gtk/Gnome IDE for C/C++
* KDevelop - a KDE IDE for C/C++
* Haste - a Haskell IDE developed for a univerty student project.
* MS VisualStudio - many people swear by it. Can't find many screenshots however.
* SlickEdit - apparently is quite good
* LEO [1] - User definable outlines and views to code. Not mainstream but good for ideas. See below for a mockup.
* PIDA  - Python Integrated Development Application - this one looks interesting sharing some of our hIDE ideas 

Feel free to add more to this list.

* FreeRIDE - Ruby IDE, useful because of similar architecture and motivation, reasonably well designed plugin architecture.

The Eclipse example is particularly interesting because it is also a highly plugable IDE. They can't fix upon a single static UI design because it mught be extensable by many plugins. So it has to pick UI concepts and abstractions that many plugins can fit into. At least the first part of the eclipse UI design document is well worth a read.

Let me (DuncanCoutts) now note down some of my UI ideas:

First of all, here is a little UI mockup.

Yep is looks much like many other IDEs.

So we have 3 pannels and a menu and toolbar. The main focus is of course the editor pane. The other two can be hidden away to get the maximum screen space for the editor (which is a common IDe problem, that they take up too much screen space).

The left hand pane is a collection of views of pages, or rather a way of navigating between pages. So they are lists or trees of pages. Selecting a page opens that page in the main editor pane. The reason for having several tabs of these views is that sometimes we need different views. For exaple, in the UI mockup above we've got a modules and files view. The files view would list all files in the project directory tree, selecting any of the would allow you to edit the file. The modules view on the other hand lists just the Haskell modules rather than all files. This is probably more useful when doing ordinary coding. The modules view would list all files that are the primary source, so for example when using a module that needs pre-processing, eg a .hsc .chs. .y or .x file, then the modules view would show only that file and not the generated .hs file - the generated file would be visible through the files view.

The intention is that plugins could register their own views. What I am describing is an example of a possible default configuration. To make the vies/pages system quite flexable one idea is that all pages should exist in a singe rooted tree and that the tab are multiple views into that tree. For example the configuration in the mockup could be described as having four views, rooted at /files, /modules, /open, /tools respecvely. That would allow the user to configure it with one single tree view rather than having multiple tabs. It would also allow a view to show only a subtree, which might be useful perhaps in a very large code base. So in that scheme, plugins could register pages or whole subtrees of pages and setup views to look into them.

The third pannel is for tools to display a UI to interact with the user. Examples of these tools could include things like search, interactive window, error messages etc. anything which you might want to have open at the same time as an editor page.

---

Another vision for hIDE is . (how do I get a link instead of picture?)

On the left there is user editable treeview which can contain different types of nodes. Some nodes will become modules and others are there for documentation. Some nodes can contain interpreters that have other modules loaded or other dynamic output. Nodes can be cloned so same node can appear at multiple places in the tree.

Point is that the whole tree is user built. (Though you can provide templates for lazy.)

Right side is normal splittable editing panel.

The point is that everything is in the outline. You (user) can make different nodes for different things and organize your workflow as you like. You could build different views, for say, bugs. Just collect all things related to a bug (tests, code, documentation) into single outline for easy manipulation and reference.

Different types of nodes is the main extension direction of this plan (besides editor interface with type checking etc). You could even make nodes that contain extension code that dynamically produces the node contents so as to make extending easy.

You could start with simple @module node that reflects a haskell module. Then Ordinary node that will be just documentation. Then perhaps ghci node, build log node, timetable node, project management node.. (see pivotal for great inspiration)

Development

darcs get http://darcs.haskell.org/hIDE
darcs get http://darcs.haskell.org/yi

You'll also need fps and unless you are using >=GHC 6.5 also ghc-api.

So far it has the basics of plugin loading ability and we've passed the first milestone of getting it to boot, load plugins, intialsise them and transfer control to the UI. It now is also hosting the yi/hIDE integration work which is comming along nicely.

Name contest

Please put your suggestion for the official name of hIDE here...

• hs as Haskell Studio :-) (Gour)
• yiDE - since it uses yi and is an IDE (aleator)
• gYi - ditto :) (BulatZiganshin)
• A name prefixed with "Free" or "Open", i.e. FreeIDE, FreeCode(?), FreeHS, FreeStudio, OpenStudio etc. (to emphasise that we are free!) (dons)
• On the 'Studio' theme, the obvious one is "HaskellStudio". But the MS haters might object :-) (dcoutts)
  • well, the full name of Anjuta is "Anjuta DevStudio" :-) (gour)
• why not hIDE? -- Could we make a clever pun with a companion tool named "Jekyll" or something like it? (mwc)
• Hive: Haskell Integrated Visual Editor (Environment), or somesuch. "The hive is a symbol of industriousness and teamwork." http://www.google.be/search?q=define%3Ahive
• Hades: HAskell DEvelopment System (or Studio)

Links

• NeilMitchell/WinHaskell - some thoughts from NeilMitchell about a lightweight GUI interface to a Haskell editor/interpreter.
• HaskellIde - an older page discussing some ideas for a Haskell IDE
• The Yi and lambdabot source code - useful for understanding the dynamic plugin architecture.
• The Yi wiki also has some documentation