Hi Philipp,


for my Master Thesis at the Free University of Bolzano I am trying to
implement an Haskell IDE into Eclipse - so EclipseFP is the right thing
to start from I believe ;)
Probably :-) So first of all welcome to the list and good luck with your thesis.
 

Since most of you have already some experience in the field it would be
a great support if I can ask you for help from time to time.
Sure. You're welcome to ask about the EclipseFP code. You will also find a good deal of helpful discussions in the mailing list archive of this list. Needless to say, you're also welcome to contribute to the code base ;-)

The idea is to build an IDE (or to extend EclipseFP) that supports
Editing (already done by EclipseFP), Refactoring, Testing (Hunit or
QuickCheck support, and FIT), Versioning (does as far I know already
work with EclipseFP), and maybe Debugging and Building (a kind of Ant).
Do you have tried also to implement some of the features except Editing
or thought about it? Or can you give me some suggestions?
Well, to be honest, this is a fairly ambitious program. I think you should first of all try to get a good feeling of how much work will go into each of these items. A good starting point is http://eclipse.org/articles, and I would also recommend to have a close look at a collection of available open source plugins for different languages. In addition, here are a few more 'philosophical' considerations and some more pointers.

If you are looking around the current state of the Eclipse world, you'll notice that plugins for the various programming languages could be broadly grouped by their 'level of language integration'.

There is a first level that is fairly easily and quickly achieved:

- create an editor for a file type, provide syntax coloring, code folding and some basic content assist
- create a project type (in Eclipse called project 'natures') and associate a 'builder' to it (a builder is a mechanism
  that is notified about file changes and typically invokes an external compiler over these files)
- parse the compiler output and translate it back into 'markers' (file annotations that are automatically displayed by
Eclipse in the Problems View)
- create a 'launch configuration' for running a program from the IDE, or perhaps, as in the case of Haskell, running an interpreter and loading a file from the IDE into it

All this can be done fairly quickly, and most of these tasks are well described in howto-style articles at http://eclipse.org/articles (and besides, it is a lot of fun to do this, which is definitely one of the reasons why Eclipse has become popular a few years ago :-).

On this first level, you don't have to build a lot of 'understanding of the supported language' into your plugin. Then there is a second level (or actually, there are several more levels, depending on how closely you look at it) where you do exactly that: parse and analyse the source code and use that information for:

- searching for references
- 'intelligent' code assist (i.e. don't just suggest the known keywords, but suggest exactly the function calls that
are available in the current scope)
- navigate to declaration
- refactorings
- display call hierarchies
- much, much more :-)

This is where it gets interesting, but it is also where a huge amount of work gets necessary. If you compare the available plugins, you will see that most of them have not advanced much further than the first level of language support. (In case you happen to be able to read German, you can find a bit more information about this here: http://www.sigs-datacom.de/sd/publications/pub_article_show.htm?&AID=1751&TABLE=sd_article).

The most notable language support is of course Eclipse's own JDT, but that's definitely a class of its own. They've got an entire team working on this, most of whom have been working on several IDE projects (Visual Age ...) before. They have also benefited greatly from being able to implement their own Java compiler, which helps with much of the deep-language-integration stuff. Plus: they were able to use their own tool for building that tool itself.

That's where there is a twist for anybody who wants to create an Eclipse-based IDE that is _not_ for Java, but for a different language. The JDT team could use JDT to create JDT. If you want to create a Haskell IDE, what you would rather like to do would be to use Haskell, especially for things that have to do with 'understanding the language', i.e. everything that exceeds level one above. In particular, you will want to use GHC (or/and yhc, HUGS), HaRe (the Haskell Refactorer), Haddock, Cabal, HUnit and so on. Re-implementing all this in Java isn't really an option, but it is also not really easy to integrate it with the Java-centered view of the Eclipse architecture.

This is, for me personally, the current state of mind: I'm trying to find a solution that would make it possible to use Eclipse's plugin-architecture, UI frameworks, IDE support, and integration facilities, but at the same time to make it possible to use Haskell for anything that has to do with 'understanding the language', i.e. parsing, code analysis, refactoring etc.

There are a number of options for this, and all of them have been discussed on this list for a while. My own current experimentation area is here: http://cohatoe.blogspot.com, where you may want to have a look. In addition, we are all closely following the various attempts that are currently done in the Haskell community to get Haskell code compiled to JVM bytecode (which would be incredibly helpful). We have also a while ago experimented with approaches that used Haskell's FFI (Foreign Function Interface) and Java's JNI (Java Native Interface) to let Haskell code and Java code talk directly with each other.

About some of the more specific items:

>Refactoring,
For refactoring, I suggest you have a look at http://www.cs.kent.ac.uk/projects/refactor-fp/

You'll find a lot of resources there, and a tool, HaRe, that implements a catalog of refactorings for Haskell. I think integrating HaRe and EclipseFP is one of the topmost items on the wishlist of many EclipseFP users.

About the underlying (language-neutral) refactoring support in Eclipse, you'll find more information here: http://www.eclipse.org/articles/Article-LTK/ltk.html

>Versioning (does as far I know already work with EclipseFP),
Version control support is actually independent of a specific language, and is supported in Eclipse in a language-neutral manner. Therefore, language-supporting plugins typically don't have to care about it at all. Eclipse comes with built-in support for CVS, and any language plugin can rely on that support - it just automatically applies to all files in the IDE. People who want to work with other systems ( e.g. svn, vss, clearcase, ...) can just install the corresponding plugins, and again they will work cross-programming-language.

In the Haskell world, the favorite source control tool used by many is Darcs ( http://darcs.net) - Darcs is quite cool and written in Haskell (it is also used by EclipseFP as source code management system). There is also support in Eclipse for Darcs (http://eclipsedarcs.net ), but that is independent of both EclipseFP and Eclipse itself, it's an own project. It supports part, but not all functionality of Darcs yet. (Which means that you need to go to the command line Darcs client to do some things.)

>Building (a kind of Ant).
I think for this it would be the best to integrate Cabal (http://www.haskell.org/cabal/). This is the pendant of Ant in the Haskell world, and it is used by many Haskell projects.

EclipseFP has currently not much support for Cabal, but there is an editor with a bit basic syntax coloring for Cabal configuration files.

Grrrk, I hope this long mail doesn't frighten you but gives you a bit of orientation. Please feel free to ask if you want more detail about anything I've listed above :-)

Hope this helps,
Ciao,
Leif