I've compiled a list of ideas for my current pet project, GHCJS [1] (Haskell to JavaScript compiler). While it's not exactly a central part of the Haskell ecosystem, it could be a fun compiler project to work on. Since it's a cabal package and the RTS is written in JavaScript, it's much more accessible than GHC itself.

GHCJS' evaluation model is quite close to GHC's, with lightweight threads, dynamically growing stacks, (async) exceptions, lazy IO, MVar, weak refs and all. This year I'm hoping to get some extra tooling for GHCJS that can also benefit Haskell in general.

One of the projects on the list is tracing/stepping through Haskell code, compiled by GHCJS, in the browser. I did a one evening experiment last year (with a now ancient GHCJS) and that already looked quite interesting [2]. The goal is to add interactivity and a nice user interface, with better rendering of the heap and stack data structures. Another useful thing would be profiling support: In the browser it'd be much easier to build a GUI that lets you pause a running program and collect memory allocation data from some specific thing you're interested in (for example pushing a single event through an FRP system).

The new tools would go well with Dan Frumin's last year's interactive-diagrams [3] GSoC project that runs or compiles Haskell code in a sandbox on the server. If we just upgrade the tools in the sandbox, users could paste some Haskell in the pastebin and immediately step/trace through the evaluation for example. Interactive-diagrams already has the ability to automatically show input fields or select boxes for users to supply the arguments if the input is a function.

While not for beginners, I think that students with reasonably good Haskell and JavaScript skills and some interest in RTS internals should be able to build something that's useful (and I have a good idea of what's going to be involved in both projects). The list [1] has more ideas, if anyone is interested in discussing projects, come to IRC, #ghcjs or #haskell-gsoc on freenode, github tickets / email also welcome.

luite

[1] https://github.com/ghcjs/ghcjs/wiki/GHCJS-Google-Summer-of-Code-project-ideas
[2] http://hdiff.luite.com/reduce/
[3] http://paste.hskll.org/ (sorry if it's down, one of the hdds in the server died recently, i'm moving everything over to a faster new server)


On Tue, Mar 11, 2014 at 5:31 PM, Allan Gardner <allanegardner@gmail.com> 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/viewanalytics says 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