Skip to end of metadata
Go to start of metadata


Information for Students

These ideas were contributed by our developers and users. They are sometimes vague or incomplete. If you wish to submit a proposal based on these ideas, you may wish to contact the developers and find out more about the particular suggestion you're looking at.

Being accepted as a Google Summer of Code student is quite competitive. Accepted students typically have thoroughly researched the technologies of their proposed project and have been in frequent contact with potential mentors. Simply copying and pasting an idea here will not work. On the other hand, creating a completely new idea without first consulting potential mentors is unlikely to work out.

If there is no specific contact given you can ask questions on the general Clojure Google Group -

Adding a Proposal

Please follow this template. If you don't have Confluence access please submit your idea, following this template to the clojure mailing list with the subject prefix [GSoC Idea].

Project title (heading level 3)

Brief explanation: A few sentences describing the problem to solved.

Expected results: What should the student have been able to produce at the end of the project. This includes things like tests and documentation.

Knowledge prerequisites: If a student needs to know something to be able to complete the project, be sure to list it.

Mentor: Add your name if you are developer who is willing to be a primary or secondary mentor for the project.

If you are not a developer but have a good idea for a proposal, get in contact with relevant developers first.

Google Summer of Code 2012 Project Ideas

Please see the Google Summer of Code 2012 for examples of project ideas.

Project Ideas

Please organise your project idea into a category below. Feel free to create new categories if needed.

Core Clojure

Lean JVM Runtime

Brief explanation:  The current Clojure/JVM runtime is fully-featured, and can become even more fully-featured with projects like core.typed.  However, sometimes it is important to have a leaner runtime that is less resource-intensive.  This is ideal for instances where Clojure serves primarily as a library or in lean runtime environments like Google App Engine or Android where a quick startup is desirable.  The goal of this project would be to create an alternative lean Clojure runtime and associated compiler.  The compiler may be based either of the standard compiler or the ClojureScript compiler.  Clojure vars would compile to static fields or methods.  It will be necessary to find out which subset of the language makes sense (for example, vars would probably not really exist anymore).

Expected results: A lean Clojure runtime and compiler (well, some good progress to this end)

Knowledge prerequisites: A thorough understanding of Clojure and some familiarity with byte code generation for the JVM.

Difficulty: Hard

Mentor: Daniel Solano Gómez



Brief explanation: ClojureScript is in constant need of further optimization and optimizations which are likely to deliver across all the major JavaScript implementations. We need to assess the corners of ClojureScript which seem to lag too far behind Clojure on the JVM and see what can be done. This includes but is not limited to improvements to persistent data structures, function invocation, the EDN reader, and to code size. It would be extremely desirable to generalize the ad-hoc benchmarking that is in currently in place. A web based tool that graphs changes over time that continually run the tests a la Are We Fast Yet? would be extremely beneficial - we imagine highlighting changesets that cause regression with links to GitHub, etc. 

Expected results: Improved performance and comprehensive benchmark suite that is available on and offline.

Knowledge prerequistes: A JavaScript performance nut. Experience with Clojure.

Difficulty: Medium

Mentor: David Nolen

Source Maps

Brief explanation: ClojureScript debugging is still significantly harder than it should be. Source Maps would greatly alleviate the difficultly. A considerable amount of work has been done, but there is more to do during emission in the compiler before the source maps we generate will be truly accurate. Even after Source Maps work, there's the question of step-by-step debugging. Perhaps it's possible to do this via a mixture of source maps and something via the Remote Debugging Protocol in Chrome. We could even imagine editing ClojureScript source in Chrome.  

Expected results: Accurate source mapping in browsers that support.

Knowledge prerequistes: A JavaScript & Programming languages nut. Experience with Clojure.

Difficulty: Medium

Mentor: David Nolen

Extending dogfort for real world use

Brief explanation:  Node.js provides a lightweight and fast server implementation, that’s commonly used for real time applications. Although its possible to make clojurescript applications targeting nodejs, the current experience is far from pleasant. Partly due to node’s heavy use of callback hell, and partly because most existing node libraries are heavily object oriented and imperative. Dogfort ( is a nice proof of concept , inspired by ring and compojure, that abstracts out quite a few of these issues.

Expected results: An improved version of dogfort that can be put to real world use. New features include:
- sessions
- cookies
- authentication middleware
- abstraction
- route filtering middleware
Knowledge prerequisites: Familiarity with nodejs

Mentor: Bodil Stokke


refactor and documentation

Brief explanation: core.match provides ML & Racket style extensible pattern matching to Clojure & ClojureScript. The project is in need of refactoring and extensive internal documentation. In order to aid debugging the pattern matrix transformations, a tool for stepping through the pattern compilation process would be very desirable.

Expected results: An core.match with fewer bugs and a code base that welcomes internal contributions and simplifies external extensions.

Knowledge prerequisites: Familiarity with at least one functional programming language that includes pattern matching as a feature.

Difficulty: Medium-Hard

Mentor: David Nolen


CLP(FD) enhancements

Brief explanation: core.logic now ships with a basic support for efficient constraint logic programming over finite domains. However this work could be taken considerably further. For example new constraints could be added that would allow core.logic to solve FD equations much, much more efficiently. It's also not clear precisely what kinds of classic FD problems core.logic excels at and on which ones we perform poorly on. It would be informative to take the problems found in mature solvers like GeCode and port them over to core.logic so a more disciplined comparison could be made. It would also be interesting to discover if core.logic can be made to defer FD constraint solving to external solvers like GeCode or JaCoP if that is desirable to the user.

Expected results: Improved performance and benchmark suite.

Knowledge prerequistes: Experience with Clojure, though significant functional experience in Common Lisp, Scheme, Racket, Haskell, OCaml, Scala is OK too if Clojure experience is lacking. Experience with Prolog or another language that supports constraint solving well is a big plus.  

Difficulty: Hard

Mentor: David Nolen


Brief explanation: CLP(Set) would greatly widen the applicability of using core.logic for various forms of static analysis. It would also make core.logic programming more natural for more kinds of problems for Clojure programmers.

Expected results: Basic support for CLP(Set). If CLP(Set) work begins in earnest by core.logic developers, we expect the student to tackle the various significant subproblems we expect to encounter.

Knowledge prerequistes: Experience with Clojure, though significant functional experience in Common Lisp, Scheme, Racket, Haskell, OCaml, Scala is OK too if Clojure experience is lacking. Experience with Prolog or another language that supports constraint solving well is a big plus.  

Difficulty: Hard

Mentor: David Nolen


Brief explanation: core.logic with probabilistic programming features would be a powerful extension to core.logic with a high degree of real world applicability.

Expected results: Basic support of CLP(Prob).

Knowledge prerequistes: Experience with Clojure, though significant functional experience in Common Lisp, Scheme, Racket, Haskell, OCaml, Scala is OK too if Clojure experience is lacking. Experience with Prolog or another language that supports constraint solving well is a big plus.

Difficulty: Medium-Hard 

Mentor: David Nolen


NDArray Implementation in Clojure

Brief explanation: Clojure's core.matrix ( provides a general purpose API for matrix / vector maths in Clojure, similar to Python's NumPY. An innovative feature of this API is that it is designed to support  multiple back-end implementations via Clojure protocols, which allows various mature Java-based matrix libraries to be used in idiomatic Clojure code. However, we do not yet have a comprehensive N-dimensional Array (NDArray) implementation written in Clojure itself. This is important because a) It would become the de-facto standard matrix implementation for core.matrix and b) It has the potential become the base format for multi-dimensional numerics in Clojure and c) It would enable core.matrix to work "out of the box" without needing a separate matrix library implementation.

Expected results: At the end of the project, core.matrix should include a NDArray implementation written in Clojure that conforms fully to the core.matrix API and passes all relevant test suites.

Difficulty: Medium/Hard

Mentor: Mike Anderson (core.matrix maintainer)

Algebraic Expressions

Brief explanation: Clojure's core.matrix ( provides a general purpose API for matrix / vector maths in Clojure, similar to Python's NumPY. There is an opportunity to research and implement a system for representing and optimising mathematical expressions so that they can be executed efficiently via core.matrix. There is significant opportunity to explore advanced features, e.g. finding solutions to systems of equations, compiling strategies for numerical optimisation, analysing expressions to determine opportunities for distributing or parallelizing computation etc.  It is proposed that the solution should exploit core.logic for manipulating expressions / solving formulae. Some experimental implementation ideas exist at

Expected results: At the end of the project, core.matrix should include a system for representing mathematical matrix expressions, and optimising them for efficient execution in core.matrix.

Knowledge prerequisites: Advanced Linear Algebra, Logic Programming (core.logic), Experience with Clojure

Difficulty: Hard

Mentor: Mike Anderson (core.matrix maintainer)

Incanter support

Brief explanation: Clojure's core.matrix ( provides a general purpose API for matrix / vector maths in Clojure, similar to Python's NumPY. Incanter is a Clojure-based, R-like platform for statistical computing and graphics. Historically, Incanter used some legacy matrix code that bound it to specific matrix implementations, and it would be a great improvement to have full core.matrix support in Incanter. However core.matrix is relatively new and does not yet have all the features required to meet Incanter's needs. The goal of this project is to make this integration happen, which will unify two of the major projects in the Clojure numerical computing space.

Expected results: At the end of the project, core.matrix should include support for all functionality required to support Incanter, and there should be a patched version of Incanter that uses core.matrix as the primary matrix library. Ideally, Incanter should adopt the core.matrix version as the master branch going forward (subject to approval with Incanter project leads).

Knowledge prerequisites: Linear Algebra, Statistics, Experience with Clojure

Difficulty: Medium

Mentor: Mike Anderson (core.matrix maintainer)

API Contract Validation

Brief explanation: Clojure's core.matrix ( provides a general purpose API for matrix / vector maths in Clojure, similar to Python's NumPY. An innovative feature of this API is that it is designed to support multiple back-end implementations via Clojure protocols, which allows various mature Java-based matrix libraries to be used in idiomatic Clojure code. However, this presents the challenge of validating that different back end implementations adhere to the contract implied by the core.matrix API. The goal of this project is to implement a robust system for specifying and validating these contracts, so that any core.matrix implementation can prove that it correctly supports the API, and any defects / regressions can be detected and understood. The problem is interesting because of the variety of options in the core.matrix API that the implementations may support (e.g. double vs int arrays, arrays of different dimensionality, optional linear algebra features, ability to fallback to default implementations etc.) - so it is not simply a case of pass / fail but understanding what combination of features an implementation supports and validating these.

Expected results: At the end of the project, core.matrix should include a robust system for declaring and validating API contracts. This should have been tested successfully against all internal core.matrix matrix implementations, and at least one external core.matrix implementation (e.g. vectorz-clj).

Knowledge prerequisites: Linear Algebra, Test-Driven Development, API Design, Experience with Clojure

Difficulty: Medium/Hard

Mentor: Mike Anderson (core.matrix maintainer)


Android UIs as Clojure data

Brief explanation:  Android currently allows developers to declare their user interfaces using sets of parallel XML files.  While this is a valid and practical approach, that doesn't mean there isn't room for improvement.  For example, the current approach means common snippits of XML may be duplicated and keeping different XML files synchronized can be troublesome.  Also, there is no really easy way to query and manipulate an Android UI at runtime.  Some ideas of how to ameliorate these issues include: Using a Clojure data structure with embedded logic or pattern matching to help solve the XML hell.  This data structure may be used at runtime to instantiate a UI or at compile time to generate XML.  Also, by extending Clojure's data structure protocols to Android's UI classes, it might be able to query and manipulate Android UIs as plain old Clojure data.

Expected results: Library and tools for manipulating Android UIs as Clojure data

Knowledge prerequisites: Android, core.match

Difficulty: Medium

Mentor: Daniel Solano Gómez

Enhance Neko for Android

Brief explanation: The original lein-droid and Neko projects gave a possibility to conveniently develop Clojure for Android (further CFA) projects, but Neko as a main library still lacks the maturity. Not all necessary UI elements are wrapped to be used in neko.ui's code generation facilities, some macros (like for defining an Activity) still do not cover all the use cases. Also, new Android 4.0-specific features (like ActionBars and Fragments) were beyond the scope of last year's work.  UI being on the most paramount sides of mobile development, it would be nice to conceptually change the way to think of it besides simply wrapping it for Clojure. On way it can be improved is leveraging Clojure's data manipulation capabilities (like destructuring or core.match) to handle the UI. There are already similar attempts in Neko, like destructuring Intents or, and doing this for UI could really improve development experience. Finally there still are issues untackled on the toolchain side. Auto-completion and go-to-definition features, which most Clojure users are used to, are currently unavailable in CFA due to platform peculiarities and need a dedicated effort to be implemented. Since this would most propably be made on the nREPL side, both nrepl.el and CCW could leverage these features thereafter.

Expected results: Neko as a library for full-blown and mature Android development.

Knowledge prerequisites: Android, Clojure for Android

Difficulty: Medium

Mentor: Zach Oakes 


Enhancing Clooj IDE

Brief explanation: Clooj ( is already a good IDE for Clojure beginners to start with, if they do not already have a preferred development tool set.  It is the easiest to install.  There are ideas for enhancements in the Issues tab of the project.

Expected results: An enhanced version of Clooj that fixes existing issues, adds new features, etc.

Knowledge prerequisites: The student would need to know or learn Clojure, and something about GUI development using Java Swing, the GUI library currently used by Swing.

Mentor: Arthur Edelstein, the developer of Clooj, would be an ideal mentor, if he has the time and interest in doing so.  No one has yet approached him with this possibility that I am aware of.

Refactoring feature for CCW & other IDEs

Brief explanation: Counterclockwise ( ) is the de facto Clojure plugin for Eclipse. It currently lacks any Clojure-specific refactoring feature, while Eclipse already provides a generic Framework for Refactoring. The idea would be to create refactorings for Clojure code.

Expected results:  A handful of common refactorings implemented, integrated with the Eclipse Refactoring Framework. A simplified integration layer for adding more refactorings in the future. Clojure the language will be used to write the refactorings. As few java as possible. Everything that is not IDE related separated in a "headless" layer so that it can be reused in other contexts (other IDEs, command line, leiningen plugin, etc.).

Knowledge prerequisites: The student would need to already know Clojure. Existing experience with Eclipse development would be a plus, since it's a framework with kind of a barrier to entry.

Mentor: Laurent Petit, developer of Counterclockwise.

Program analysis suite, based on Rich Hickey's Codeq

Brief explanation: Rich Hickey, inventor of Clojure and Datomic, created Codeq ( as a prototype framework for program analysis.  It harvests multiple information sources (eg, Git metadata, source code), and stores the results in a graph database (eg, Datomic).  The results are thus available for querying, processing, visualization, etc.

Although Codeq is very promising, it is only a proof of concept, lacking analyzers, a control framework, and presentation tools. Turning Codeq into a production suite would be a substantial software engineering effort, with corresponding visibility.  The student would extend the base that Codeq provides, producing a compelling and robust example of the power of this approach.

Expected results: The suite should be ready for "drop-in" installation in typical Clojure shops.  It should do continuous harvesting of code bases. It should extend the current Clojure analyzer to harvest names of called functions and methods, use of global state, etc.

Stretch goals might include other analyzers (eg, Java), queries for common use cases, analysis and visualization software, etc.

Knowledge prerequisites: Interest in mechanized program analysis.  Experience with Clojure.

Difficulty:  Medium

Mentor:  Rich Morin (mechanized documentation enthusiast), Tom Faulhaber (author of Autodoc, clojure.pprint, etc.)


Improve and document core.typed

Brief explanation: Optional type systems are more effective when only a small subset of code needs to be tailored to its needs (3-6%). Currently several important Clojure idioms are not understood by core.typed.

Documentation for core.typed is sparse, making the transition to it much harder than necessary for users.

Expected results: 

Type check more expressions and idioms:

  • More complete multimethod support
    • eg. multiple dispatch
  • Completed: Support for function keyword arguments
  • More core functions/methods assigned types
  • Completed: Should understand common control flow idioms across body expressions (in progress)
    • eg. function preconditions, assertions bound to throwaway locals like _
  • Improve Java method inference for method calls that the Clojure compiler does not already infer
  • Completed: Namespace management tools
    • eg. typed-require, typed-use, typed-load
  • Contract generation from types
    • Useful for preserving static type invariants when using typed code from untyped code.
  • More comprehensive handling of complex operations
    • eg. assoc, dissoc, update-in, assoc-in, get-in
  • Be able to successfully type check the current ClojureScript compiler
  • Design "Wrapper" types
    • eg. SQLSafeString
    • Might not fit with core.typed
  • Better design metadata types
    • especially for `with-meta`
  • Add support for Clojure Records
    • implement correct behaviour for when all base keys are dissociated (a record loses it's type)
  • Completed: Design solutions to correctly handle macros with complicated expansions.
    • especially `for`, `dotimes`, `doseq` etc.
  • Design a type generalising scheme to help better guess the type of loop variables
    • eg. (loop [a 1] ...) ; a should probably be Long, not the type (Value 0)
    • harder: (loop [a nil] ...) ; should be (U nil (Seqable Any)) ?
  • Design a sound solution for boxed/unboxed positions
    • Often doesn't make sense to give a function a primitive return.
    • eg. `int` should probably be something like `(MaybePrimitive int)`
    • Target Clojure 1.5 boxing semantics
  • Understand common higher-order functions in non-higher-order contexts
    • eg. juxt, every?, comp, partial, etc
  • Investigate and (perhaps) prototype an implementation of Alms type inference
  • Comprehensive user guide
  • Untyped -> typed migration guide
  • Code examples
    • Complete typed CLJS compiler

Knowledge prerequisites:

  • Reasonably complete knowledge of core.typed or Typed Racket internals

Mentor: David Nolen

Student: Ambrose Bonnaire-Sergeant

Previous GSoC Student Partiticipation: Typed Clojure (GSoC 2012, Clojure organisation)

Mentor-Student relationship: 

  • 2011 - core.match + core.logic development & docs
  • 2012 - Mentor-Student for Typed Clojure GSoC 2012

Clojure in Clojure

Complete CinC implementation

Brief Explanation: After the success of the CLJS compiler, rewriting the JVM compiler in Clojure has been on the menu for a while now. CinC has made a great start, but needs work to be a viable alternative to the JVM compiler.

Expected Results: Reliable alternative Clojure compiler to clojure.lang.Compiler

Knowledge prerequisites: Good Java and Clojure knowledge. Previous work with compilers a plus, especially CLJS.

Mentor: Aaron Cohen


Delta-cycle simulator for Piplin

Brief explanation: Piplin is a hardware description language written in Clojure. In order to better support intermixing arbitrary Clojure code with hardware simulations, the simulator needs to be able to propagate signals between Clojure-land and simulation-land within a cycle, until the values converge to a fixed point. This will enable better integration of plain Clojure tests and integration with existing Verilog simulators.  

Expected results: Delta cycle capabilities added to the simulator; an API for running arbitrary code during delta cycles; an example module demonstrating the usage of the API; tests and a 2-3 paragraph design document ensuring that the API can be used after GSoC

Knowledge Prerequisites: Verilog or VHDL, comfortable with Clojure

Mentor: David Greenberg

Hardware libraries for Piplin

Brief explanation: Piplin is a hardware description language written in Clojure; however, although it's core functionality is finished, it could use many libraries: 8 bit CPUs, video displays, random number generators, ethernet ports, I2C ports, serial ports, etc. This project will attempt to implement some reusable libraries to accelerate hardware development in Piplin.

Expected results: A module with SPI functionality, and one of: an ethernet module, an 8 bit CPU module, or an I2C module. These modules should come with tests and docstring documentation and be released to Clojars. They should be tested on an actual FPGA to verify that they work.

Knowledge Prerequisites: Verilog or VHDL, comfortable with Clojure, basic knowledge of the aforementioned protocols

Mentor: David Greenberg


Data structures

RRB-Trees (flexvec)

Brief explanation: Polishing (newly in Clojure Contrib, previously, the Clojure implementation of persistent vectors with support for efficient slicing and concatenation, based on Bagwell, Rompf, "RRB-Trees: Efficient Immutable Vectors", EPFL-REPORT-169879, September, 2011.

Expected results: Optimized implementation of concatenation (to replace the current high-level implementation using Clojure's seq functions extensively), full test coverage (currently there are (separate) probabilistic tests in place for concatenation and slicing, however a complete test suite for the basic vector operations, as well as concat-after-slice etc. is needed), performance tuning (e.g. fixing performance degradation arising when flexvec vectors of different element types are used in the same JVM; the overall performance profile needs to be closer to that of c.l.PersistentVector – this requires major profiling effort and possibly tweaks to the compiler), ClojureScript version (using whichever method of code sharing becomes standard during Clojure 1.6 development cycle if that happens prior to end of the GSoC period), transients.

Knowledge prerequisites: Familiarity with algorithmic details behind RRB-Trees, experience with Clojure and ClojureScript performance tuning.

Mentor: David Nolen