EclipseFP: laundry list for 2.6

I seem to have a bit more free time these days to work on EclipseFP, so I was thinking about what we should try to add in the next major release. In no particular order:

• Sandboxing via Cabal 1.18 support and not only cabal-dev. Maybe also using cabal repl could replace some code in the GHCi launch configuration management.
• HSpec 
• Cabal bench
• An Haskell worksheet similar to the Scala worksheet. This would allow a better integration with the UI than running a GHCi launch, and would be able to persist test expressions over reloads and even Eclipse restarts. This would help people to play around with their code and see the results straight away. We could add things like time of execution, history of timings so you could check if you're improving the performance, pluggable graphical representations, save as unit test (make a unit test that checks that the given expression always give the current result)... Note that buildwrapper already has code to perform evaluations of expressions using the GHC API, but this is not used yet by the Eclipse front-end.
• Integrate HaRe (into buildwrapper since it now uses the GHC API?) to provide more refactorings.
• See if new versions of tools we depend on, like haskell-src-exts, can do more things for us or allow us to get rid of some of our code to rely on theirs (yeah!)

Let me know if you have some great idea that's not on the list, or if any of these are of special interest to you. I know there some other requests that people have made that I haven't implemented yet, so you can also check the issue list and comment on those you'd like to see treated with higher priority.

If you feel the urge to fork the github repository and start working on something, please don't refrain, I'll be happy to get more contributors!

EclipseFP: package version bounds in dependencies

Coming in EclipseFP 2.5.5, the cabal editor lets you specify what policy you want to use in respect to versin bounds when adding a dependency to a package, instead of just referencing the package without any constraints, or having to type them by hand:

You have four options:

• None: as before, doesn't generate any bound
• Current major version: will restrict to the major version of the package you currently have
• Current major version from current minor: the minor version of the package you currently have is going to be the lowest version allowed, up to the next major version. This is the default, since it assumes the current version you have is the one you're testing against
• Current minor version: only use the minor version of the package you currently have

The text field shows you the actual values that get generated. This field is now read-only since you can first select a package then change the version restriction options. If you want to enter manually the version bounds, you can still do that on the main page where all the current dependencies are listed.

I hope it will let you conform to the Package Versioning Policy and provide reasonable dependency bounds on your libraries.

No date on the 2.5.5 release yet, there's a couple of things I'd like to do first. The Github version should be usable if any of you want to live on the edge (and perform some valuable testing!).