I suddenly find myself in a strange (good?) position: as a maintainer of an IDE (ok, plugins) for Haskell, I can somehow participate towards fulfilling that dream. I know, I know, we're far from it, and EclipseFP has not yet reached the ease of use and power of the JDT in Eclipse. But maybe we can achieve success by doing things differently, not by trying to mimic what's already there and anyway applies to a different language.
We've already started to take some steps in the right direction: for example, Alejandro is working on a version of scion-browser that stores its data in a database. It's not such a big leap to envision that a lot of information about the developer's projects and modules could be kept in that database, to give accurate and fast searching and refactoring operations. We'll also need to think about providing an editor that is a lot more structured than the standard text-with-foldable-sections editor we have now, but it's not clear now if
- the benefits of a structured editor justify developing an interface programmers are not used to
- people would take the plunge even if we could prove tangible benefits
I can already see a clear advantage in having an editor that always force you to have valid code: EclipseFP loses a lot of functionality (thingAtPoint for example doesn't work) if the module you're working on has errors, because the GHC API can provide a lot more info once the module can be analysed correctly. With things like "undefined" and type-directed autocomplete support we could have modules that are always correct. I'm not sure myself that having a compiling module with loads of undefined that fails miserably at run-time is such a great proposition, but hey... In Java, Eclipse let you run a file with errors and only throws a run-time error when you access the incorrect code.
So we'll have to overcome usability and performance issues, deal with GHC limitations and programmers' expectations, but we're in the position to at least try, and see if we can move forward a little bit!
