Sunday, September 30, 2007

Eclipse's IDE Metatooling project

There is a new initiative at Eclipse.org for supporting projects who want to build Eclipse-based IDEs for new programming languages: the IMP project ('Eclipse IDE Meta-tooling Platform'). It seems it is a continuation of an IBM-internal project called SAFARI (of which we have seen a presentation at the last EclipseCON). This is great news; I think it will make the 'small step' that I have described in an earlier post much more extensive.

The IMP approach

Basically the idea behind the IMP approach is that for any IDE you create, there is a lot of stuff that you have (or someone else has) done already for other IDEs. The language specifics (such as the concrete syntax and semantics) may differ, but when you want to color syntax in the editor, show an Outline view and so on, you find yourself doing basically the same things that are done for any other language IDE. Much of the specifics of a language can be captured in a condensed description such as a grammar - why not derive the common stuff from there?

With IMP, you start with identifying your language and some basic information (e.g. file extension), and then providing a syntactical description, from which the lexer and parser are generated. From this, IMP can already derive some development support (e.g. mark syntax errors in the code editor). Now the rest of your IDE is built up from 'IDE services', which you can add one by one.

These IDE services are an abstraction over the well-known Eclipse APIs that one would have to implement when creating an IDE, e.g. project natures, New Project wizards, Outline page, syntax colorer, Code Folding, Content Assist etc. Since the parser is already in place, such IDE services can be generated in order to make use of the AST delivered by it; the generated code can then be customized to particular needs.

More information in detail can be found in the IMP Users Guide and in the SAFARI presentation from EclipseCON 2007.


The small step and the big step

So much for the small step (that is, what you get for free). What the IMP approach doesn't help with, though, is making the big step, once the small step is done.

Well, perhaps for many languages an extensive small step is all that is needed. An IMP-based IDE will have a lot of nice features. Here's a list from their website:

  • syntax highlighting, outline view population, package explorer-like navigation, content assistance, project natures and builders, error markers
  • refactoring support (not only "Move" and "Rename", but type- and code-related refactorings requiring non-trivial analysis, e.g. "Extract Method" and "Infer Type Arguments")
  • static program analysis (pointer analysis, type analysis, etc.) in support of the above
  • execution and debugging support
For many languages, IDE support of this order will get them quite some way, in particular if it comes mostly for free, or is at any rate easier done than with the current Eclipse APIs :-) Especially experimental languages or languages with a focused field of application (DSLs) will benefit from having such IDE support, and they might have not a real demand for making the big step.

IMP and established languages

But what about established, general-purpose languages? They have been around for a while; there is a community, and there are programming tools. Such languages tend to be self-hosting: given one that is sufficiently general-purpose, as soon as there is some community around it, people will start to write development tools in that language, for that language. Furthermore, its community works in the target language. They're not so much interesting in building their IDE in Java. (Perhaps even less so in hacking around in generated Java files to 'customize' it?) For taking the big step, making the project attractive to a larger community is essential. To avoid duplication of functionality, it is important to integrate existing tools - but these are written in the target language and don't necessarily integrate quite well with Java and Eclipse concepts.

Quite possibly, having gained so much by the small step, it might even become more difficult to get started with the big step. If the big step is not done in Java, it will involve much re-work, and there is a certain discouragement for this in the fact that so much already works ...

As far I can see, the IMP approach doesn't take this into account, and will thus mostly be helpful in areas where languages are restricted to some area of application, or are expected to be experimental and short-lived (or are sufficiently close to Java).

However that may be, this is definitely an interesting project that addresses a real need, and I'll be interested to follow it and see how it develops. (As a side note: there may well be some potential to integrate Cohatoe with IMP, in order to further reduce the amount of code one has to write on the Eclipse/Java side when implementing plugins in Haskell. I'll have a closer look into this sometime in the future and keep you posted.)

No comments: