---

yaml
---
r: 148671
b: refs/heads/try2
c: d62097d
h: refs/heads/master
i:
  148669: 725b52a
  148667: 9751617
  148663: 076354e
  148655: 0b1c420
  148639: fe3b860
  148607: 621c762
v: v3

Author: Armavica

[refs]

@@ -5,7 +5,7 @@ refs/heads/snap-stage3: 78a7676898d9f80ab540c6df5d4c9ce35bb50463
 refs/heads/try: 519addf6277dbafccbb4159db4b710c37eaa2ec5
 refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
 refs/heads/ndm: f3868061cd7988080c30d6d5bf352a5a5fe2460b
-refs/heads/try2: c3ae182d5ce005e15d3d1f2906bd67cb65c61f8d
+refs/heads/try2: d62097d88cee0ced0eb9508313c48d03ba355e51
 refs/heads/dist-snap: ba4081a5a8573875fed17545846f6f6902c8ba8d
 refs/tags/release-0.2: c870d2dffb391e14efb05aa27898f1f6333a9596
 refs/tags/release-0.3: b5f0d0f648d9a6153664837026ba1be43d3e2503

branches/try2/.gitignore

@@ -74,10 +74,8 @@ src/.DS_Store
 /doc/html
 /doc/latex
 /doc/std
-/doc/arena
 /doc/extra
 /doc/flate
-/doc/glob
 /doc/green
 /doc/native
 /doc/rustc

branches/try2/doc/guide-conditions.md

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

branches/try2/doc/guide-pointers.md

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

branches/try2/doc/guide-runtime.md

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

branches/try2/doc/guide-tasks.md

@@ -77,6 +77,11 @@ 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
@@ -98,10 +103,10 @@ an environment that it carries across tasks.
 // Generate some state locally
 let child_task_number = generate_task_number();
 
-spawn(proc() {
+do spawn {
     // Capture it in the remote task
     println!("I am child number {}", child_task_number);
-});
+}
 ~~~
 
 ## Communication
@@ -127,10 +132,10 @@ concurrently:
 
 let (port, chan): (Port<int>, Chan<int>) = Chan::new();
 
-spawn(proc() {
+do spawn || {
     let result = some_expensive_computation();
     chan.send(result);
-});
+}
 
 some_other_expensive_computation();
 let result = port.recv();
@@ -155,10 +160,10 @@ spawns the child task.
 # use std::task::spawn;
 # fn some_expensive_computation() -> int { 42 }
 # let (port, chan) = Chan::new();
-spawn(proc() {
+do spawn || {
     let result = some_expensive_computation();
     chan.send(result);
-});
+}
 ~~~~
 
 Notice that the creation of the task closure transfers `chan` to the child
@@ -190,15 +195,15 @@ of tasks? The following program is ill-typed:
 # fn some_expensive_computation() -> int { 42 }
 let (port, chan) = Chan::new();
 
-spawn(proc() {
+do spawn {
     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
-spawn(proc() {
+do spawn {
     chan.send(some_expensive_computation());
-});
+}
 ~~~
 
 Instead we can use a `SharedChan`, a type that allows a single
@@ -212,9 +217,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();
-    spawn(proc() {
+    do spawn {
         child_chan.send(some_expensive_computation(init_val));
-    });
+    }
 }
 
 let result = port.recv() + port.recv() + port.recv();
@@ -242,9 +247,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();
-    spawn(proc() {
+    do spawn {
         chan.send(some_expensive_computation(init_val));
-    });
+    }
     port
 });
 
@@ -291,7 +296,7 @@ fn partial_sum(start: uint) -> f64 {
 }
 
 fn main() {
-    let mut futures = vec::from_fn(1000, |ind| extra::future::Future::spawn( proc() { partial_sum(ind) }));
+    let mut futures = vec::from_fn(1000, |ind| do extra::future::Future::spawn { partial_sum(ind) });
 
     let mut final_res = 0f64;
     for ft in futures.mut_iter()  {
@@ -334,11 +339,11 @@ fn main() {
         let (port, chan)  = Chan::new();
         chan.send(numbers_arc.clone());
 
-        spawn(proc() {
+        do spawn {
             let local_arc : Arc<~[f64]> = port.recv();
             let task_numbers = local_arc.get();
             println!("{}-norm = {}", num, pnorm(task_numbers, num));
-        });
+        }
     }
 }
 ~~~
@@ -412,13 +417,13 @@ termination with an error).
 # use std::task;
 # fn some_condition() -> bool { false }
 # fn calculate_result() -> int { 0 }
-let result: Result<int, ()> = task::try(proc() {
+let result: Result<int, ()> = do task::try {
     if some_condition() {
         calculate_result()
     } else {
         fail!("oops!");
     }
-});
+};
 assert!(result.is_err());
 ~~~
 
@@ -497,9 +502,9 @@ Here is the code for the parent task:
 
 let (from_child, to_child) = DuplexStream::new();
 
-spawn(proc() {
+do spawn {
     stringifier(&to_child);
-});
+};
 
 from_child.send(22);
 assert!(from_child.recv() == ~"22");

branches/try2/doc/index.md

@@ -37,9 +37,7 @@ li {list-style-type: none; }
 * [The Rust parser, `libsyntax`](syntax/index.html)
 * [The Rust compiler, `librustc`](rustc/index.html)
 
-* [The `arena` allocation library](arena/index.html)
 * [The `flate` compression library](flate/index.html)
-* [The `glob` file path matching library](glob/index.html)
 
 # Tooling
 

branches/try2/doc/rust.md

@@ -2751,6 +2751,52 @@ 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}
@@ -2818,14 +2864,15 @@ match_pat : pat [ ".." pat ] ? [ "if" expr ] ;
 
 A `match` expression branches on a *pattern*. The exact form of matching that
 occurs depends on the pattern. Patterns consist of some combination of
-literals, destructured enum constructors, structures, records and tuples, variable binding
-specifications, wildcards (`..`), and placeholders (`_`). A `match` expression has a *head
-expression*, which is the value to compare to the patterns. The type of the
-patterns must equal the type of the head expression.
+literals, destructured vectors or enum constructors, structures, records and
+tuples, variable binding specifications, wildcards (`..`), and placeholders
+(`_`). A `match` expression has a *head expression*, which is the value to
+compare to the patterns. The type of the patterns must equal the type of the
+head expression.
 
-In a pattern whose head expression has an `enum` type, a placeholder (`_`) stands for a
-*single* data field, whereas a wildcard `..` stands for *all* the fields of a particular
-variant. For example:
+In a pattern whose head expression has an `enum` type, a placeholder (`_`)
+stands for a *single* data field, whereas a wildcard `..` stands for *all* the
+fields of a particular variant. For example:
 
 ~~~~
 enum List<X> { Nil, Cons(X, ~List<X>) }
@@ -2839,11 +2886,35 @@ match x {
 }
 ~~~~
 
-The first pattern matches lists constructed by applying `Cons` to any head value, and a
-tail value of `~Nil`. The second pattern matches _any_ list constructed with `Cons`,
-ignoring the values of its arguments. The difference between `_` and `..` is that the pattern
-`C(_)` is only type-correct if `C` has exactly one argument, while the pattern `C(..)` is
-type-correct for any enum variant `C`, regardless of how many arguments `C` has.
+The first pattern matches lists constructed by applying `Cons` to any head
+value, and a tail value of `~Nil`. The second pattern matches _any_ list
+constructed with `Cons`, ignoring the values of its arguments. The difference
+between `_` and `..` is that the pattern `C(_)` is only type-correct if `C` has
+exactly one argument, while the pattern `C(..)` is type-correct for any enum
+variant `C`, regardless of how many arguments `C` has.
+
+Used inside a vector pattern, `..` stands for any number of elements. This
+wildcard can be used at most once for a given vector, which implies that it
+cannot be used to specifically match elements that are at an unknown distance
+from both ends of a vector, like `[.., 42, ..]`. If followed by a variable name,
+it will bind the corresponding slice to the variable. Example:
+
+~~~~
+fn is_symmetric(list: &[uint]) -> bool {
+    match list {
+        [] | [_]                   => true,
+        [x, ..inside, y] if x == y => is_symmetric(inside),
+        _                          => false
+    }
+}
+
+fn main() {
+    let sym     = &[0, 1, 4, 2, 4, 1, 0];
+    let not_sym = &[0, 1, 7, 2, 4, 1, 0];
+    assert!(is_symmetric(sym));
+    assert!(!is_symmetric(not_sym));
+}
+~~~~
 
 A `match` behaves differently depending on whether or not the head expression
 is an [lvalue or an rvalue](#lvalues-rvalues-and-temporaries).
@@ -2926,7 +2997,7 @@ let z = match x { &0 => "zero", _ => "some" };
 assert_eq!(y, z);
 ~~~~
 
-A pattern that's just an identifier, like `Nil` in the previous answer,
+A pattern that's just an identifier, like `Nil` in the previous example,
 could either refer to an enum variant that's in scope, or bind a new variable.
 The compiler resolves this ambiguity by forbidding variable bindings that occur
 in `match` patterns from shadowing names of variants that are in scope.