2013 Summer of Code Ideas List

Here are a list of ideas for the Google 2013 Summer of Code.  Grace is a gradually typed object-oriented languages that is defined for teaching novices.  General information about the Grace language (including a language spec and a number of papers) is available at gracelang.org.  Compilers are also available that generate either javascript or C for the backend.  Please direct questions to Kim Bruce (kim@cs.pomona.edu).

We have several projects related to the implementation of the language that are ongoing.

  1. Continued Work implementing Grace on DrRacket
    1. Grace on DrRacket:
      The front end of a Grace compiler on DrRacket is mainly done, while some parts of the backend are also done. However, they need to be integrated and take advantage of the hooks into the IDE.  For this project it would be very helpful to have some experience implementing languages in DrRacket.  (kim@cs.pomona.edu)
    2. Grace type inference in DrRacket:
      Grace is a gradually typed programming language, allowing a mix of statically and dynamically typed code.  We wish to provide help for programmers who wish to convert code from dynamically to statically typed.  Rather than having the computer perform type inference automatically (as in ML or Haskell) we want the IDE (in this case DrRacket) to suggest type annotations that the programmer can either accept or reject.A student has been working on this project and has made a good start.  We are looking for someone to extend the type inference of this tool to make it more useful for programmers.  Familiarity with Racket and DrRacket as well as some experience with the specification of type systems would be helpful for this project.  (kim@cs.pomona.edu)
  2.  Grace on the JVM
    1. Investigate methods used by other languages, like Clojure, Jython and JRuby, to not only execute on the JVM, but also to call Java libraries.  For example, some languages use Java reflection to create,  on-the-fly, a “wrapper” that can be used to call Java libraries, and more recent implementations use the new invokedynamic bytecodes. Select a suitable mechanism and implement a JVM back-end for minigrace. (mwh@mwh.geek.nz)
    2. Grace on BlueJ:
      Using Grace on the JVM, implement a Grace parser for BlueJ, and adapt BlueJ to support Grace objects. (andrew.p.black@gmail.com)
    3. Grace using java.util.concurrent:
      Using Grace on the JVM, implement concurrency libraries for Grace based on java.util.concurrent, or perhaps some Java message-passing library.
  3. Type-checker for the minigrace compiler
    We have a partial set of type rules for grace, and preliminary ideas on how to combine static and dynamic typing using the notion of gradual typing, which will guarantee type safety even mixing statically and dynamically typed code are mixed together..  The goal of this project would be to implement these rules in the existing Grace compiler, and see how they behave in practice.  (kim@cs.pomona.edu)
  4. Libraries and dialects
    1. GUnit library
      Complete the implementation of GUnit, Grace’s Unit testing framework. (andrew.p.black@gmail.com)
    2. Behavioural specification dialect
      Behaviour-Driven Development (BDD) is like test-driven development, but with an emphasis on making the specifications readable by domain experts as well as by implementors.  BDD relies on the existence of a ubiquitous language that all the stakeholders in a project can use to communicate about the behaviour of the software.The aim of this project is to (1) define a domain-specific language, similar to RSpec or Gherkin, that can be used for describing desired behavior, and (2) to implement it as a DSL in Grace, using the modules and dialects of Grace. (andrew.p.black@gmail.com)
    3. Comprehensive Collections LibrariesDesign interfaces and implementations for both mutable and immutable collection frameworks for Grace.  Inspiration can be drawn from the mutable collections of Smalltalk (with comprehensive internal iterators), the in-development revised iteration framework for Java 8, the Fortress immutable object-oriented collections,  and tree-structured collections used in some functional languages.The major challenge is not in implementation, since we are not overly concerned with efficiency, and implementation details can always be tweaked later, but in getting the interfaces right.  This is arguably at least as important as the design of the Grace language itself. (andrew.p.black@gmail.com, mwh@mwh.geek.nz)
  5. Graphics & Multimedia
    1. Javascript-based graphics (cross-platform)In order to support teaching novices to program we wish to have libraries for graphical interfaces that will let the students see the results of their program visually. Our compiler is able to target JavaScript and run programs on the web, so a convenient way of allowing the widest possible audience to use the language in this way is to have web-based graphics, likely using the canvas element.Both the design of the programming interface and the implementation are important. Ideally, the interface will be suitable for general use and potentially implementation on other platforms as well. This may involve a two-tiered implementation: an underlying wrapper around the available graphical primitives and a higher-level interface to present to students. (mwh@mwh.geek.nz)
    2. GTK-based graphicsAs for JavaScript, allowing new programmers to see the results of their programs visually, and to interact with their programs, will be helpful. We have a library that wraps the GTK+ widget toolkit, but this is a very thin wrapper and the GTK+ interface is not ideal to present to students.The GTK+ wrapper library itself is likely to require extending, but as important is designing a high-level interface to present to students. This interface may be shared with the JavaScript library, if applicable. (mwh@mwh.geek.nz)
    3. Sound support for GraceSome sort of media support is important for Grace, since media-based computing has been shown to be a good way to get beginning programmers “hooked”.  So support for still images and sound, in some way or other, is essential.   The goal of this project is to figure out the most effective way to provide audio support, and develop audio programming environments, such as Gibber or Chuck. (James Noble, kjx@ecs.vuw.ac.nz)
  6. Parallelism and Concurrency
    1. Actor-style concurrency with immutable objectsScala has a good implementation of message passing concurrency using the actor model.  Provide a library to support for the Actor model in Grace.
    2. Shared memory concurrency using Habanero modelThere are many different points of view about how to best teach parallelism.  A good approach for this project would be to find a proven set of teaching materials (such as those from Jens Mache’s NSF-sponsored project) and figure out what language features and libraries are needed to support that teaching approach in Grace.  A very promising design is that presented in the Habanero Multicore Software Research Project at https://wiki.rice.edu/confluence/display/HABANERO/Habanero+Multicore+Software+Research+Project.
  7. Curricula, Documentation, Evaluation“The best way to evaluate a design is to write the manual”
    1. Grace ResourcesBeginners learning Grace will need teaching materials: text, web pages, examples, assignments, videos, screencasts…  Even though the language design is still evolving, it is now stable enough that we plan to start teaching experiments later in 2013. We need resources for students and instructors to help them learn and teach Grace — and to help us find the parts of the language that are difficult to teach or to explain. (James Noble, kjx@ecs.vuw.ac.nz)
    2. Grace for the impatient/ How to design Grace programs/ Grace by Example/  There are a lots of great programming books about particular languages. This task is to pick your favourite programming language book and Gracify it. We hope this will find some examples that work well in Grace, and others that indicate rough spots in the language design (James Noble, kjx@ecs.vuw.ac.nz)

Leave a Reply

Your email address will not be published. Required fields are marked *