I thought I would throw some project ideas into the mix:
TUI environment for ghci
We recently gain the ability to colorize and pretty print the results in ghci, but we can do so much more. I don't think we need a full graphical user interface on top of ghci. I think we could accomplish a lot using a rich text user interface (TUI) instead.The idea I have is to use a library such as vty-ui to build a multipane interactive system on top of ghci. Imagine having a special pane for the ghci debugger, a pane for looking at the memory requirements and structure of types/values (ala vacuum). It could also support colorizing the input as you type expressions (and parenthesis matching).
Another pane could allow for module browsing and viewing haddocks.
Haddock 2.0
The basic idea here is to replace the haddock internals with pandoc. We could take this a step further and allow people to specify which type of markup they want to use for haddocks. The particular markup style would then be based on a directive such as:-- | haddock-markup: markdown
I'm not sure what the default should be, perhaps a "haddock to pandoc" could be provided as the default.
Community Edition of the Haskell Editor
There has been a lot of talk about Haskell IDEs lately, but for many of us editors such as Emacs and Vim are working well. Maybe it's time for a community maintained installer for plugins for the major editors?This package would bundle popular plugins (including ghc-mod) and provide reasonable defaults as well as documentation about using the plugins. The idea is to make it easier for Haskell experts and Haskell beginners to get up and running with a nice editor environment for Haskell. I envision such a package being complimentary to the Haskell Platform (or perhaps even included in it).
Social Hackage
Hackage 2 is getting closer to deployment by the day. It's time to start thinking about how to use the new features for a "Social Hackage". By which I mean, a hackage that distributes responsibility and provides clues as to the quality, maturity, and community opinion of packages and maintainers.Features such as upvoting, tagging, and comments can be used together to help people quickly and easily assess if a package is right for their project needs. I doubt these features will be properly tuned out of the box. Now is the time to get involved with Hackage 2 to help with this effort. Also, now is a good time to help Duncan et al get the new hackage tested and running.
More Platform Support
Heard that Simon Marlow is leaving MSR? Want to get involved with GHC development? How about being the champion for a new compiler backend? Here are some platforms that I wish had better support:- .NET
- JVM
- Web Browser (JavaScript or Google Native Client). Perhaps Fay will fill this role in the future.
- ARM, it's been ported but we need more testers
- iOS
Good GUI libraries
My highest priority here is that the libraries be easy and painless to install on the big three platforms (Windows, OSX, Linux). Improving GTK2HS and wxHaskell is a start, but I suspect this effort will require a major attempt from scratch.Improving Window Support
Improving the infrastructure such that developing for windows is easier. There is a lot to do. Here is a starter list:- Port more libraries. Any thing that uses the FFI is likely to not build on windows.
- Complete husyhox so that windows devs have a posix shell environment alternative to cygwin
- Port GHC and the RTS to work with the "native windows toolchain" (aka Visual Studio)
