Below is a list of project ideas for [GSoC 2015](https://www.google-melange.com/gsoc/homepage/google/gsoc2015). These projects require familiarity with the Nim programming language so it is absolutely essential that you become familiar with Nim ahead of time.
[Nim](http://nim-lang.org) is a statically typed programming language which compiles primarily to C and has an excellent performance/productivity ratio. Nim's design focuses on efficiency, expressiveness, elegance.
Areas of the project you may wish to work on include the [Nim compiler](#wiki-nim-compiler) which is itself written in Nim, Nim's [standard library](#wiki-standard-library) and/or the [tools and infrastructure](#wiki-tools--infrastructure) of Nim which includes the Nim package manager (nimble).
To get started you will need to clone the Nim repository and then subsequently bootstrap the compiler, instructions for doing this are located [here](https://github.com/Araq/Nim#compiling). You can then move onto the [tutorial](http://nim-lang.org/tut1.html) and read through the [other documentation](http://nim-lang.org/documentation.html) as well.
We encourage you to join the #nim IRC channel on Freenode to discuss these projects with the community and our mentors. The Nim [Forum](http://forum.nim-lang.org) and [mailing list](http://www.freelists.org/list/nim-dev) are also available. Because communication is a big part of open source development you are expected to get in touch with us before making your application, failure to do so will put your application at a great disadvantage.
The following list of projects are just some ideas that the community and the developers have come up with. You will be contributing to a programming language so there is a lot of flexibility when it comes to the projects that you can work on, this list is certainly not comprehensive so we are happy to hear any suggestions that you may have.
* Ensure that global state (that is: state stored in global variables) is kept during recompilations of the generated C code. This means the C codegen needs to emit some kind of getters and setters for global variable access.
Most of the popular garbage collected languages of today require a separately distributed run-time environment, providing only a predetermined set of garbage collection algorithms. This leaves little room for experimentation with various approaches and condemns GC researchers to develop and test their algorithms on specialized platforms such as the [Jikes RVM](http://jikesrvm.org/) that have limited practical significance.
In contrast, in Nim, the garbage collection algorithm is chosen at compile-time and embedded in the resulting stand-alone native executable. This enables the users to pick a GC algorithm that's most suitable to their project and allows for a proliferation of GC algorithms, developed by independent groups and individuals, without requiring any modifications to be made to the standard Nim distribution.
The Nim code generator and type system can provide various GC roots marking strategies, various kinds of write/read barriers and all necessary static type information (e.g. static cycle analysis) and a GC implementation will consist only of a single Nim module (supplied as a command-line parameter) that
provides configuration for the code generator and implements the logic of the garbage collection algorithm. This module will be compiled as C code with the rest of the program and it could be easily debugged using standard C/C++ debugging and profiling tools.
Nim currently supports C, C++, Objective C and JavaScript code generation. However to run efficiently on GPUs an OpenCL backend is required. The easy way to do this is to copy OpenCL's low level mode of operation with its different ``private``, ``local``, ``global`` storage types and to simply provide an idiomatic syntax for OpenCL. So apart from syntactic sugar users get all of Nim's meta programming advantages plus good integration into Nim's infrastructure.
The vision is a ``gpu`` pragma that means a proc and all of its dependencies are translated into OpenCL instead of C but can be invoked from ordinary Nim code that is translated to C. The ``gpu`` code generator is allowed to only translate a subset of Nim, in particular things like function pointers that are not supported by OpenCL do not have to be supported. The compiler should produce a clean error message for unsupported features.
* Add support for the ``gpu`` pragma that translates to the OpenCL, version 2: https://www.khronos.org/registry/cl/sdk/2.0/docs/man/xhtml/
**Bonus points:** Support version 1.2 of the OpenCL specification: https://www.khronos.org/registry/cl/sdk/1.2/docs/man/xhtml/. This should be significantly harder as version 1.2 doesn't support a shared address space with the host environment.
* Port relevant parts of the standard library to JS.
* Make the code generator emit "source maps" for better debugging support. The current debugging support is done by emitting stack tracing instructions which slow things down and are not standard.
A high quality benchmarking library is a must for a high performance language.
Time, memory usage, and utilization of each CPU core can be interesting metrics
to measure. It should be possible to compare different implementations with a
variety of inputs semi-automatically. The output of such a benchmarking library
should be visually appealing and easy to share, similar to the one of
[criterion](http://www.serpentine.com/criterion/fibber.html), a Haskell
benchmarking library. Since Nim code can seamlessly be compiled with different
C compilers and garbage collectors, make it possible to run benchmarks with
combinations of these.
**Tasks:**
* Implement ways to reliably measure time, memory usage and other metrics on multiple platforms. See [bench.nim](https://github.com/def-/nim-benchmarksgame/blob/master/bench.nim) for a start of doing this on Linux.
* Implement a way to specify inputs of different sizes for the code to be tested.
* Create Output reports in a nice HTML with Graphs and JavaScript.
**Bonus Points:**
* Make it possible to run benchmark code from other languages as well.
* Use this library as the basis of a modern benchmarking game where participants submit algorithm implementations in many languages for comparisons, similar to [The Benchmarks Game](http://benchmarksgame.alioth.debian.org/).
**Expected Result:** A high quality benchmarking library for Nim.
**Difficulty:** Easy to Medium (depending on the scope)
* Start implementing a high level game library on top of SDL2 and OpenGL, inspired by other game libraries like Piston and Pyglet.
* Prove the usability to write a simple Minecraft clone in the spirit of the 500 line Python/Pyglet [Minecraft](https://github.com/fogleman/Minecraft).
Nim's [c2nim tool](https://github.com/nim-lang/c2nim/) helps create Nim bindings for C libraries. However, c2nim does not parse the whole C language, and is not currently supposed to import whole APIs into Nim mechanically, but rather to serve as a starting point for manual definition of interfaces to C libraries. c2nim is particularly effective in dealing with C's preprocessor macros, but is
Make c2nim accept more C declarations than it currently does, and produce corresponding Nim declarations. This can be done either by directly filling in the missing capabilities, or by interfacing it with a mature tool for parsing C code, such as LLVM's Clang or the GCC-XML tool. If one of these tools is used, then it is expected that it would not suffice by itself, but rather augment the current c2nim parser, since these tools have their own limitations. A possible implementation might pass
the header file once through GCC-XML to parse C declarations, and would use the current c2nim parser on lines that start with '#' to parse preprocessor definitions. c2nim would then process the parsed headers and produce constants, types, macros and proc declarations similar to those that it produces now.
* refactor c2nim so that it can generate declarations from the parsed output of the above parser, rather than directly from .h files as it currently does.
* combine the output from the previous task with the declarations that c2nim produces for preprocessor macros.
Lexer generators are useful tools for writing all sorts of parsers. Currently Nim lacks native lexer generators. This project involves the implementation of a lexer generator. It should be modeled after [re2c](http://re2c.org/) or alternatively it can be based on the wide number of existing lexer generators such as Flex.
[Ragel](http://www.complang.org/ragel/) is a "finite-state machine compiler with output support for C, C++, C#, Objective-C, D, Java, OCaml, Go, and Ruby source code." This project involves the implementation of a Nim backend for Ragel. This can be based on the large number of preexisting backends listed previously. Ragel itself is written in C++, so C++ programming should be familiar to you. Ragel embeds code in the backend language directly and then generates a regular source code file from this. Ideally the new Nim backend would end upstream in Ragel, but alternatively we can maintain it ourselves.