[Haskell-cafe] GSOC Project Ideas

[Allan Gardner]

I went through the GSOC trac, most of the Haskell IRC logs, and the Haskell
idea reddit. So now I have a list of ideas (grouped by category):

infrastructure:

   - C++ integration (e.g. finish https://github.com/ofan/hqt
   https://github.com/ofan/fficxx )
   - Ada/Python/... integration
   - gobject bindings (gtk2hs stuff)
   - cabal improvements - Haddock flags (
   https://github.com/haskell/cabal/issues/1585), custom setup improvements
   (https://github.com/haskell/cabal/issues/948), some sort of plugin
   system for tests/docs/other random things (BNFC), clean up and merge
   parallel build code, package management, ...
   - Hackage2 improvements - voting, rewrite auth system, speed up
   reverse-deps enough to enable on main site, package wiki/comments,
   deprecations w/ links, create haddock even if the package doesn't build, ...
   - scale up Hoogle so it can search all of hackage by default
   - scoutess work (integration with with hackage, ghc snapshots, ...)

libraries:

   - email/PIM library (MIME, imap, ical, XMPP, WebDav, ... probably make
   use of a lot of old HaskellNet code)
   - comprehensive Date/Time API - there are lots of Hackage libs, but none
   do e.g. internationalization - aim to be backwards-compatible with time
   - highlight code using inferred types - HsColour + haskell-src/type-exts
   ? (maybe not enough for a GSOC?)
   - implement miscellaneous concurrent data structures
   - darcs improvements (performance, storage, ...)
   - fix pandoc conversion issues
   - ... (there were a lot of other libraries, but one of the blog posts
   said not do a library project because hackage already has too many and
   designing a good API from scratch is hard)

GHC project ideas:

   - package improvements - finish multiple package stuff, sign and verify
   packages, ...
   - port GHC build system to shake (faster, progress indicators, written
   in Haskell, ...)
   - implement something like ccache or distcc for GHC
   - rewrite the GHC pattern overlap/exhaustiveness analysis (
   https://ghc.haskell.org/trac/ghc/ticket/595, 10 years old!)
   - make GHC deterministic (refactor Unique + other nondeterminism
   sources, make a pure parser and/or typechecker API)
   - port Hat to the GHC api and integrate it into GHCi's :trace mode so
   omniscient debugging is available by default
   - implement typed core as another IL, either above or below old-core
   ("Types are Calling Conventions" paper)
   - other type-level programming library/project (units, extended
   arithmetic solver, true dependent types, linear types, ...)

GHC backend-ish:

   - customizable RTS - remove unused RTS functions, write your own
   concurrency primitives, ...
   - resurrect Immix patches and try to get incremental GC
   - implement loop unrolling in GHC
   - allow LLVM phases to be written in Haskell (bindings already used, so
   it's just dealing with the FFI's and GHC's options handling...)

I've tried putting these by two people (edwardk and carter) on
#haskell-gsoc, and they both said that all the GHC ideas are too hard for a
GSOC. Can I get a third opinion?

Also, please tell me if I left anything important out (I see a Yi proposal
on this mailing list; that would be in the ... in libraries).

Finally, some sort of idea of which ideas are most likely to get accepted
would be helpful.
https://docs.google.com/forms/d/1rEobhHwFpjzPnra9L1TmrozWNFFyAVNPmdUMCcT--3Q/viewanalyticssays
the top priorities are GHC, Cabal, and Hackage, so since GHC is
(apparently) out I guess that means I should look more at my Cabal,
Hackage, and Hoogle ideas... is this sensible?

-- Allan Gardner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140310/47da0417/attachment.html>