HIDE

This project is currently orphaned. Creating a decent IDE is still an active research topic and many problems are yet to be resolved (see, say, the Proxima thesis). It has to be noted, however, that no conceptual problem was encountered with the GHC API. The plugin system -- which was based on GHC API -- remained at the prototype stage though.

A later note by AndrewUFrank (July 2009): Leksah is fulfilling many of the requirements mentioned here and in version 0.4.4.1 is at a stage where it can be used for productive work. It would be interesting to compare the actual realization with the requirements listed here.

---

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 requirements 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.
• ImamTashdidulAlam: I have ideas :-)
• Yogesh Mali : I am newbie to haskell..i have extensive experience of standard ML and silver function programmings which i use for my research. I would like to start with something concrete in haskell to hone my skills in it.I have ideas based on my using IDE for standard ML..so i can help in testing and coding in haskell.
• Tim Watson (lambdonut): also a haskell newbie, from mixed background including ocaml, lisp and erlang (I work for a telco - sue me). Interested in decent code awareness features (navigation, stats, etc), HaRe integration, etc. Will probably start with testing on GNU Linux and Win32, move on to documentation and get into code once I'm up to speed.

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?

Piotr Kalinowski: I don't expect IDE to be such sort of software that you would frown at a single additional install of GTK libs. Would you?

Jeremy O'Donoghue: Agree that look and feel is not primary for IDE. However, wide acceptance will require that a Windows/Mac Installer be created, and this really needs to include all necessary libs to run.

For wxHaskell this is easy (2 DLLs in same directory as application, totalling ~4MB, and no registry entries needed). I've created several applications this way using Inno Setup - it's very easy to do.

For GTK it is harder - my Windows GTK directory contains 1850 files and 47MB (I assume similar problem for native Mac port - but I've never even tried: GTK was just too painful (and ugly) on Windows). You'll also need to create a few registry entries (HKLM/SOFTWARE/GTK/2.0/DllPath, Path and Version last time I looked).

It took me a week of part-time hacking to get a GTK+ developer install which worked, and I've never succeeded in packaging it into a single installer with a Windows app which reliably works. While GUI lib used for an IDE doesn't necessarily matter, packaging is a very big deal for a 'killer app' - it really does need to have a simple installation mechanism, so someone should look into this right from the start.

For me personally, I'd much prefer native look and feel on all platforms, but I'd live without it if HIDE was really a 'killer app'. However, failing to create a simple installation mechanism and/or hundreds of library dependencies mean that I'd probably never even try it to find out (life's too short).

Piotr Kalinowski: I suppose it is possible to use a separate installer for GTK+. How about the one from http://gladewin32.sourceforge.net ? There's runtime environment and development version. Personally I never had problems with GTK under windows at looks very well for me.

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?

Jeremy O'Donoghue: I don't see how HIDE can be anything except LGPL or GPL, given GTK licensing (it is would be hard to argue that it is not a derived work of GTK). This is another (big) difference of wxHaskell where license is more liberal, and would allow open or closed source plug-ins etc (whether this is an advantage depends on point of view).

Without getting into 'license' war, BSD or MIT license should be OK for a plug-in to LGPL/GPL licensed application. Release a closed source plug-in at your own risk (I wouldn't do it, for example, based on the legal advice I have received, but your legal advice may vary).

Piotr Kalinowski: Actually it is just an application linked against GTK+ and not a GUI library based on it. Since GTK+ is licensed under LGPL, that should impose no restrictions on HIDE license. Personally, I don't care as long as it is open source.

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 university student project. (Dead link)
* 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.
* [Leksah] - Early stage haskell ide built in haskell. The "source candy" feature (giving nice symbols for lambdas, etc) is very nice. 
* Smalltalk - Different from all other IDEs as it does not work with files at all. Instead the IDE 
works with the languange primitives - classes and methods. Why do we need files anyway? In Haskell IDE, 
where files would (or could) be abstracted, the developer could focus on functions, types and type-classes. 
Such IDE would be superior to all current technology.

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)
  • Since the greek word “hades” denotes the place where the dead reside, it seems not like a good name for a Haskell IDE to me. -- Wolfgang Jeltsch 00:11, 21 February 2006 (UTC)
  • "Hades" actually stands for the god of the underworld. HenkJanVanTuyl 10:41, 31 December 2006 (UTC)

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