reorder Tour of Scala sections more logically

SethTisue · SethTisue · commit 9f0d591a4d47 · 2015-07-18T16:42:44.000-04:00
thanks to Stephen Compall for suggesting this; his original pull request (scala#307) couldn't be merged because too much time had passed, but I have followed his suggested ordering here
diff --git a/tutorials/tour/abstract-types.md b/tutorials/tour/abstract-types.md
@@ -5,11 +5,10 @@ title: Abstract Types
 disqus: true
 
 tutorial: scala-tour
-num: 2
-outof: 35
+num: 22
 languages: [es, ko]
-tutorial-next: annotations
-tutorial-previous: tour-of-scala
+tutorial-next: compound-types
+tutorial-previous: inner-classes
 ---
 
 In Scala, classes are parameterized with values (the constructor parameters) and with types (if classes are [generic](generic-classes.html)). For reasons of regularity, it is not only possible to have values as object members; types along with values are members of objects. Furthermore, both forms of members can be concrete and abstract.
diff --git a/tutorials/tour/annotations.md b/tutorials/tour/annotations.md
@@ -5,9 +5,9 @@ title: Annotations
 disqus: true
 
 tutorial: scala-tour
-num: 3
-tutorial-next: classes
-tutorial-previous: abstract-types
+num: 31
+tutorial-next: default-parameter-values
+tutorial-previous: automatic-closures
 ---
 
 Annotations associate meta-information with definitions.
diff --git a/tutorials/tour/anonymous-function-syntax.md b/tutorials/tour/anonymous-function-syntax.md
@@ -5,9 +5,9 @@ title: Anonymous Function Syntax
 disqus: true
 
 tutorial: scala-tour
-num: 14
-tutorial-next: currying
-tutorial-previous: nested-functions
+num: 6
+tutorial-next: higher-order-functions
+tutorial-previous: mixin-class-composition
 ---
 
 Scala provides a relatively lightweight syntax for defining anonymous functions. The following expression creates a successor function for integers:
diff --git a/tutorials/tour/automatic-closures.md b/tutorials/tour/automatic-closures.md
@@ -5,9 +5,9 @@ title: Automatic Type-Dependent Closure Construction
 disqus: true
 
 tutorial: scala-tour
-num: 16
-tutorial-next: operators
-tutorial-previous: currying
+num: 30
+tutorial-next: annotations
+tutorial-previous: operators
 ---
 
 Scala allows parameterless function names as parameters of methods. When such a method is called, the actual parameters for parameterless function names are not evaluated and a nullary function is passed instead which encapsulates the computation of the corresponding parameter (so-called *call-by-name* evalutation).
diff --git a/tutorials/tour/case-classes.md b/tutorials/tour/case-classes.md
@@ -5,9 +5,9 @@ title: Case Classes
 disqus: true
 
 tutorial: scala-tour
-num: 5
-tutorial-previous: classes
-tutorial-next: compound-types
+num: 10
+tutorial-next: pattern-matching
+tutorial-previous: currying
 ---
 
 Scala supports the notion of _case classes_. Case classes are regular classes which export their constructor parameters and which provide a recursive decomposition mechanism via [pattern matching](pattern-matching.html).
diff --git a/tutorials/tour/classes.md b/tutorials/tour/classes.md
@@ -5,9 +5,9 @@ title: Classes
 disqus: true
 
 tutorial: scala-tour
-num: 4
-tutorial-next: case-classes
-tutorial-previous: compound-types
+num: 3
+tutorial-next: traits
+tutorial-previous: unified-types
 ---
 
 Classes in Scala are static templates that can be instantiated into many objects at runtime.
diff --git a/tutorials/tour/compound-types.md b/tutorials/tour/compound-types.md
@@ -5,9 +5,9 @@ title: Compound Types
 disqus: true
 
 tutorial: scala-tour
-num: 6
-tutorial-next: sequence-comprehensions
-tutorial-previous: case-classes
+num: 23
+tutorial-next: explicitly-typed-self-references
+tutorial-previous: abstract-types
 ---
 
 Sometimes it is necessary to express that the type of an object is a subtype of several other types. In Scala this can be expressed with the help of *compound types*, which are intersections of object types.
diff --git a/tutorials/tour/currying.md b/tutorials/tour/currying.md
@@ -5,9 +5,9 @@ title: Currying
 disqus: true
 
 tutorial: scala-tour
-num: 15
-tutorial-next: automatic-closures
-tutorial-previous: anonymous-function-syntax
+num: 9
+tutorial-next: case-classes
+tutorial-previous: nested-functions
 ---
 
 Methods may define multiple parameter lists. When a method is called with a fewer number of parameter lists, then this will yield a function taking the missing parameter lists as its arguments.
diff --git a/tutorials/tour/default-parameter-values.md b/tutorials/tour/default-parameter-values.md
@@ -1,13 +1,13 @@
 ---
 layout: tutorial
-title: Default Parameter values
+title: Default Parameter Values
 
 disqus: true
 
 tutorial: scala-tour
-num: 34
+num: 32
 tutorial-next: named-parameters
-tutorial-previous: xml-processing
+tutorial-previous: annotations
 ---
 
 Scala provides the ability to give parameters default values that can be used to allow a caller to omit those parameters.
diff --git a/tutorials/tour/explicitly-typed-self-references.md b/tutorials/tour/explicitly-typed-self-references.md
@@ -5,9 +5,9 @@ title: Explicitly Typed Self References
 disqus: true
 
 tutorial: scala-tour
-num: 27
-tutorial-next: local-type-inference
-tutorial-previous: lower-type-bounds
+num: 24
+tutorial-next: implicit-parameters
+tutorial-previous: compound-types
 ---
 
 When developing extensible software it is sometimes handy to declare the type of the value `this` explicitly. To motivate this, we will derive a small extensible representation of a graph data structure in Scala.
diff --git a/tutorials/tour/extractor-objects.md b/tutorials/tour/extractor-objects.md
@@ -5,9 +5,9 @@ title: Extractor Objects
 disqus: true
 
 tutorial: scala-tour
-num: 8
-tutorial-next: generic-classes
-tutorial-previous: sequence-comprehensions
+num: 15
+tutorial-next: sequence-comprehensions
+tutorial-previous: regular-expression-patterns
 ---
 
 In Scala, patterns can be defined independently of case classes. To this end, a method named unapply is defined to yield a so-called extractor. For instance, the following code defines an extractor [object](singleton-objects.html) Twice.
diff --git a/tutorials/tour/generic-classes.md b/tutorials/tour/generic-classes.md
@@ -5,9 +5,9 @@ title: Generic Classes
 disqus: true
 
 tutorial: scala-tour
-num: 9
-tutorial-next: implicit-parameters
-tutorial-previous: extractor-classes
+num: 17
+tutorial-next: variances
+tutorial-previous: sequence-comprehensions
 ---
 
 Like in Java 5 (aka. [JDK 1.5](http://java.sun.com/j2se/1.5/)), Scala has built-in support for classes parameterized with types. Such generic classes are particularly useful for the development of collection classes.
diff --git a/tutorials/tour/higher-order-functions.md b/tutorials/tour/higher-order-functions.md
@@ -5,9 +5,9 @@ title: Higher-order Functions
 disqus: true
 
 tutorial: scala-tour
-num: 18
-tutorial-next: pattern-matching
-tutorial-previous: operators
+num: 7
+tutorial-next: nested-functions
+tutorial-previous: anonymous-function-syntax
 ---
 
 Scala allows the definition of higher-order functions. These are functions that _take other functions as parameters_, or whose _result is a function_. Here is a function `apply` which takes another function `f` and a value `v` and applies function `f` to `v`:
diff --git a/tutorials/tour/implicit-parameters.md b/tutorials/tour/implicit-parameters.md
@@ -5,9 +5,9 @@ title: Implicit Parameters
 disqus: true
 
 tutorial: scala-tour
-num: 10
-tutorial-previous: generic-classes
-tutorial-next: inner-classes
+num: 25
+tutorial-next: views
+tutorial-previous: explicitly-typed-self-references
 ---
 
 A method with _implicit parameters_ can be applied to arguments just like a normal method. In this case the implicit label has no effect. However, if such a method misses arguments for its implicit parameters, such arguments will be automatically provided.
diff --git a/tutorials/tour/inner-classes.md b/tutorials/tour/inner-classes.md
@@ -5,9 +5,9 @@ title: Inner Classes
 disqus: true
 
 tutorial: scala-tour
-num: 11
-tutorial-previous: implicit-parameters
-tutorial-next: mixin-class-composition
+num: 21
+tutorial-next: abstract-types
+tutorial-previous: lower-type-bounds
 ---
 
 In Scala it is possible to let classes have other classes as members. Opposed to Java-like languages where such inner classes are members of the enclosing class, in Scala such inner classes are bound to the outer object. To illustrate the difference, we quickly sketch the implementation of a graph datatype:
diff --git a/tutorials/tour/local-type-inference.md b/tutorials/tour/local-type-inference.md
@@ -5,9 +5,9 @@ title: Local Type Inference
 disqus: true
 
 tutorial: scala-tour
-num: 29
-tutorial-next: unified-types
-tutorial-previous: explicitly-typed-self-references
+num: 28
+tutorial-next: operators
+tutorial-previous: polymorphic-methods
 ---
 Scala has a built-in type inference mechanism which allows the programmer to omit certain type annotations. It is, for instance, often not necessary in Scala to specify the type of a variable, since the compiler can deduce the type from the initialization expression of the variable. Also return types of methods can often be omitted since they corresponds to the type of the body, which gets inferred by the compiler.
 
diff --git a/tutorials/tour/lower-type-bounds.md b/tutorials/tour/lower-type-bounds.md
@@ -5,7 +5,9 @@ title: Lower Type Bounds
 disqus: true
 
 tutorial: scala-tour
-num: 26
+num: 20
+tutorial-next: inner-classes
+tutorial-previous: upper-type-bounds
 ---
 
 While [upper type bounds](upper-type-bounds.html) limit a type to a subtype of another type, *lower type bounds* declare a type to be a supertype of another type. The term `T >: A` expresses that the type parameter `T` or the abstract type `T` refer to a supertype of type `A`.
diff --git a/tutorials/tour/mixin-class-composition.md b/tutorials/tour/mixin-class-composition.md
@@ -5,9 +5,9 @@ title: Mixin Class Composition
 disqus: true
 
 tutorial: scala-tour
-num: 12
-tutorial-next: nested-functions
-tutorial-previous: mixin-class-composition
+num: 5
+tutorial-next: anonymous-function-syntax
+tutorial-previous: traits
 ---
 
 As opposed to languages that only support _single inheritance_, Scala has a more general notion of class reuse. Scala makes it possible to reuse the _new member definitions of a class_ (i.e. the delta in relationship to the superclass) in the definition of a new class. This is expressed as a _mixin-class composition_. Consider the following abstraction for iterators.
diff --git a/tutorials/tour/named-parameters.md b/tutorials/tour/named-parameters.md
@@ -5,7 +5,7 @@ title: Named Parameters
 disqus: true
 
 tutorial: scala-tour
-num: 35
+num: 33
 tutorial-previous: default-parameter-values
 ---
 
diff --git a/tutorials/tour/nested-functions.md b/tutorials/tour/nested-functions.md
@@ -5,9 +5,9 @@ title: Nested Functions
 disqus: true
 
 tutorial: scala-tour
-num: 13
-tutorial-next: anonymous-function-syntax
-tutorial-previous: mixin-class-composition
+num: 8
+tutorial-next: currying
+tutorial-previous: higher-order-functions
 ---
 
 In Scala it is possible to nest function definitions. The following object provides a `filter` function for extracting values from a list of integers that are below a threshold value:
diff --git a/tutorials/tour/operators.md b/tutorials/tour/operators.md
@@ -5,9 +5,9 @@ title: Operators
 disqus: true
 
 tutorial: scala-tour
-num: 17
-tutorial-next: higher-order-functions
-tutorial-previous: automatic-closures
+num: 29
+tutorial-next: automatic-closures
+tutorial-previous: local-type-inference
 ---
 
 Any method which takes a single parameter can be used as an *infix operator* in Scala. Here is the definition of class `MyBool` which defines three methods `and`, `or`, and `negate`.
diff --git a/tutorials/tour/pattern-matching.md b/tutorials/tour/pattern-matching.md
@@ -5,10 +5,10 @@ title: Pattern Matching
 disqus: true
 
 tutorial: scala-tour
-num: 20
+num: 11
 
-tutorial-next: polymorphic-methods
-tutorial-previous: higher-order-functions
+tutorial-next: singleton-objects
+tutorial-previous: case-classes
 ---
 
 Scala has a built-in general pattern matching mechanism. It allows to match on any sort of data with a first-match policy. 
diff --git a/tutorials/tour/polymorphic-methods.md b/tutorials/tour/polymorphic-methods.md
@@ -5,10 +5,10 @@ title: Polymorphic Methods
 disqus: true
 
 tutorial: scala-tour
-num: 21
+num: 27
 
-tutorial-next: regular-expression-patterns
-tutorial-previous: polymorphic-methods
+tutorial-next: local-type-inference
+tutorial-previous: views
 ---
 
 Methods in Scala can be parameterized with both values and types. Like on the class level, value parameters are enclosed in a pair of parentheses, while type parameters are declared within a pair of brackets.
diff --git a/tutorials/tour/regular-expression-patterns.md b/tutorials/tour/regular-expression-patterns.md
@@ -5,10 +5,10 @@ title: Regular Expression Patterns
 disqus: true
 
 tutorial: scala-tour
-num: 22
+num: 14
 
-tutorial-next: traits
-tutorial-previous: polymorphic-methods
+tutorial-next: extractor-objects
+tutorial-previous: xml-processing
 ---
 
 ## Right-ignoring sequence patterns ##
diff --git a/tutorials/tour/sequence-comprehensions.md b/tutorials/tour/sequence-comprehensions.md
@@ -5,9 +5,9 @@ title: Sequence Comprehensions
 disqus: true
 
 tutorial: scala-tour
-num: 7
-tutorial-previous: compound-types
-tutorial-next: extractor-objects
+num: 16
+tutorial-next: generic-classes
+tutorial-previous: extractor-objects
 ---
 
 Scala offers a lightweight notation for expressing *sequence comprehensions*. Comprehensions have the form `for (enumerators) yield e`, where `enumerators` refers to a semicolon-separated list of enumerators. An *enumerator* is either a generator which introduces new variables, or it is a filter. A comprehension evaluates the body `e` for each binding generated by the enumerators and returns a sequence of these values.
diff --git a/tutorials/tour/singleton-objects.md b/tutorials/tour/singleton-objects.md
@@ -5,7 +5,10 @@ title: Singleton Objects
 disqus: true
 
 tutorial: scala-tour
-num: 28
+num: 12
+
+tutorial-next: xml-processing
+tutorial-previous: pattern-matching
 ---
 
 Methods and values that aren't associated with individual instances of a [class](classes.html) belong in *singleton objects*, denoted by using the keyword `object` instead of `class`.
diff --git a/tutorials/tour/tour-of-scala.md b/tutorials/tour/tour-of-scala.md
@@ -6,7 +6,8 @@ disqus: true
 
 tutorial: scala-tour
 num: 1
-tutorial-next: abstract-types
+outof: 33
+tutorial-next: unified-types
 ---
 
 Scala is a modern multi-paradigm programming language designed to express common programming patterns in a concise, elegant, and type-safe way. It smoothly integrates features of object-oriented and functional languages.
diff --git a/tutorials/tour/traits.md b/tutorials/tour/traits.md
@@ -5,9 +5,9 @@ title: Traits
 disqus: true
 
 tutorial: scala-tour
-num: 24
-tutorial-next: upper-type-bounds
-tutorial-previous: regular-expression-patterns
+num: 4
+tutorial-next: mixin-class-composition
+tutorial-previous: classes
 ---
 
 Similar to interfaces in Java, traits are used to define object types by specifying the signature of the supported methods. Unlike Java, Scala allows traits to be partially implemented; i.e. it is possible to define default implementations for some methods. In contrast to classes, traits may not have constructor parameters.
diff --git a/tutorials/tour/unified-types.md b/tutorials/tour/unified-types.md
@@ -5,9 +5,9 @@ title: Unified Types
 disqus: true
 
 tutorial: scala-tour
-num: 30
-tutorial-next: variances
-tutorial-previous: local-type-inference
+num: 2
+tutorial-next: classes
+tutorial-previous: tour-of-scala
 ---
 
 In contrast to Java, all values in Scala are objects (including numerical values and functions). Since Scala is class-based, all values are instances of a class. The diagram below illustrates the class hierarchy.
diff --git a/tutorials/tour/upper-type-bounds.md b/tutorials/tour/upper-type-bounds.md
@@ -5,9 +5,9 @@ title: Upper Type Bounds
 disqus: true
 
 tutorial: scala-tour
-num: 25
-tutorial-next: explicitly-typed-self-references
-tutorial-previous: traits
+num: 19
+tutorial-next: lower-type-bounds
+tutorial-previous: variances
 ---
 
 In Scala, [type parameters](generic-classes.html) and [abstract types](abstract-types.html) may be constrained by a type bound. Such type bounds limit the concrete values of the type variables and possibly reveal more information about the members of such types. An _upper type bound_ `T <: A` declares that type variable `T` refers to a subtype of type `A`.
diff --git a/tutorials/tour/variances.md b/tutorials/tour/variances.md
diff --git a/tutorials/tour/views.md b/tutorials/tour/views.md
diff --git a/tutorials/tour/xml-processing.md b/tutorials/tour/xml-processing.md
