Index: doc/proposals/virtual.txt
===================================================================
--- doc/proposals/virtual.txt	(revision d49bfa8ec26d4120dc115e26fe83c7af90beb85b)
+++ doc/proposals/virtual.txt	(revision c72f9fdda3f7c30ea9be86498e52e5e155eaf6dc)
@@ -2,7 +2,7 @@
 
 There are two types of virtual inheritance in this proposal, relaxed
-(implicate) and strict (explicate). Relaxed is the simpler case that uses the
+(implicit) and strict (explicit). Relaxed is the simpler case that uses the
 existing trait system with the addition of trait references and vtables.
-Strict adds some constrants and requires some additional notation but allows
+Strict adds some constraints and requires some additional notation but allows
 for down-casting.
 
@@ -28,6 +28,6 @@
 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 :
+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 };
@@ -49,5 +49,5 @@
 }
 
-While this code will work as indented, adding any new widgets or any new
+While this code will work as implemented, 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
@@ -83,6 +83,7 @@
 This could be implied in simple cases like this one (single parameter on the
 trait and single generic parameter on the function). In more complex cases it
-would have to be explicately given, or a strong convention would have to be
-enforced.
+would have to be explicitly given, or a strong convention would have to be
+enforced (e.g. implementation of trait functions is always drawn from the 
+first polymorphic parameter).
 
 Once a function in a trait has been marked as virtual it defines a new
@@ -95,7 +96,7 @@
 one virtual parameter. The program must have a single table to look up the
 function on. Using trait references with traits with more than one parameter
-is also restricted, inistially forbidden, see extention.
-
-Extention: Multi-parameter Virtual Traits:
+is also restricted, initially forbidden, see extension.
+
+Extension: Multi-parameter Virtual Traits:
 
 This implementation can be extented to traits with multiple parameters if
@@ -140,8 +141,8 @@
 So the trait error is the head of a new tree and io_error is a child of it.
 
-Also the parent trait is implicately part of the assertions of the children,
+Also the parent trait is implicitly part of the assertions of the children,
 so all children implement the same operations as the parent. By the unique
-path down the tree, we can also uniquely order them so that prefixs of a
-child's vtable has the same format as the parent's.
+path down the tree, we can also uniquely order them so that a prefix of a
+child's vtable has the same format as its parent's.
 
 This gives us an important extra feature, runtime checking of the parent-child
@@ -171,5 +172,8 @@
 This can generate a seperate vtable for each U for which all the T+U
 implementations are provided. These are then seperate nodes in the tree (or
-the root of different trees) as if each was created individually.
+the root of different trees) as if each was created individually. Providing a 
+single unique instance of these nodes would be the most difficult aspect of 
+this extension, possibly intractable, though with sufficient hoisting and 
+link-once duplication it may be possible.
 
 Example:
@@ -187,11 +191,11 @@
 
 Currently traits must be the internal nodes and structs the leaf nodes.
-Structs could be made internal nodes as well, and might specify structural
-inheritance.
+Structs could be made internal nodes as well, in which case the child structs 
+would likely structurally inherit the fields of their parents.
 
 
 Storing the Virtual Lookup Table (vtable):
 
-We have so fare been silent on how the vtable is created, stored and accessed.
+We have so far been silent on how the vtable is created, stored and accessed.
 
 Creation happens at compile time. Function pointers are found by using the