Index: c/initialization.txt
===================================================================
--- src/initialization.txt	(revision 9bd6105039ae99629f8f39beb74fdf7643422d2a)
+++ 	(revision )
@@ -1,71 +1,0 @@
-From the refrat (5.5) we have our specification:
-
-    \section{Initialization} An expression that is used as an
-    \nonterm{initializer} is treated as being cast to the type of the
-    object being initialized.  An expression used in an
-    \nonterm{initializer-list} is treated as being cast to the type of
-    the aggregate member that it initializes.  In either case the cast
-    must have a single unambiguous
-    interpretation\index{interpretations}.
-
-Steps:
-
-- add a member function "void Resolver::visit( SynTree::DeclStmt
-*declStmt )"; for each DeclStmt:
-
-- do what you need to do to establish correspondences between
-expressions in the initializer and pieces of the object to be
-initialized
-
-- for each initializer expression, construct a cast expression that
-casts the value of the expression to the type of the corresponding
-sub-object
-
-- invoke the resolver recursively on each cast expression; it's an invariant
-of the resolver that attempting to resolve a cast expression results either
-in a single resolved expression (corresponding to the unambiguous interpretation
-referred to above) or a thrown SemanticError.
-
-- construct a new initializer from the resolved expressions
-
-You'll undoubtedly have to play with the CodeGen stuff a bit; I
-hacked it to spit out unresolved initializers for file-scope
-declarations so that real programs would compile.  You'll want to make
-sure that resolved initializers for all declarations are being
-generated.
-
-
-------
-
-More recent email: (I am quoted; Richard is the responder)
-> As far as I'm aware, the only way that I could currently get the correct
-> results from the unification engine is by feeding it an expression that
-> looks like "?=?( ((struct Y)x.y).a, 10 )", then picking out the pieces that
-> I need (namely the correct choice for a). Does this seem like a reasonable
-> approach to solve this problem?
-
-No, unfortunately. Initialization isn't being rewritten as assignment,
-so you shouldn't allow the particular selection of assignment
-operators that happen to be in scope (and which may include
-user-defined operators) to guide the type resolution.
-
-I don't think there is any way to rewrite an initializer as a single
-expression and have the resolver just do the right thing. I see the
-algorithm as:
-
-For each alternative interpretation of the designator:
-  Construct an expression that casts the initializer to the type of
-    the designator
-  Construct an AlternativeFinder and use it to find the lowest cost
-    interpretation of the expression
-  Add this interpretation to a list of possibilities
-Go through the list of possibilities and pick the lowest cost
-
-As with many things in the resolver, it's conceptually simple but the
-implementation may be a bit of a pain. It fits in with functions like
-findSingleExpression, findIntegralExpression in Resolver.cc, although
-it will be significantly more complicated than any of the existing
-ones.
-
-
-