Google Summer of Code 2012 Project Ideas

Project Ideas

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.

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.

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

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.

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

Support for function keyword arguments

More core functions/methods assigned types

Should understand common control flow idioms across body expressions (in progress)

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

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.