Error formatting macro: pagetree: java.lang.NullPointerException
Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current  |   View Page History

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].

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

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: Improved performance and comprehensive benchmark suite that is available on and offline.

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

Difficulty: Medium

Mentor: David Nolen

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 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.

Expected results: 

  • 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
    • 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.

Knowledge prerequisites: TBD

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

Mentor: TBD (Candidates: David Nolen or Ambrose Bonnaire-Sergeant)

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: TBD (Candidates: Ambrose Bonnaire-Sergeant)

Web

Labels: