This year the Scala team applied for the second time for the Google Summer of Code  program to work with enthusiastic students on challenging Scala projects and we got accepted again!
Google invites students to come up with interesting, non-trivial problems for their favourite open-source projects and work on them over the summer. Participants get support from the community, plus a mentor who makes sure you don't get lost and that you meet your goals. Aside from the satisfaction of solving challenging problems, students get paid for their work. But wait, there's more! Successful participants also receive an official Google Summer of Code t-shirt! This is an incredible opportunity to get involved in the Scala community and get helpful support along the way.
Below we have collected a list of project ideas. The suggestions are only a starting point for students. We expect students to explore the ideas in much more detail, preferably with their own suggestions and detailed plans on how they want to proceed. Don't feel constrained by the provided list! We welcome any of your own challenging ideas, but make sure that the proposed project satisfies the main requirements mentioned here below.
The best place to propose and discuss your proposals is our "scala-language" mailing list (scala-language @ Google Groups, instructions to subscribe are available at http://www.scala-lang.org/node/199#scala ). This way you will get quickly responses from the whole Scala community.
This is the second time Scala team will apply for the GSoC. Last year we got approved and we had 6 very successful projects that were widely accepted by the Scala community. We encourage you to have a look at our Summer of Code 2010  page to get an idea on what we and you can expect while working on Scala.
Please make sure to read carefully the instructions at the end of this page for requirements and submission details.
Here are some project ideas for you (our community members have posted more on the mailing list so have a look there as well):
The aim of the project is to add support for Scala programs to Eclipse MAT . There’s a small project already providing text viewers for some Scala types on github , but the really interesting bit is hooking the Scala interpreter in the query builder.
MAT supports OQL , an SQL-like query language for Java heaps. Unfortunately, it has virtually no abstraction or reuse mechanisms. This project should add support for writing queries in Scala giving:
for-comprehension syntax for queries
all the abstraction mechanisms available in Scala, for instance to save queries or filters, to refine existing results, etc.
We have developed a tool (jdk2ikvm, http://lamp.epfl.ch/~magarcia/ScalaNET ) to automate the migration of Scala sources from JDK to .NET (once migrated, those sources can be compiled by Scala.NET against the IKVM library to obtain .NET assemblies). Our experience with this tool is based on porting the Scala compiler itself and the Scala library. However, the API migration that jdk2ikvm performs is general in nature, and thus it would be interesting to field-test it with other large Scala applications (for a non-exhaustive list, see https://github.com/alacscala/scala-corpus  ) “Field testing” means more than just running jdk2ikvm and hoping for the best, it includes for example running the (migrated) test suite of the application on .NET. An expected by-product of these case studies are additional conversion rules, for example gathered for JDK APIs that have not yet been addressed as part of the conversion.
Existing embedded DSLs for database-query allow the Scala compiler to statically check many (but by no means all) aspects of query well-formedness. This topic aims at improving on both the expressiveness, checking, and optimization of embedded database queries by: (a) extending the current syntax for for-comprehensions with notation for group-by and order-by, along the lines of Haskell’s “comprehensive comprehensions”; (b) use lightweight modular staging to realize the query optimization capabilities of Ferry and Pathfinder: http://hackage.haskell.org/package/DSH  ; and finally (c) develop a benchmark suite.
Because this is a demanding project, good knowledge of Scala is a prerequisite.
Spice up the proof-of-concept dhtml repl interface http://github.com/tiarkrompf/replhtml  and turn it into a useful development tool. Interface to the presentation compiler to add completion, hovers, etc. Some aspects of GUI would also need to be redesigned. Finally, it would be useful to include a launcher interface so that it integrates into Mac/Linux/Windows desktop environments.
Devise an interactive Scala shell that merges to the extent possible command prompt facilities (e.g. bash), scala prompt (scala), and interactive debugger (such as ocamldebug). As part of this, devise a mapping from file system into a web of objects that represent directories and files. For example, a directory could be presented as an object whose fields are other files and directories. Then, provide a convenient way to inspect objects, through the notion of current object that generalizes current directory.
There are many other different ways in which current REPL would benefit. We welcome any ideas proposed by students which are backuped up with a reasonable plan. For possible extensions you can also look for inspiration in bash integration or porting some of the features of popular Windows PowerShell to Scala REPL.
Build a simple presentation creator in Scala.
The primary input mode should be free-form drawing and text. You are encouraged to use (or port) the open-source http://detexify.kirelabs.org/classify.html  to provide some mapping of hand-written latex symbols into the corresponding Unicode characters. Use context to improve the precision of symbol recognition.
Project aims at providing a distributed abstraction layer for active objects such as actors and transactors, to ease development of such computational models in a distributed setting. This layer should allow starting active objects transparently. It builds upon a message passing layer. It should meet the following prerequisites:
- taking care about load-balancing, transparently starting active objects on remote nodes, and moving them dynamically to different nodes as needed
- support distributed garbage collection of non-cyclic data, active objects, as well as regular ‘network objects’
Finally, the project should extend an existing actor implementation to use this abstraction layer (Scala remote actors, see successful project from GSOC 2010 for instance).
The goal of the project is to extend Scaladoc to emit API documentation that follows .NET and Mono conventions. The newly redesigned Scaladoc 2 has greatly improved the ability to generate different type of styles of documentation and with the upcoming release of Scala.Net it would be useful to immediately have the ability to generate .Net-compatible documentation. Further details can be found at: http://lamp.epfl.ch/~magarcia/ScalaNET/2011Q1/ScaladocNET.pdf .
An API’s Scaladoc documentation may refer to external API documentations (for example the standard library API) to create an integrated documentation of multiple APIs.
There are many ways to successfully finish this project and students will be expected to provide a firm plan to accomplish it. Possible outline as follows. When building a documentation site (i.e. the result of running Scaladoc on a set of source files), the user can specify dependency URLs to remote Scaladoc sites. The documentation for any entity that is referenced in the sources and for which documentation is available in a dependent site is linked to that site. Optionally, the index of the site is completed with the entries of the remote site’s own index to create an integrated documentation site. To support this feature, it may be necessary to modify the Scaladoc client to be more dynamic (i.e. closer to an AJAX web application), and have the Scaladoc compiler generate a reusable data representation (JSON) of the documentation rather than static sites.
The student doing this project will be expected to take on stewardship of Scaladoc for the duration of his summer of code. To familiarize yourself with Scaladoc 2 (introduced in 2.8.0) we suggest you have a look at the following website: http://lampsvn.epfl.ch/trac/scala/wiki/Scaladoc . It also contains other ideas to improve the infrastructure of Scaladoc 2 which you may find interesting and propose as a separate GSOC project.
The goal of the project is to build up the Colladoc community by extending and improving the system’s collaborative features, and tackling key usability issues.
Advanced collaborative features, in particular those concerned with tracking and reverting changes, are not yet mature in Colladoc. To improve those, the student will observe existing use patterns on the deployed Colladoc tool, while helping nurturing its community. He or she will analyse key missing collaborative features, will implement and deploy them and, in an iterative process, observe the resulting effect on the community. Because collaborative documentation is still new, a part of this project will be to understand the specific dynamic of this process. This includes the interaction between documentation contributors themselves, and between contributors and the developers of the documented sources (the Scala team).
The student doing this project will be expected to take on stewardship of Colladoc (in cooperation with Petr Hosek) for the duration of his summer of code.
More information and source code for the GSOC 2010 Colladoc project can be found at: http://code.google.com/p/collaborative-scaladoc/ 
Akka is the platform for the next generation event-driven, scalable and fault-tolerant architectures on the JVM. Akka is one of the most successful projects written in Scala which propagates the concept of Actors on the JVM platform. More infomation about Akka can be found at its website http://akka.io , including growing documentation at http://doc.akka.io . For more information about the projects we suggest asking either the scala or akka mailing list, http://groups.google.com/group/scala-language  and http://groups.google.com/group/akka-user  respectively.
Akka currently has remoting support based on Netty NIO library. This project would implement a new transport based on ZeroMQ. First support the DIRECT pattern but if time permits also other patterns like PUBSUB, PIPELINE etc.
Implement remote class loading for Akka Remoting. This means the ability to start up other JVMs without the user code on the class path, send them arbitrary actors and see the classes for these actors be loaded across the network in a transparent fashion.
Being able to attach a Scala REPL to a running system to inspect and modify code at runtime.
Akka currently has a naive implementation of Dataflow Concurrency though Dataflow Variables. This project will reimplement them in a more performant fashion and also add support for Remote Dataflow Streams. If time permits also make these work across the network utilizing Akka Remoting.
Implement a ScalaCheck-style testing framework for testing state-machines. In particular Akka FSM module.
Create a plugin for Google’s Protobuf compiler (or stand-alone compiler) to emit Scala ‘case classes’ that supports serialization to and from Protobuf’s binary format.
Of course the list is non-binding and any reasonable project related to Scala that is proposed by student will be thoroughly reviewed.
This is the second time the Scala project has applied to the Summer of Code, and from last years experience, increased popularity of the language and stories of other mentor organizations we expect a high number of applications. First, be aware of the following:
The proposal will be submitted via the standard web-interface at http://socghop.appspot.com , therefore plain text is the best way to go. We expect your application to be in the range of 1200-2500 words. Anything less than that will probably not contain enough information for us to determine whether you are the right person for the job.
Your proposal should contain at least the following information, but feel free to include anything that you think is relevant: