- 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!
4 comments:
+1 on HaRe. I expect to make a release soon, and it will makes use of ghc-mod to provide support for detecting the Haskell environment (cabal, sandboxing, etc). It was relatively straightforward to include this support, so integrating with buildwrapper should be straightforward too.
I am curious if you have seen hdevtools, which uses a persistent GHC process for incremental compilation, and if hat sort of technology could be used in EclipseFP.
I could be wrong, but it looks likes EclipseFP/buildrwapper starts a new GHC process for ever compilation task
It sounds slightly similar to the "worksheet" you mention in the post.
https://github.com/bitc/hdevtools
(And since you mentioned Scala, I'll mention that what I am thinking about is similar to `fsc`, the persistent scala compiler server used to make Scala compilarton fast when building with `ant`)
Thanks again for all your great work in EclipseFP.
I am curious if you have seen hdevtools, which uses a persistent GHC process for incremental compilation, and if hat sort of technology could be used in EclipseFP.
I could be wrong, but it looks likes EclipseFP/buildrwapper starts a new GHC process for ever compilation task
It sounds slightly similar to the "worksheet" you mention in the post.
https://github.com/bitc/hdevtools
(And since you mentioned Scala, I'll mention that what I am thinking about is similar to `fsc`, the persistent scala compiler server used to make Scala compilarton fast when building with `ant`)
Thanks again for all your great work in EclipseFP.
Michael, EclipseFP used to use Scion which was a long running GHC session, and this caused several issues (memory usage, static flags) as GHC is not designed with this type of usage in mind, which is why we switched to a short lived executable/ However, once you're editing a file, we keep a GHC session open for that editing session.
Post a Comment