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.

Google Summer of Code 2012 Project Ideas

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

Project Ideas

Info

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

Core Clojure

Clojurescript

Optimization

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 (https://github.com/bodil/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
- socket.io abstraction
- route filtering middleware
 
Knowledge prerequisites: Familiarity with nodejs

Mentor: Bodil Stokke

core.match

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

core.logic

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

CLP(Set)

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

CLP(Prob)

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

Mobile

Tooling

Enhancing Clooj IDE

Brief explanation: Clooj (https://github.com/arthuredelstein/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.

Type Systems

Preparing

Improve and document core.typed

for real world usage

Brief explanation: core.typed (aka. Typed Clojure) has a reasonably solid foundation, taking inspiration mainly from Typed Racket. There are several key missing parts that prevent it from being used seriously 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
  • Support for function keyword arguments
  • More core functions/methods assigned types
  • 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
  • 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
  • "Wrapper" types
    • eg. SQLSafeString
  • 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)
  • 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.
Documentation:
  • Comprehensive user guide
  • Untyped -> typed migration guide
  • Code examples
    • Complete typed CLJS compiler

Knowledge prerequisites: TBD

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

Mentor: David Nolen

Improve local type inference in core.typed (via Alms)

Brief explanation: Local type inference in core.typed (aka. Typed Clojure) is based on Pierce and Turner's Local Type Inference. LTI's strength is in its simplicity, but the authors note that squeezing just a little more inference adds significant complexity to the implementation. A particularly annoying prerequisite is that LTI requires that all function arguments be annotated with a static type.

Alms is a new language most notably featuring affine types. It includes a novel implementation of local type inference that can infer more accurate types for some function arguments. The algorithm is described in Chapter 6 of Jesse A. Tov's PhD dissertation.

The algorithm used for local type inference in Alms could be applied to core.typed 

Expected results: ? (Prototype, document, evidence of incompatibility)

Knowledge prerequisites: Difficulty: High.

Mentor: Ambrose Bonnaire-Sergeant

Web