Index: doc/proposals/vtable.md
===================================================================
--- doc/proposals/vtable.md	(revision 24662ff50dfb325fe8845d2ec497b66224708e7d)
+++ doc/proposals/vtable.md	(revision 4cf2472f2b5659dfb57b51b9748e18e9dcb9c543)
@@ -3,12 +3,11 @@
 
 This is an adaptation of the earlier virtual proposal, updating it with new
-ideas, reframing it and laying out more design decisions.
+ideas, re-framing it and laying out more design decisions. It should
+eventually replace the earlier proposal, but not all features and syntax have
+been converted to the new design.
 
 The basic concept of a virtual table (vtable) is the same here as in most
 other languages. They will mostly contain function pointers although they
 should be able to store anything that goes into a trait.
-
-This should replace the virtual proposal, although all not all features have
-been converted to the new design.
 
 Trait Instances
@@ -39,4 +38,8 @@
 	combine(obj, 5);
 
+As with `struct` (and `union` and `enum`), `trait` might be optional when
+using the trait as a type name. A trait may be used in assertion list as
+before.
+
 Internally a trait object is a pair of pointers. One to an underlying object
 and the other to the vtable. All calls on an trait are implemented by looking
@@ -44,6 +47,7 @@
 remaining arguments to it.
 
-Trait objects can be copied and moved by copying and moving the pointers.
-They should also be able to own or borrow the underlying object.
+Trait objects can be moved by moving the pointers. Almost all other operations
+require some functions to be implemented on the underlying type. Depending on
+what is in the virtual table a trait type could be a dtype or otype.
 
 Hierarchy
@@ -56,5 +60,5 @@
 tree.
 
-The hierachy would be a tree of types, of traits and structs. Currently we do
+The hierarchy would be a tree of types, of traits and structs. Currently we do
 not support structural extension, so traits form the internal nodes and
 structures the leaf nodes.
@@ -62,5 +66,5 @@
 The syntax is undecided but it will include a clause like `virtual (PARENT)`
 on trait and struct definitions. It marks out all types in a hierarchy.
-PARENT may be omitted, if it is this type is the root of a hierachy. Otherwise
+PARENT may be omitted, if it is this type is the root of a hierarchy. Otherwise
 it is the name of the type that is this type's parent in the hierarchy.
 
@@ -73,14 +77,14 @@
 from a parent type to a child type are conditional, they check to make sure
 the underlying instance is an instance of the child type, or an instance of
-one of its children. The type then is recoverable at runtime.
+one of its children. The type then is recoverable at run-time.
 
 As with regular trait objects, calling a function on a trait object will cause
-a lookup on the the virtual table. The casting rules make sure anything that
+a look-up on the the virtual table. The casting rules make sure anything that
 can be cast to a trait type will have all the function implementations for
 that trait.
 
-Converting from a concrete type (structures at the edge of the hierchy) to
+Converting from a concrete type (structures at the edge of the hierarchy) to
 an abstract type works the same as with normal trait objects, the underlying
-object is packaged with a virtal table pointer. Converting back to an abstract
+object is packaged with a virtual table pointer. Converting back to an abstract
 type requires confirming the underlying type matches, but then simply extracts
 the pointer to it.
@@ -92,5 +96,5 @@
 it is the trait object could be a single pointer.
 
-It is trival to do if the field with the virtual table pointer is fixed.
+It is trivial to do if the field with the virtual table pointer is fixed.
 Otherwise some trickery with pointing to the field and storing the offset in
 the virtual table to recover the main object would have to be used.
@@ -114,5 +118,5 @@
 
 The main thing CFA would need to do it this way is some single point where
-the type declaration, including the functions that satify the trait, are
+the type declaration, including the functions that satisfy the trait, are
 all defined. Currently there are many points where this can happen, not all
 of them will have the same definitions and no way to select one over the
@@ -122,13 +126,13 @@
 time and a single vtable created for each type at compilation time.
 
-### Explicate Resolution Points:
-Slightly looser than the above, there are explicate points where the vtables
+### Explicit Resolution Points:
+Slightly looser than the above, there are explicit points where the vtables
 are resolved, but there is no limit on the number of resolution points that
 might be provided. Each time a object is bound to a trait, one of the
-resolutions is selected. This might be the most flexable option.
+resolutions is selected. This might be the most flexible option.
 
 An syntax would have to be provided as above. There may also be the option
 to name resolution points so that you can choose between them. This also
-could come with the ablity to forward declare them.
+could come with the ability to forward declare them.
 
 Especially if they are not named, these resolution points should be able to
@@ -141,11 +145,11 @@
 its own resolution. Syntax-wise this is the simplest as it should be able
 to use just the existing declarations and the conversion to trait object.
-It also is very close to the current polymorphic reolution rules.
+It also is very close to the current polymorphic resolution rules.
 
-This works as the explicate resolution points except the resolution points
-are implicate and their would be no selection of which resolution to use. The
+This works as the explicit resolution points except the resolution points
+are implicit and their would be no selection of which resolution to use. The
 closest (current) resolution is always selected.
 
-This could easily lead to an explosition of vtables as it has the most fine
+This could easily lead to an explosion of vtables as it has the most fine
 grained resolution the number of bindings in a single scope (that produces
 the same binding) could be quite high. Merging identical vtables might help
@@ -156,9 +160,9 @@
 
 Vtables interact badly with the thunk issue. Conceptually vtables are static
-like type/function data they carry, as those decitions are made by the
+like type/function data they carry, as those decisions are made by the
 resolver at compile time.
 
 Stack allocated functions interact badly with this because they are not
-static. There are serveral ways to try to resolve this, however without a
+static. There are several ways to try to resolve this, however without a
 general solution most can only buy time.
 
@@ -168,5 +172,5 @@
 
 Dynamically allocated vtables introduces memory management overhead and
-requires some way to differentate between dynamic and statically allocated
+requires some way to differentiate between dynamic and statically allocated
 tables. The stale function pointer problem continues unless those becomes
 dynamically allocated as well which gives us the same costs again.
@@ -175,3 +179,3 @@
 is now the limiting factor but it should be effectively the same as the
 shortest lifetime of a function assigned to it. However this still limits the
-lifetime "implicately" and returns to the original problem with thunks.
+lifetime "implicitly" and returns to the original problem with thunks.
