On Mon, Mar 10, 2014 at 9:31 PM, Allan Gardner wrote:

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?

I absolutely agree. The thing about GSoC is that the time is short and relative to that the proposals tend to be ambitious. To make the best of the time you have, it's really important to understand what changes need to be made and to have a pretty solid idea of how you'll implement it. Of course, that's not the full story. GSoC is also an important mentoring opportunity as well. So you're not expected to know everything or all the technical details. Just keep in mind the time goes fast and that you probably won't have much time left if you need to spend time getting up to speed. The exception would be if you have previous experience with modifying ghc. In that case, it might be reasonable to do a ghc-based proposal. I hope that helps, Jason

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... 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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe