Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

Info

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

 
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
 
Mentor: Edward Knyshov

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