Generics/templates

[GoogleCodeExporter]

Design and implement some kind of generic programming system. It can be based 
heavily on type inference, but it should allow basic constructs like generic 
containers and so on without needing crufty nonsense like boxing/unboxing and 
lots of explicit typecasts.

This can work either as generics or as C++ style templates or even full 
compile-time macros. The merits of each approach should be considered carefully.

Original issue reported on code.google.com by don.ap...@gmail.com on 15 Feb 2012 at 8:02

[GoogleCodeExporter]

structure list<T>
{
    remove: T item
    add: T item
    count: integer
    //...
}

list<T>:remove: T item
{
    //...
}

Given the above as our "template" or "generic" or even "compile time macro"

Advantages of the syntax: It uses already understood C#/Java "generics" style 
type identification, its also fairly recognizable to a C++ user as well.

Now, on to the generics vs templates discussion:

Generics:
These are generated at runtime/VM time/JIT time.

    Advantages:
        - You can dynamically generate new instances based on types not known till runtime.
        - Compilation is extremely fast, only a single "generic" instance of the type needs to be made AND validated.
        - Smaller base executable size, as there needs to be only one hardcopy of the actual generic type.

    Disadvantages:
        - Without type expansion you are limited to very general operations on the input type. As an example, its impossible for the following code to work right with generics:
            generic_add<T>: T a, T b -> T c { c = a + b; }
          as their is no guarantee that an operator + is available to perform the operation on those types. Validation can be performed on any SPECIFIC instances of generic_add that is used, such as generic_add(1, 2), however when the types that may be used are unknown (i.e. runtime generated or discovered), then such behavior cannot be solved without runtime failures of the generics... it gets messy fast. This can be partially solved through the use of constraints (if supported).
        - JIT time memory growth is unbound. While the static compiled executable is known, the instances that need to be generated at runtime can easily grow without bound (one for each type).

Templates:
These are generated at compile time from an "input" template type

    Advantages:
        - Allows for advanced operations such as:
            generic_add<T> : T a, T b -> T c { c = a + b }
          Since we can validate that all of the conditions are met at compile time
        - Static memory size, since all of the combinations are generated at compile time all known combinations are known prior to application startup.
        - Optimizations. Since they are generated at compile time then various types of specialized operations, such as instance folding and pointer collapsing can be performed.

    Disadvantages:
        - Compile times will grow with templates, as a new instance has to be created for each specified type and then validation on the type has to be performed.
        - Executable size grows as the number of template type instances are created.
        - You lose some of the flexibility of generics and type constraints since everything is determined at compile time.

Original comment by ryoohki@gmail.com on 15 Feb 2012 at 8:41

[GoogleCodeExporter]

+1 for angle brackets.

Not sure about how I want to do member function syntax yet, though. I need to 
ponder on that and write up my thoughts on the Epoch "object" model at some 
point.

Original comment by don.ap...@gmail.com on 15 Feb 2012 at 8:49

[GoogleCodeExporter]

Templates have been implemented in rudimentary form in the current source 
trunk. Future development in this vein should be based on new enhancement 
requests/bug reports.

Original comment by don.ap...@gmail.com on 14 Nov 2012 at 12:20

• Changed state: Fixed