Probably :-) So first of all welcome to the list and good luck with your thesis.
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 ;-)
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
, 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
- 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:
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:
, 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: