diff --git a/doc/go_spec.txt b/doc/go_spec.txt
index 7417e03c40..d17b126cb2 100644
--- a/doc/go_spec.txt
+++ b/doc/go_spec.txt
@@ -1,7 +1,7 @@
 The Go Programming Language Specification (DRAFT)
 ----
 
-Robert Griesemer, Rob Pike, Ken Thompson
+Russ Cox, Robert Griesemer, Rob Pike, Ian Taylor, Ken Thompson
 
 (February 11, 2009)
 
@@ -19,6 +19,7 @@ Any part may change substantially as design progresses.
 
 <!--
 Biggest open issues:
+[ ] General iterators
 [ ] Conversions:
 	- current situation is messy
 	- 2 (3?) different notations for the same thing
@@ -39,7 +40,7 @@ Decisions in need of integration into the doc:
 Todo's:
 [ ] there is some funny-ness regarding ';' and empty statements and label decls
 [ ] document illegality of package-external tuple assignments to structs
-	w/ private fields: P.T{1, 2} illegal since same as P.T{a: 1, b: 2} for
+	w/ private fields: P.T(1, 2) illegal since same as P.T(a: 1, b: 2) for
 	a T struct { a b int }.
 [ ] clarification on interface types, rules
 [ ] clarify tuples
@@ -66,13 +67,13 @@ Smaller issues:
 [ ] Is . import implemented / do we still need it?
 [ ] Do we allow empty statements? If so, do we allow empty statements after a label?
     and if so, does a label followed by an empty statement (a semicolon) still denote
-	a for loop that is following, and can break L be used inside it?
-[ ] Russ: If we use x.(T) for all conversions, we could use T() for "construction"
-    and type literals - would resolve the parsing ambiguity of T{} in if's
-	
+	a for loop that is following, and can break L be used inside it?	
 
 
 Closed:
+[x] Russ: If we use x.(T) for all conversions, we could use T() for "construction"
+    and type literals - would resolve the parsing ambiguity of T{} in if's -
+	switching to () for literals, conversion discussion still open
 [x] Russ: consider re-introducing "func" for function type. Make function literals
 	behave like slices, etc. Require no &'s to get a function value (solves issue
 	of func{} vs &func{} vs &func_name).
@@ -1820,7 +1821,7 @@ Literals for composite data structures consist of the type of the value
 followed by a braced expression list for array, slice, and structure literals,
 or a list of expression pairs for map literals.
 
-	CompositeLit = LiteralType "{" [ ( ExpressionList | ExprPairList ) [ "," ] ] "}" .
+	CompositeLit = LiteralType "(" [ ( ExpressionList | ExprPairList ) [ "," ] ] ")" .
 	LiteralType = Type | "[" "..." "]" ElementType .
 	ExprPairList = ExprPair { "," ExprPair } .
 	ExprPair = Expression ":" Expression .
@@ -1839,7 +1840,7 @@ Given
 
 one can write
 
-	pi := Num{Rat{22, 7}, 3.14159, "pi"};
+	pi := Num(Rat(22, 7), 3.14159, "pi");
 
 The length of an array literal is the length specified in the LiteralType.
 If fewer elements than the length are provided in the literal, the missing
@@ -1848,24 +1849,24 @@ It is an error to provide more elements than specified in LiteralType. The
 notation "..." may be used in place of the length expression to denote a
 length equal to the number of elements in the literal.
 
-	buffer := [10]string{};               // len(buffer) == 10
-	primes := [6]int{2, 3, 5, 7, 9, 11};  // len(primes) == 6
-	days := [...]string{"sat", "sun"};    // len(days) == 2
+	buffer := [10]string();               // len(buffer) == 10
+	primes := [6]int(2, 3, 5, 7, 9, 11);  // len(primes) == 6
+	days := [...]string("sat", "sun");    // len(days) == 2
 
 A slice literal is a slice describing the entire underlying array literal.
 Thus, the length and capacity of a slice literal is the number of elements
 provided in the literal. A slice literal of the form
 
-	[]T{x1, x2, ... xn}
+	[]T(x1, x2, ... xn)
 
 is essentially a shortcut for a slice operation applied to an array literal:
 
-	[n]T{x1, x2, ... xn}[0 : n]
+	[n]T(x1, x2, ... xn)[0 : n]
 
 Map literals are similar except the elements of the expression list are
 key-value pairs separated by a colon:
 
-	m := map[string]int{"good": 0, "bad": 1, "indifferent": 7};
+	m := map[string]int("good": 0, "bad": 1, "indifferent": 7);
 
 TODO: Consider adding helper syntax for nested composites
 (avoids repeating types but complicates the spec needlessly.)
@@ -2045,7 +2046,7 @@ of subarrays. The index expressions in the slice select which elements appear
 in the result.  The result has indexes starting at 0 and length equal to the
 difference in the index values in the slice.  After slicing the array "a"
 
-	a := [4]int{1, 2, 3, 4};
+	a := [4]int(1, 2, 3, 4);
 	s := a[1:3];
 
 the slice "s" has type "[]int", length 2, and elements
@@ -2163,9 +2164,9 @@ For instance, consider the function
 
 and the call
 
-	f(42, "foo", 3.14, true, &[]int{1, 2, 3})
+	f(42, "foo", 3.14, true, []int(1, 2, 3))
 
-Upon invocation, the parameters "3.14", "true", and "*[3]int{1, 2, 3}"
+Upon invocation, the parameters "3.14", "true", and "[]int(1, 2, 3)"
 are wrapped into a struct and the pointer to the struct is passed to f.
 In f the type of parameter "f_extra" is "interface{}".
 The dynamic type of "f_extra" is the type of the value assigned
@@ -2175,11 +2176,11 @@ up for illustration only, they are not accessible via reflection):
 	*struct {
 		arg0 float;
 		arg1 bool;
-		arg2 *[3]int;
+		arg2 []int;
 	}
 
 The values of the fields "arg0", "arg1", and "arg2" are "3.14", "true",
-and "*[3]int{1, 2, 3}".
+and "[]int(1, 2, 3)".
 
 As a special case, if a function passes a "..." parameter as the argument
 for a "..." parameter of a function, the parameter is not wrapped again into
@@ -2282,14 +2283,11 @@ to strings and arrays; all other arithmetic operators apply to integer types onl
 	<<   left shift      integer << unsigned integer
 	>>   right shift     integer >> unsigned integer
 
-Strings and arrays can be concatenated using the "+" operator
-(or via the "+=" assignment):
+Strings can be concatenated using the "+" operator (or the "+=" assignment):
 
 	s := "hi" + string(c)
-	a += []int{5, 6, 7}
 
-String and array addition creates a new array or string by copying the
-elements.
+String addition creates a new string by copying the elements.
 
 For integer values, "/" and "%" satisfy the following relationship:
 
@@ -2846,7 +2844,7 @@ scope rules, Rule 3). In this case their types are the array index and element,
 or the map key and value types, respectively.
 
 	var a [10]string;
-	m := map[string]int{"mon":0, "tue":1, "wed":2, "thu":3, "fri":4, "sat":5, "sun":6};
+	m := map[string]int("mon":0, "tue":1, "wed":2, "thu":3, "fri":4, "sat":5, "sun":6);
 	
 	for i, s := range a {
 		// type of i is int
@@ -3177,11 +3175,6 @@ Predeclared functions
 	typeof
 
 
-TODO: (gri) suggests that we should consider assert() as a built-in function.
-It is like panic, but takes a boolean guard as first argument. (rsc also thinks
-this is a good idea).
-
-
 Length and capacity
 ----
 
@@ -3244,7 +3237,7 @@ representation of the integer.
 3b) Converting an array of uint8s yields a string whose successive
 bytes are those of the array.  (Recall byte is a synonym for uint8.)
 
-	string([]byte{'h', 'e', 'l', 'l', 'o'}) // "hello"
+	string([]byte('h', 'e', 'l', 'l', 'o')) // "hello"
 
 There is no linguistic mechanism to convert between pointers
 and integers. A library may be provided under restricted circumstances
@@ -3481,7 +3474,7 @@ Systems considerations
 Package unsafe
 ----
 
-The special package "unsafe", known to the compiler, provides facilities
+The built-in package "unsafe", known to the compiler, provides facilities
 for low-level programming including operations that violate the Go type
 system. A package using "unsafe" must be vetted manually for type safety.
 
@@ -3489,7 +3482,7 @@ The package "unsafe" provides (at least) the following package interface:
 
 	package unsafe
 
-	const Maxalign
+	const Maxalign int
 
 	type Pointer *any
 
@@ -3532,6 +3525,9 @@ a variable "x" of the largest arithmetic type (8 for a float64), but may
 be smaller on systems that have less stringent alignment restrictions
 or are space constrained.
 
+The results of calls to "unsafe.Alignof", "unsafe.Offsetof", and
+"unsafe.Sizeof" are compile-time constants.
+
 
 Size and alignment guarantees
 ----