** 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. -- [[User:Wolfgang Jeltsch|Wolfgang Jeltsch]] 00:11, 21 February 2006 (UTC)

** 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. -- [[User:Wolfgang Jeltsch|Wolfgang Jeltsch]] 00:11, 21 February 2006 (UTC)

+

** "Hades" actually stands for the god of the underworld. [[User:HenkJanVanTuyl|HenkJanVanTuyl]] 10:41, 31 December 2006 (UTC)

== Links ==

== Links ==

Revision as of 10:41, 31 December 2006

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.

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

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

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

1.2 Why now?

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

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.

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

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

3 Development issues

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

3.2 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

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

3.4 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

3.5 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)

4 Development

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.

5 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)