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!
6 comments:
There was a mention of GHC being able to compile incorrect program, displaying warnings and deferring type errors to run time. I wonder how would that be reflected in GHC API.
Marek, do you have any pointer to that functionality? Thanks.
It was a feature in branch (which seems to have been removed).
http://www.reddit.com/r/haskell/comments/mwo5p/commit_ghc_fix5624_implement_runtimecoercion/
http://hackage.haskell.org/trac/ghc/ticket/5624
I think I would prefer Java-style editor to structural one. When I start writing a new module, it is convenient for me to keep pseudocode and code snippets in the function body, thus keeping it in non-compilable state for quite long time.
Happy hacking and happy New Year!
Boris, thanks very much, I wasn't aware of that work. The thing is, we're already calling GHC with the editor contents, so we could probably implement the same algorithm in buildwrapper without touching GHC itself. I'll think about it!
Chris Done posted a video prototyping a structured editor that forces type-correct code. Seemed cumbersome to me (http://chrisdone.com/posts/2011-12-17-concept-for-editing-asts-rather-than-text.html).
If you are not aware of Subtext and Jonathan Edwards, check him out (http://alarmingdevelopment.org/). Now defunct and I don't know that a binary was ever released, but had some good ideas. His paper "No Ifs, Ands or Buts" describes a really cool way of expressing conditional and looping statements graphically.
Justin, thanks for the pointers, I'll check them out!
Post a Comment