[Haskell-cafe] GSOC Project Ideas

[Brent Yorgey]

I'd like to point out that we also have a list of diagrams-related
projects here:

  http://www.haskell.org/haskellwiki/Diagrams/Projects

Some (though not all) of them would make good GSoC projects,
especially those that push diagrams more in the direction of being a
useful general-purpose tool for other Haskellers, or result in
spinning off useful general-purpose Haskell packages.  Diagrams is a
lot of fun to work on and we had two successful diagrams-related GSoC
projects last summer (one creating an interactive diagrams pastebin,
http://paste.hskell.org/, which also resulted in spinning off several
libraries; and one adding a diagrams backend for the Chart library).

Some particularly good potential projects include:

  - Implementing a general graph-drawing library on top of diagrams
    (note this doesn't include doing graph *layout*, just drawing; but
    could include making it easy to e.g. use graphviz to do the graph
    layout and diagrams to do the drawing).

  - Converting SVG files to diagrams and/or improving diagrams' SVG
    output (optimizing the size of generated files, adding features
    like grouping for transparency, node ids, etc.)

  - Adding the ability to edit diagrams (e.g. "make everything black
    and white" or "make all the circles 50% bigger"); this is a big
    missing feature and would involve some fun gymnastics with zippers
    and lenses.

We're happy to discuss these or other ideas on the #diagrams IRC
channel.

-Brent

On Mon, Mar 10, 2014 at 10:31:02PM -0600, Allan Gardner wrote:
> 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

> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe