eC Language & Compiler - Ideas for Google Summer of Code





eC Language / Compiler

  • 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
    Other relevant/useful skills:
    • Familiarity with compiler development
    Expected results: The new Recursive Descent parser being able to parse properly all constructs of the eC language.

    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)
    Other relevant/useful skills:
    • Familiarity with recursive descent parsers
    Expected results: The code base for the eC compiler ported over to the new recursive descent parser abstract syntax tree constructs.
    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)
    Other relevant/useful skills:
    • Familiarity with reference counting memory management
    Expected results: Having reference counting more consitent between local and global instances. Minimizing the need for manual 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)
    The heap strings should support multiple reallocation strategies. New language syntax may be developed to accomodate the declaration of characteristics and manipulation of these new strings (e.g. supporting the + operator to concatenate objects, way to specify buffer size for local strings).

    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)
    Other relevant/useful skills:
    • Familiarity with String manipulation
    • Compiler development
    Expected results: eC having a String class facilitating string manipulation while maintaining the typical performance of C strings, and also reducing the possibility of buffer overflows.

    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)
    Other relevant/useful skills:
    • Familiarity with writing high performance C code
    Expected results: Performance improvements when making use of inline functions in performance critical 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)
    Other relevant/useful skills:
    • Familiarity writing GNU Makefiles
    Expected results: No more bad builds caused by updating a subset of a module's files.

    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
    Other relevant/useful skills:
    • FFI
    • (lib)TCC
    Expected results: Being able to write eC code within an application and execute it right away without having to resort to an external compiler (useful e.g. for scripting within game editors, evaluating code for heuristics). Possibility to write a small self-contained client able to execute remote applications.

    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
    Expected results: Having the eC compiler directly output LLVM object code rather than intermediate C source files.

    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
    Other relevant/useful skills:
    • Familiarity with LINQ
    Expected results: Preliminary support for closures/lambdas in eC

    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
    Other relevant/useful skills:
    • Familiarity with Java
    • Familiarity with Rust
    Expected results: Support for interface constructs similar to what is found in Java

    Difficulty: Hard

    Lead Mentor: Jérôme St-Louis <jerome@ecere.com>
    Additional Mentor: Réjean Loyer <redj@ecere.com>



Copyright © 2017 Ecere Corporation. All rights reserved. | Design by FreeCSSTemplates.org.