Index: doc/proposals/virtual.txt
===================================================================
--- doc/proposals/virtual.txt	(revision 63c2bca95066131a0c16dfa60fa782325c57b136)
+++ doc/proposals/virtual.txt	(revision 63c2bca95066131a0c16dfa60fa782325c57b136)
@@ -0,0 +1,146 @@
+Proposal for virtual functionality
+
+Imagine the following code :
+
+trait drawable(otype T) {
+      void draw(T* );
+};
+
+struct text {
+      char* text;
+};
+
+void draw(text*);
+
+struct line{
+      vec2 start;
+      vec2 end;
+};
+
+void draw(line*);
+
+While all the members of this simple UI support drawing creating a UI that easily
+supports both these UI requires some tedious boiler-plate code :
+
+enum type_t { text, line };
+
+struct widget {
+      type_t type;
+      union {
+            text t;
+            line l;
+      };
+};
+
+void draw(widget* w) {
+      switch(w->type) {
+            case text : draw(&w->text); break;
+            case text : draw(&w->text); break;
+            default : handle_error(); break;
+      }
+}
+
+While this code will work as indented, adding any new widgets or any new widget behaviors
+requires changing existing code to add the desired functionality. To ease this maintenance
+effort required CFA introduces the concept of dynamic types, in a manner similar to C++.
+
+A simple usage of dynamic type with the previous example would look like :
+
+drawable* objects[10];
+fill_objects(objects);
+
+while(running) {
+      for(drawable* object : objects) {
+            draw(object);
+      }
+}
+
+However, this is not currently do-able in the current CFA and furthermore is not
+possible to implement statically. Therefore we need to add a new feature to handle
+having dynamic types like this (That is types that are found dynamically not types
+that change dynamically).
+
+C++ uses inheritance and virtual functions to find the
+desired type dynamically. CFA takes inspiration from this solution.
+
+What we really want to do is express the fact that calling draw() on a object
+should find the dynamic type of the parameter before calling the routine, much like the
+hand written example given above. We can express this by adding the virtual keyword on
+the parameter of the constraints on our trait:
+
+trait drawable(otype T) {
+      void draw(virtual T* );
+};
+
+This expresses the idea that drawable is similar to an abstract base class in C++ and
+also gives meaning to trying to take a pointer of drawable. That is anything that can
+be cast to a drawable pointer has the necessary information to call the draw routine on
+that type. Before that drawable was only a abstract type while now it also points to a
+piece of storage which specify which behavior the object will have at run time.
+
+This storage needs to be allocate somewhere. C++ just adds an invisible pointer at
+the beginning of the struct but we can do something more explicit for users, actually
+have a visible special field :
+
+struct text {
+      char* text;
+      vtable drawable;
+};
+
+struct line{
+      vtable drawable;
+      vec2 start;
+      vec2 end;
+};
+
+With these semantics, adding a "vtable drawable" means that text pointers and line pointers are now
+convertible to drawable pointers. This conversion will not necessarily be a type only change however, indeed,
+the drawable pointer will point to the field "vtable drawable" not the head of the struct. However, since all
+the types are known at compile time, converting pointers becomes a simple offset operations.
+
+The vtable field contains a pointer to a vtable which contains all the information needed for the caller
+to find the function pointer of the desired behavior.
+
+One of the limitations of this design is that it does not support double dispatching, which
+concretely means traits cannot have routines with more than one virtual parameter. This design
+would have many ambiguities if it did support multiple virtual parameter.
+
+Extensibility.
+
+One of the obvious critics of this implementation is that it lacks extensibility for classes
+that cannot be modified (ex: Linux C headers). However this solution can be extended to
+allow more extensibility by adding "Fat pointers".
+
+Indeed, users could already "solve" this issue by writing their own fat pointers as such:
+
+trait MyContext(otype T) {
+      void* get_stack(virtual T*)
+};
+
+void* get_stack(ucontext_t *context);
+
+struct fat_ucontext_t {
+      vtable MyContext;
+      ucontext_t *context;
+}
+
+//Tedious forwarding routine
+void* get_stack(fat_ucontext_t *ptr) {
+      return get_stack(ptr->context);
+}
+
+However, users would have to write all the virtual methods they want to override and make
+them all simply forward to the existing method that takes the corresponding POCO(Plain Old C Object).
+
+The alternative we propose is to use language level fat pointers :
+
+trait MyContext(otype T) {
+      void* get_stack(virtual T*)
+};
+
+void* get_stack(ucontext_t *context);
+
+//The type vptr(ucontext_t) all
+vptr(ucontext_t) context;
+
+These behave exactly as the previous example but all the forwarding routines are automatically generated.