Below is a list of project ideas for [GSoC](https://www.google-melange.com/gsoc/homepage/google/gsoc2014) 2014. All these projects require familiarity with the Nimrod programming language, or at minimum, experience with similar programming languages such as C, C#, Java, Python, etc. It is absolutely essential that you become familiar with Nimrod ahead of time.
[Nimrod](http://nimrod-lang.org) is a statically typed programming language which compiles primarily to C. Areas of the project you may wish to work on include the [Nimrod compiler](#wiki-nimrod-compiler) which is itself written in Nimrod, Nimrod's [standard library](#wiki-standard-library) and/or the [tools and infrastructure](#wiki-tools--infrastructure) of Nimrod which includes the Nimrod build farm (Nimbuild) and the Nimrod package manager (babel).
We encourage you to join the #nimrod IRC channel on Freenode to discuss these projects with the community and our mentors. The Nimrod [Forum](http://forum.nimrod-lang.org) is 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.
Implement proper coroutines that provide light-weight collaborative multi-tasking. The coroutines must be cooperative - this means a coroutine is suspended only when it explicitly yields. The coroutines must never be migrated across threads - this means that of all the coroutines started from a thread, exactly one is running at any point in time while the others are suspended. Other semantic details are to be nailed down as part of the project.
Nimrod already supports "closure iterators" which are comparable to Python's generators. However closure iterators are much less powerful than proper coroutines because they don't allow capturing the full call stack. This means, for instance, that closure iterators cannot be recursive.
Nimrod 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 and simply provide a nimrodic syntax for OpenCL. So apart from syntactic sugar users get all of Nimrod's meta programming advantages plus good integration into Nimrod'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 Nimrod code that is translated to C. The ``gpu`` code generator is allowed to only translate a subset of Nimrod, 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.
**Expected Result:** The GPU code generator works on a selected set of examples/test cases.
**Tasks:**
* Add support for new pointer types in the compiler like ``global``, ``private``.
* Add support for workg groupss.
* 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.
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 Nimrod, 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 Nimrod distribution.
The Nimrod 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 Nimrod 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.
Nimrod's Compiler as a Service feature allows IDEs to query the compiler for things like code suggestions, definition lookups and more. The current implementation works but has some issues.
The Nimrod standard library currently lacks a YAML parsing module. YAML is a popular "human-readable data serialization format", its popularity is especially evident in the Ruby community. As such it would be a great addition to Nimrod's standard library. This task requires you to read the [YAML specification](http://yaml.org/spec/) and to create a module which will be able to parse YAML data into an AST. Subsequently the parser can be used to create a high-level API to access the data similar to the current design of the [json](http://nimrod-lang.org/json.html) module which provides a low-level parser and a higher-level interface which builds on top of the parser.
Nimrod's standard library currently has a [``fsmonitor``](http://build.nimrod-lang.org/docs/fsmonitor.html) ([source code](https://github.com/Araq/Nimrod/blob/devel/lib/pure/fsmonitor.nim)) module which allows the programmer to monitor the filesystem for directory and file changes. The problem is that this module currently only supports Linux.
* Allow the ``fsmonitor`` module to work on Microsoft Windows by using native APIs to gather information about changes in monitored files and directories.
* Revise the ``fsmonitor`` module API to decouple Unix/Linux file handle paradigms from the API, allowing easier implementations of multiple native backends.
* Integrate the ``fsmonitor`` module's polling mechanism into the new [asynchronous IO modules](https://github.com/Araq/Nimrod/blob/newasync/lib/pure/asyncio2.nim).
The [Nimrod documentation](http://nimrod-lang.org/lib.html) is generally good but it lacks helpful code examples. It is also using a rather old design which is not on par with some of the documentation of other software projects out there. [Read the docs](https://readthedocs.org/) is a good example of attractive as well as readable documentation, it is something we would be after in this project.
* Create and design new CSS and HTML layouts for the documentation, the design should put readability above eyecandy. That said, the new design should be attractive to developers.
* Add comments to the compiler internals, documenting the various mechanisms and mechanics the compiler uses to analyze and transform nimrod code to the code of the specified backend.
* Reduce the number of assumptions the Nimrod builder makes about its host system, in order to reduce configuration restrictions. Assumptions include location and usage of external tools, such as git.
* Implement benchmark tests in the builder and generate graphs showing the time taken to perform those benchmarks on the Nimbuild site. This can include bootstrap times, and test times too.
* Generate images showing the status of the build to be shown in Nimrod's Github repo and/or Nimrod's website.
* Improve the download tables on Nimbuild's homepage and generate embeddable download tables for the Nimrod website.
Babel is the Nimrod package manager. It is currently very basic and some important features are still missing. Babel packages are stored in user-controlled repositories with support for Git and Mercurial currently present.
**Possible tasks:**
* Add support for other VCS' alongside Git and Mercurial.
* Create a website which tracks packages similar to hackage, npm, the [DUB registry](http://code.dlang.org/) etc.
* Add support for the removal of packages.
* Automate the package submission process.
* Expand the babel tester to test more dependency scenarios.
