Removing usage of the do keyword from documentation

doc/guide-conditions.md

@@ -261,7 +261,7 @@ use std::task;
 fn main() {
 
     // Isolate failure within a subtask.
-    let result = do task::try {
+    let result = task::try(proc() {
 
         // The protected logic.
         let pairs = read_int_pairs();
@@ -269,7 +269,7 @@ fn main() {
             println!("{:4.4d}, {:4.4d}", a, b);
         }
 
-    };
+    });
     if result.is_err() {
             println!("parsing failed");
     }

doc/guide-pointers.md

@@ -221,9 +221,9 @@ struct Point {
 
 fn main() {
     let a = Point { x: 10, y: 20 };
-    do spawn {
+    spawn(proc() {
         println!("{}", a.x);
-    }
+    });
 }
 ~~~
 
@@ -238,9 +238,9 @@ struct Point {
 
 fn main() {
     let a = ~Point { x: 10, y: 20 };
-    do spawn {
+    spawn(proc() {
         println!("{}", a.x);
-    }
+    });
 }
 ~~~
 

doc/guide-runtime.md

@@ -236,9 +236,9 @@ extern mod green;
 
 #[start]
 fn start(argc: int, argv: **u8) -> int {
-    do green::start(argc, argv) {
+    green::start(argc, argv, proc() {
         main();
-    }
+    })
 }
 
 fn main() {}

doc/guide-tasks.md

@@ -77,11 +77,6 @@ spawn(print_message);
 
 // Print something more profound in a different task using a lambda expression
 spawn(proc() println!("I am also running in a different task!") );
-
-// The canonical way to spawn is using `do` notation
-do spawn {
-    println!("I too am running in a different task!");
-}
 ~~~~
 
 In Rust, there is nothing special about creating tasks: a task is not a
@@ -103,10 +98,10 @@ an environment that it carries across tasks.
 // Generate some state locally
 let child_task_number = generate_task_number();
 
-do spawn {
+spawn(proc() {
     // Capture it in the remote task
     println!("I am child number {}", child_task_number);
-}
+});
 ~~~
 
 ## Communication
@@ -132,10 +127,10 @@ concurrently:
 
 let (port, chan): (Port<int>, Chan<int>) = Chan::new();
 
-do spawn || {
+spawn(proc() {
     let result = some_expensive_computation();
     chan.send(result);
-}
+});
 
 some_other_expensive_computation();
 let result = port.recv();
@@ -160,10 +155,10 @@ spawns the child task.
 # use std::task::spawn;
 # fn some_expensive_computation() -> int { 42 }
 # let (port, chan) = Chan::new();
-do spawn || {
+spawn(proc() {
     let result = some_expensive_computation();
     chan.send(result);
-}
+});
 ~~~~
 
 Notice that the creation of the task closure transfers `chan` to the child
@@ -195,15 +190,15 @@ of tasks? The following program is ill-typed:
 # fn some_expensive_computation() -> int { 42 }
 let (port, chan) = Chan::new();
 
-do spawn {
+spawn(proc() {
     chan.send(some_expensive_computation());
-}
+});
 
 // ERROR! The previous spawn statement already owns the channel,
 // so the compiler will not allow it to be captured again
-do spawn {
+spawn(proc() {
     chan.send(some_expensive_computation());
-}
+});
 ~~~
 
 Instead we can use a `SharedChan`, a type that allows a single
@@ -217,9 +212,9 @@ let (port, chan) = SharedChan::new();
 for init_val in range(0u, 3) {
     // Create a new channel handle to distribute to the child task
     let child_chan = chan.clone();
-    do spawn {
+    spawn(proc() {
         child_chan.send(some_expensive_computation(init_val));
-    }
+    });
 }
 
 let result = port.recv() + port.recv() + port.recv();
@@ -247,9 +242,9 @@ might look like the example below.
 // Create a vector of ports, one for each child task
 let ports = vec::from_fn(3, |init_val| {
     let (port, chan) = Chan::new();
-    do spawn {
+    spawn(proc() {
         chan.send(some_expensive_computation(init_val));
-    }
+    });
     port
 });
 
@@ -296,7 +291,7 @@ fn partial_sum(start: uint) -> f64 {
 }
 
 fn main() {
-    let mut futures = vec::from_fn(1000, |ind| do extra::future::Future::spawn { partial_sum(ind) });
+    let mut futures = vec::from_fn(1000, |ind| extra::future::Future::spawn( proc() { partial_sum(ind) }));
 
     let mut final_res = 0f64;
     for ft in futures.mut_iter()  {
@@ -339,11 +334,11 @@ fn main() {
         let (port, chan)  = Chan::new();
         chan.send(numbers_arc.clone());
 
-        do spawn {
+        spawn(proc() {
             let local_arc : Arc<~[f64]> = port.recv();
             let task_numbers = local_arc.get();
             println!("{}-norm = {}", num, pnorm(task_numbers, num));
-        }
+        });
     }
 }
 ~~~
@@ -417,13 +412,13 @@ termination with an error).
 # use std::task;
 # fn some_condition() -> bool { false }
 # fn calculate_result() -> int { 0 }
-let result: Result<int, ()> = do task::try {
+let result: Result<int, ()> = task::try(proc() {
     if some_condition() {
         calculate_result()
     } else {
         fail!("oops!");
     }
-};
+});
 assert!(result.is_err());
 ~~~
 
@@ -502,9 +497,9 @@ Here is the code for the parent task:
 
 let (from_child, to_child) = DuplexStream::new();
 
-do spawn {
+spawn(proc() {
     stringifier(&to_child);
-};
+});
 
 from_child.send(22);
 assert!(from_child.recv() == ~"22");

doc/rust.md

@@ -2751,52 +2751,6 @@ but must enclose it.
 
 A `loop` expression is only permitted in the body of a loop.
 
-### Do expressions
-
-~~~~ {.ebnf .gram}
-do_expr : "do" expr [ '|' ident_list '|' ] ? '{' block '}' ;
-~~~~
-
-A _do expression_ provides a more-familiar block syntax
-for invoking a function and passing it a newly-created a procedure.
-
-The optional `ident_list` and `block` provided in a `do` expression are parsed
-as though they constitute a procedure expression;
-if the `ident_list` is missing, an empty `ident_list` is implied.
-
-The procedure expression is then provided as a _trailing argument_
-to the outermost [call](#call-expressions) or
-[method call](#method-call-expressions) expression
-in the `expr` following `do`.
-If the `expr` is a [path expression](#path-expressions), it is parsed as though it is a call expression.
-If the `expr` is a [field expression](#field-expressions), it is parsed as though it is a method call expression.
-
-In this example, both calls to `f` are equivalent:
-
-~~~~
-# fn f(f: proc(int)) { }
-# fn g(i: int) { }
-
-f(proc(j) { g(j) });
-
-do f |j| {
-    g(j);
-}
-~~~~
-
-In this example, both calls to the (binary) function `k` are equivalent:
-
-~~~~
-# fn k(x:int, f: proc(int)) { }
-# fn l(i: int) { }
-
-k(3, proc(j) { l(j) });
-
-do k(3) |j| {
-   l(j);
-}
-~~~~
-
 ### For expressions
 
 ~~~~ {.ebnf .gram}

doc/tutorial.md

@@ -1796,48 +1796,20 @@ call_it(proc(n) {
 });
 ~~~~
 
-This is such a useful pattern that Rust has a special form of function
-call for these functions.
-
-~~~~
-# fn call_it(op: proc(v: int)) { }
-do call_it() |n| {
-    println!("{}", n);
-}
-~~~~
-
-The call is prefixed with the keyword `do` and, instead of writing the
-final procedure inside the argument list, it appears outside of the
-parentheses, where it looks more like a typical block of
-code.
-
-`do` is a convenient way to create tasks with the `task::spawn`
-function.  `spawn` has the signature `spawn(fn: proc())`. In other
-words, it is a function that takes an owned closure that takes no
-arguments.
+A practical example of this pattern is found when using the `spawn` function,
+which starts a new task.
 
 ~~~~
 use std::task::spawn;
-
-do spawn() || {
-    debug!("I'm a task, whatever");
-}
+spawn(proc() {
+    debug!("I'm a new task")
+});
 ~~~~
 
-Look at all those bars and parentheses -- that's two empty argument
-lists back to back. Since that is so unsightly, empty argument lists
-may be omitted from `do` expressions.
-
-~~~~
-use std::task::spawn;
-
-do spawn {
-   debug!("Kablam!");
-}
-~~~~
-
-If you want to see the output of `debug!` statements, you will need to turn on `debug!` logging.
-To enable `debug!` logging, set the RUST_LOG environment variable to the name of your crate, which, for a file named `foo.rs`, will be `foo` (e.g., with bash, `export RUST_LOG=foo`).
+If you want to see the output of `debug!` statements, you will need to turn on
+`debug!` logging.  To enable `debug!` logging, set the RUST_LOG environment
+variable to the name of your crate, which, for a file named `foo.rs`, will be
+`foo` (e.g., with bash, `export RUST_LOG=foo`).
 
 # Methods