[Haskell-cafe] GSOC Project Ideas

Luite Stegeman stegeman at gmail.com
Tue Mar 11 13:04:14 UTC 2014


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 at 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/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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140312/e2467312/attachment.html>


More information about the Haskell-Cafe mailing list