From 2ecf56423d7843adf9ee86ed5259e0f6f7021f7e Mon Sep 17 00:00:00 2001 From: Andreas Rumpf Date: Fri, 20 Feb 2015 14:52:14 +0100 Subject: [PATCH] Updated GSoC 2015 Ideas (markdown) --- GSoC-2015-Ideas.md | 27 ++++++++++++++------------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/GSoC-2015-Ideas.md b/GSoC-2015-Ideas.md index 4409c35..c3770c1 100644 --- a/GSoC-2015-Ideas.md +++ b/GSoC-2015-Ideas.md @@ -78,11 +78,11 @@ The Nim code generator and type system can provide various GC roots marking stra 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. **Tasks:** - * Add support for precise stack marking - * Add support for read barriers and polish the support for Levanoni/Petrank style of write barriers - * Implement the infrastructure for picking a user-supplied GC module + * Add support for precise stack marking. + * Add support for read barriers and polish the support for Levanoni/Petrank style of write barriers. + * Implement the infrastructure for picking a user-supplied GC module. -**Bonus points:** Implement simple forms of variety of GC algorithms as a proof-of-concept +**Bonus points:** Implement simple forms of variety of GC algorithms as a proof-of-concept. **Expected Result:** It becomes easy to implement a custom Garbage Collector for experiments in Nim. @@ -97,7 +97,7 @@ ___ **Description:** -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 and simply provide a 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. +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. @@ -135,7 +135,7 @@ examples](https://github.com/def-/nim-unsorted) with the JS backend. * Make JS test cases. **Bonus points:** - * Speed up the JavaScript backend by targetting `asm.js` + * Speed up the JavaScript backend by targetting `asm.js`. * Write a library for communication between client-side Nim (compiled to JavaScript) and server-side Nim (compiled to C). **Expected Result:** Nim becomes more usable for client-side website development. @@ -169,7 +169,7 @@ The polyhedral model deals with iteration spaces and serves to parallelize loop programs automatically by applying algebraic transformations. As it is a traditional optimization pass in a compiler it has to prove these transformations are correct. This is remarkably similar to the task of proving -the code written down by a human being correct. So the idea of this task is to +the code written down by a human being is correct. So the idea of this task is to leverage the polyhedral model for program verification as opposed to program optimization. @@ -220,7 +220,7 @@ as well. * Add search capabilities to the online documentation. * Improve the website design and usability. * Add cross-linking capabilities in nim doc. - * Make nimble build and install the documentation locally so you have. + * Make nimble build and install the documentation locally so you have docs of all your installed libraries. * Automatically create online documentation of each nimble package. @@ -275,8 +275,9 @@ game libraries available in Nim, such as [CSFML](https://github.com/blaxpirit/nim-csfml), [SDL2](https://github.com/nim-lang/sdl2), [GLFW](https://github.com/rafaelvasco/nimrod-glfw) and -[Urho3D](https://github.com/3dicc/Urhonimo). In this idea a friendly, high -level game library should be written directly in Nim with an SDL2 and possibly +[Urho3D](https://github.com/3dicc/Urhonimo). + +In this idea a friendly, high level game library should be written directly in Nim with an SDL2 and possibly GLFW backend. This will allow games to be created more idiomatically and with less overhead involved. Other new languages like Rust have similar projects like [Piston](https://github.com/PistonDevelopers/piston). @@ -344,7 +345,7 @@ Gofmt is often cited as one of the major points for the Go programming language. It completely eliminates the need to manually adhere to style formatting, by automatically converting Go code into a consistent style. This makes the code easier to read, write and maintain as well as removes any debate -about which code style to adhere towhich code style to adhere to +about which code style to adhere to. Something similar would be nice to have in Nim, where we have additional freedoms, like case insensitivity, that should be handled in a consistent way @@ -401,7 +402,7 @@ ___ **Description:** -Lexer generators are useful tools for writing all sorts of parsers. Currently Nim lacks a native Lexer generators. This project involves the implementation of a lexer generator. It should be modelled after [re2c](http://re2c.org/) or alternatively it can be based on the wide number of existing lexer generators such as Flex. +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 modelled after [re2c](http://re2c.org/) or alternatively it can be based on the wide number of existing lexer generators such as Flex. Here is a sketch of a possible implementation: @@ -423,7 +424,7 @@ ___ **Description:** -[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 pre-existing 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. +[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 pre-existing 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. **Tasks:** * Become familiar with the template format used by Ragel and Ragel internals by studying how it works with other language backends.