Skip to end of metadata
Go to start of metadata

Guidelines

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 - http://groups.google.com/group/clojure

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].  Also, feel free to add new categories.

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.

Previous year's Project Ideas

Please see prior year project idea pages for examples:

Project Ideas

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

Core Clojure

 

Numerical Clojure

 

Typed Clojure

ClojureScript

ClojureScript compiler backend infrastructure

ClojureScript Performance

Brief explanation: there are many impactful enhancements we would like to make to ClojureScript with respect to both runtime and compile time performance. In both cases we need better infrastructure for visualizing performance changes over time. This would require building new benchmark harnesses and ideally a public website where we can publish results for the wider community to follow along. This benchmark harness would be a critical tool in assessing the tradeoffs associated with a proposed patch. For runtime performance this work may involve significantly enhancing type inference and type propagation, for example occurrence typing might be a promising avenue of investigation. For compile time enhancements we should examine where parallelization, AST data representation changes, or more aggressive caching of intermediate artifacts may deliver faster development and production build time. Another important area for performance investigation is REPL start time - many ClojureScript developers rely heavily on a REPL driven workflow and shorter REPL launch times will have a big impact on user experience.

Expected results: faster runtime performance, faster compile times

Knowledge prerequisites: ClojureScript, Clojure, Java

Mentor: David Nolen


ClojureScript core.async & AST standardization

Brief explanation: cljs.core.async should be updated to be in sync with with clojure.core.async. Currently cljs.core.async still relies on the hand-rolled AST representation instead of the one provided by tools.analyzer. Updating cljs.core.async will remove many known issues and bugs. This would also be a good opportunity to address quirks and inconsistencies present in the ClojureScript compiler AST. Unifying the representations would open the door to more shared tooling between Clojure language implementations.

Expected results: more robust & maintainable cljs.core.async, shared tooling over common AST

Knowledge prerequisites: ClojureScript, Clojure, Java

Mentor: David Nolen

 

core.match compilation

Brief explanation: Currently core.match relies on a performance quirk of the JVM for backtracking - pre-allocated exceptions. This approach does not translate to JavaScript where the cost of throwing an exception is significant. Instead we should compile to a loop + jump table (via case). This would allow us to deliver good code generation for a much wider variety of targets.

Expected results: faster performance on modern JavaScript engines

Knowledge prerequisites: ClojureScript, Clojure, Java

Mentor: David Nolen

 

Light Table

 

Tooling

Distributed Load Testing

Brief explanation: Clojure as a language is a good choice for writing readable load test scenarios. Core libraries and runtime are well suited for doing highly parallel computation while lazy sequences and transducers are effective for doing calculations on big data structures. All of these properties are required in load testing. At the moment all the load testing solutions for Clojure at least partly utilize tools from other languages. Pure Clojure solution for this problem could be simpler and more concise.

Expected results: a Clojure tool for distributed load testing

Knowledge prerequisites: Clojure, performance tuning, Cloud computing

Mentor: Markus Hjort



Labels:
  1. Feb 20, 2016

    Brief explanation: There are a lot of ClojureScript script compiler forks exist to provide different compilation targets other than js. Most of them are currently stuck because of rapid ClojureScript development and difficulties with keeping fork in sync with upstream. We should consider refactoring ClojureScript to provide plugable backends architecture, specifically to allow users replace code generation stage of compiler and implement js generator as one of such backends.
     
    Expected results: active development of plenty other backends to bootstrap Clojure in such environments as c/c++, llvm, python, emacs lisp, lua, etc. Ability to use clojure mostly everywhere.
     
    Knowledge: ClojureScript, Clojure, JavaScript