- Complete support for all eC constructs in prototype Recursive Descent parser
- Porting compiling code to the new AST constructs of our prototype Recursive Descent parser
- Make eC reference counting more consistent
- Develop a String class
- Support for public inline functions
- Detecting, updating and triggering rebuild of dependencies between a single module's source files
- Dynamic code execution through libTCC (eC as a scripting language)
- Integrate with LLVM as a frontend to skip intermediate C files
- Implement Closures
- Implement Interfaces
-
Complete support for all eC constructs in prototype Recursive Descent parser
Overview: We've started a refactoring of the eC compiler around a more object-oriented approach. We're switching from Flex & Bison to our own Recursive Descent parser instead. A RD parser is much better suited at error handling than Bison, which is key for better compiler error reporting, and to improve our context sensing and auto-completion in the IDE.
A new basic parser for a good subset of the eC language is already functional (see code at http://github.com/ecere/ecere-sdk/tree/ec2/compiler/libec2), but support for all language features must be completed before it can take the place of the older parser.
Skills Required:
- Familiarity with basic object oriented programming concepts
- Familiarity with eC, C or another language in the C family (e.g. C++, C#, Java)
- Familiarity with writing recursive descent parsers
- Familiarity with compiler development
Difficulty: Hard
Lead Mentor: Jérôme St-Louis <jerome@ecere.com>
Additional Mentor: Réjean Loyer <redj@ecere.com> -
Porting compiling code to the new AST constructs of our prototype Recursive Descent parser
Overview: Before our new Recursive Descent parser can replace the existing Bison/Flex parser, all passes of the compiler code must be ported over to use the new Abstract Syntax Tree constructs. While doing this refactoring, we're looking for general improvement to the compiler to enhance its maintainability and extensibility, as the original compiler was written in C and no other major refactoring occurred since. We would like to really take advantage of the object-oriented features of eC (the compiler is self-hosting).
Skills Required:
- Familiarity with compiler development
- Familiarity with basic object oriented programming concepts
- Familiarity with eC, C or another language in the C family (e.g. C++, C#, Java)
- Familiarity with recursive descent parsers
The ability to compile at least some simple eC programs with the new compiler (Or all eC code if the eC constructs task is completed). Improved handling of incomplete source for better context sensing in the IDE.
Difficulty: Hard
Lead Mentor: Jérôme St-Louis <jerome@ecere.com>
Additional Mentor: Réjean Loyer <redj@ecere.com> -
Make eC reference counting more consistent
Overview: We would like local instantiation of class objects to follow the same reference counting rules as global and member instances, which automatically get an increment of 1 on creation and a decrement on termination or destruction of parent instance.
At the moment local instances start with a reference count of 0 and are not automatically decremented, thus requiring a 'delete'. When going out of scope they would now automatically get decremented. This would also make it more consistent with struct objects, which do not require a 'delete'.
This will require verification of all code base after implementation, but existing extra 'delete' should not hurt since they null the object which would later be deleted on going out of scope.
Skills Required:
- Familiarity with basic object oriented programming concepts
- Familiarity with eC, C or another language in the C family (e.g. C++, C#, Java)
- Familiarity with reference counting memory management
Difficulty: Medium
Lead Mentor: Jérôme St-Louis <jerome@ecere.com>
Additional Mentor: Réjean Loyer <redj@ecere.com> -
Develop a String class
Overview: We would like eC to have a String class to make string manipulation a lot easier and address issues of buffer overflows, while at the same time maintaining compatibility with C strings and performance.
The solution should also greatly reduce the need for manual memory management associated with text strings.
We would like to see types of storage for these String objects, which would all be aware of their storage limitation and all manipulation routines would check against that limitation to prevent overflows:- Local buffer (analogous to char s[256];)
- On the heap (Ability to resize)
- Pointer only (String object pointing to another string, possibly a C string literal, or another String's storage)
Skills Required:
- Familiarity with basic object oriented programming concepts
- Familiarity with eC, C or another language in the C family (e.g. C++, C#, Java)
- Familiarity with String manipulation
- Compiler development
Difficulty: Hard
Lead Mentor: Jérôme St-Louis <jerome@ecere.com>
Additional Mentor: Réjean Loyer <redj@ecere.com> -
Support for public inline functions
Overview: In order to make it possible to write small functions (e.g. vector operations) which can be inlined and optimized yet written in a separate module, we would like to add support for public inline functions. The code for such function would get stored as text in the module that defines them, and the eC compiler would insert the code in place where the function is called. Proper care would be needed to handle arguments and return values.
Skills Required:
- Familiarity with basic object oriented programming concepts
- Familiarity with eC, C or another language in the C family (e.g. C++, C#, Java)
- Familiarity with writing high performance C code
Difficulty: Easy
Lead Mentor: Jérôme St-Louis <jerome@ecere.com>
Additional Mentor: Réjean Loyer <redj@ecere.com> -
Detecting, updating and triggering rebuild of dependencies between a single module's source files
Overview: When source files within a single modules directly accesses a data member from, or instantiate an instance of, a class or struct defined in another source file, this source file needs to be rebuilt but the build system currently does not detect this. Properties and method calls, the recommended way to encapsulate data across multiple modules, are not affected by this problem. Although this is easily worked around by issuing a 'Clean' or 'Rebuild', or manually building the affected file when things start crashing, this can cause significant frustration to users, especially to those unaware of these limitations.
However, simply basing the rebuild rules on which modules import which would not be an acceptable solution, as one might have a main module that imports all others, while the main module also gets imported by each module. This often result in all files constantly being rebuilt on small changes and is an undesired behavior.
This task is about figuring out a proper solution where, after compiling any source file, the actual dependencies on other source files based on data member access and instantiations, are remembered for the next build, and the Makefile or a file included by it is updated. The '.imp' files generated by the ecc compiler might be a good place where to store this information before transfering it to the build system, as it already stores information about classes being instantiated.
Skills Required:
- Familiarity with basic object oriented programming concepts
- Familiarity with eC, C or another language in the C family (e.g. C++, C#, Java)
- Familiarity writing GNU Makefiles
Difficulty: Hard
Lead Mentor: Jérôme St-Louis <jerome@ecere.com>
Additional Mentor: Réjean Loyer <redj@ecere.com> -
Dynamic code execution through libTCC (eC as a scripting language)
Overview: With its reflection support and dynamic modules, eC always had a calling as a scripting language. We would like to explore the possibilities of scripting by leveraging both libTCC and the eC compiler library to make it possible to execute eC scripts within an application.
Skills Required:
- Familiarity with basic object oriented programming concepts
- Familiarity with eC, C or another language in the C family (e.g. C++, C#, Java)
- Familiarity with scripting languages
- FFI
- (lib)TCC
Difficulty: Easy
Lead Mentor: Jérôme St-Louis <jerome@ecere.com>
Additional Mentor: Réjean Loyer <redj@ecere.com> -
Integrate with LLVM as a frontend to skip intermediate C files
Overview: We're hoping to see an LLVM frontend for the eC language, which would output object files directly rather than C source files as it currently does. As a superset of C, it would be interesting to know what is possible in terms of integration with the LLVM compiler architecture and possibly Clang.
At the moment an abstract syntax tree is originally parsed from the eC language, and in multiple passes converted to contain only features available in C99. We would like to see how the LLVM framework could be used to convert these directly to object code rather than outputting C code.
Skills Required:
- Familiarity with basic object oriented programming concepts
- Familiarity with eC, C or another language in the C family (e.g. C++, C#, Java)
- Familiarity with the LLVM compiler framework
- Familiarity compiler development
Difficulty: Hard
Lead Mentor: Jérôme St-Louis <jerome@ecere.com>
Additional Mentor: Réjean Loyer <redj@ecere.com> -
Implement Closures
Overview: We would like to see support for closures/lambdas in eC. For example the following could be supported:
void testClosures() { int x = 10; // call the lambda and print its result - 15 PrintLn( (int y) => x + y)(5) ); }
This could be supported by generating code such as:
struct __ecereClosure1DataStruct { int * x; }; static int __ecereClosure1(struct __ecereClosure1DataStruct * __ecereClosure1Data, int y) { return (*__ecereClosure1Data->x) + y; } void testClosures() { int x = 10; // PrintLn( ((int y) => x+y) (5) ); { __ecereClosure1DataStruct __ecereClosure1Data = { &x }; PrintLn(__ecereClosure1(&__ecereClosure1Data, 5)); } }
A lot of things should of course be taken in consideration, and the initial implementation may need to establish some limitations.
The usefulness for database applications with EDA should also be considered, to achieve results similar to what LINQ is capable of.
Skills Required:
- Familiarity with basic object oriented programming concepts
- Familiarity with eC, C or another language in the C family (e.g. C++, C#, Java)
- Familiarity with closures and functional programming
- Familiarity with language design and compiler development
- Familiarity with LINQ
Difficulty: Hard
Lead Mentor: Jérôme St-Louis <jerome@ecere.com>
Additional Mentor: Réjean Loyer <redj@ecere.com> -
Implement Interfaces
Overview: We would like to see support for interfaces in eC. These could work in a way similiar to Java interfaces, or could adopt some aspects of traits as found in Rust. Interfaces could be useful to remedy the fact that eC does not support multiple inheritance.
The syntax could look something like this:
public interface FinancialAccount { void deposit(int amount); int checkout(); } public class AtmAccount implements FinancialAccount { void deposit(int amount) { } int checkout() { } } public class BankAccount implements FinancialAccount { void deposit(int amount) { } int checkout() { } } void test() { BankAccount ba { }; AtmAccount aa { }; List
services { [ aa, ba ] }; for(s : services) { s.deposit(10); s.checkout(); } }
Skills Required:
- Familiarity with basic object oriented programming concepts
- Familiarity with eC, C or another language in the C family (e.g. C++, C#, Java)
- Familiarity with language design and compiler development
- Familiarity with Java
- Familiarity with Rust
Difficulty: Hard
Lead Mentor: Jérôme St-Louis <jerome@ecere.com>
Additional Mentor: Réjean Loyer <redj@ecere.com>