Fix typos

_includes/footer.html

@@ -53,7 +53,7 @@
 <!-- Blog search -->
 <script src="{{ site.baseurl }}/resources/js/vendor/jekyll.search.min.js" type="text/javascript"></script>
 
-<!-- Custom javascript -->
+<!-- Custom JavaScript -->
 <script src="{{ site.baseurl }}/resources/js/functions.js" type="text/javascript"></script>
 
 {% if page.layout == "sips"%}

_overviews/FAQ/collections.md

@@ -167,7 +167,7 @@ The operation is meant to traverse all elements of the collection, and apply
 the given operation f to each element. The application is done for its side
 effect only; in fact any function result of f is discarded by foreach.
 
-Traversible objects can be finite or infinite. An example of an infinite
+Traversable objects can be finite or infinite. An example of an infinite
 traversable object is the stream of natural numbers `Stream.from(0)`. The
 method `hasDefiniteSize` indicates whether a collection is possibly infinite.
 If `hasDefiniteSize` returns true, the collection is certainly finite. If it
@@ -250,7 +250,7 @@ it. Also available are some traits with further refinements, such as
 	* `LinearSeq` -- A trait for linear sequences, with efficient time for `isEmpty`, `head` and `tail`.
 
 		* `immutable.LinearSeq`
-			* `immutable.List` -- An immutable, singlely-linked, list implementation.
+			* `immutable.List` -- An immutable, singly-linked, list implementation.
 			* `immutable.Stream` -- A lazy-list. Its elements are only computed on-demand, but memoized (kept in memory) afterwards. It can be theoretically infinite.
 		* `mutable.LinearSeq`
 			* `mutable.DoublyLinkedList` -- A list with mutable `prev`, `head` (`elem`) and `tail` (`next`).
@@ -343,7 +343,7 @@ it. Also available are some traits with further refinements, such as
 This was done to achieve maximum code reuse. The concrete *generic*
 implementation for classes with a certain structure (a traversable, a map, etc)
 is done in the Like classes. The classes intended for general consumption,
-then, override selected methods that can be optmized.
+then, override selected methods that can be optimized.
 
 * What the companion methods are for (e.g. List.companion)?
 

_overviews/FAQ/context-bounds.md

@@ -40,7 +40,7 @@ Another very common example in the library is a bit more complex:
 
     def f[A : Ordering](a: A, b: A) = implicitly[Ordering[A]].compare(a, b)
 
-Here, `implicitly` is used to retrive the implicit value we want, one of type
+Here, `implicitly` is used to retrieve the implicit value we want, one of type
 `Ordering[A]`, which class defines the method `compare(a: A, b: A): Int`.
 
 We'll see another way of doing this below.

_overviews/FAQ/finding-implicits.md

@@ -219,7 +219,7 @@ by a `t` that is not implicit, so no implicit `T` is in scope.
 
 The invocation of `f` was enabled by importing from `Y.X.`. But it is
 not convenient to require an import to access implicit values
-providied by a package.
+provided by a package.
 
 If an implicit value is not found in lexical scope, implicit search
 continues in implicit scope.

_overviews/FAQ/finding-symbols.md

@@ -160,7 +160,7 @@ object of type that is receiving the method. For example, consider `"a" -> 1`. W
 to look for an implicit which works on `"a"`, and so it can take `String`, one of its
 supertypes (`AnyRef` or `Any`) or a type parameter. In this case, we find
 `implicit final class ArrowAssoc[A](private val self: A)` which makes this implicit
-avaialable on all types.
+available on all types.
 
 Other implicit conversions may be visible in your scope depending on imports, extended types or
 self-type annotations. See [Finding implicits](finding-implicits.html) for details.

_overviews/collections/migrating-from-scala-27.md

@@ -41,7 +41,7 @@ Generally, the old functionality of Scala 2.7 collections has been left in place
 
 There are two parts of the old libraries which have been replaced wholesale, and for which deprecation warnings were not feasible.
 
-1. The previous `scala.collection.jcl` package is gone. This package tried to mimick some of the Java collection library design in Scala, but in doing so broke many symmetries. Most people who wanted Java collections bypassed `jcl` and used `java.util` directly. Scala 2.8 offers automatic conversion mechanisms between both collection libraries in the [JavaConversions]({{ site.baseurl }}/overviews/collections/conversions-between-java-and-scala-collections.html) object which replaces the `jcl` package.
+1. The previous `scala.collection.jcl` package is gone. This package tried to mimic some of the Java collection library design in Scala, but in doing so broke many symmetries. Most people who wanted Java collections bypassed `jcl` and used `java.util` directly. Scala 2.8 offers automatic conversion mechanisms between both collection libraries in the [JavaConversions]({{ site.baseurl }}/overviews/collections/conversions-between-java-and-scala-collections.html) object which replaces the `jcl` package.
 2. Projections have been generalized and cleaned up and are now available as views. It seems that projections were used rarely, so not much code should be affected by this change.
 
 So, if your code uses either `jcl` or projections there might be some minor rewriting to do.

_overviews/core/architecture-of-scala-collections.md

@@ -907,7 +907,7 @@ return with `None`. The combined selection over an option value `opt` is
 elegantly expressed using `opt.flatMap(x => f(x))`. When applied to an
 optional value that is `None`, it returns `None`. Otherwise `opt` is
 `Some(x)` and the function `f` is applied to the encapsulated value `x`,
-yielding a new option, which is returned by the flatmap.
+yielding a new option, which is returned by the flatMap.
 
 The next two methods to implement for a mutable map are `+=` and `-=`. In
 the implementation of `PrefixMap`, these are defined in terms of two
@@ -948,7 +948,7 @@ using the map's `+=` method. For immutable maps, the non-destructive
 element addition method `+` is used instead of method `+=`. Sets work
 in the same way.
 
-However, in all these cases, to build the right kind of colletion
+However, in all these cases, to build the right kind of collection
 you need to start with an empty collection of that kind. This is
 provided by the `empty` method, which is the last method defined in
 `PrefixMap`. This method simply returns a fresh `PrefixMap`.

_overviews/core/binary-compatibility-of-scala-releases.md

@@ -11,8 +11,8 @@ When two versions of Scala are binary compatible, it is safe to compile your pro
 
 We check binary compatibility automatically with [MiMa](https://github.com/lightbend/migration-manager). We strive to maintain a similar invariant for the `behavior` (as opposed to just linkage) of the standard library, but this is not checked mechanically (Scala is not a proof assistant so this is out of reach for its type system).
 
-#### Forwards and Back
-We distinguish forwards and backwards compatibility (think of these as properties of a sequence of versions, not of an individual version). Maintaining backwards compatibility means code compiled on an older version will link with code compiled with newer ones. Forwards compatibility allows you to compile on new versions and run on older ones.
+#### Forward and Back
+We distinguish forward and backward compatibility (think of these as properties of a sequence of versions, not of an individual version). Maintaining backwards compatibility means code compiled on an older version will link with code compiled with newer ones. Forward compatibility allows you to compile on new versions and run on older ones.
 
 Thus, backwards compatibility precludes the removal of (non-private) methods, as older versions could call them, not knowing they would be removed, whereas forwards compatibility disallows adding new (non-private) methods, because newer programs may come to depend on them, which would prevent them from running on older versions (private methods are exempted here as well, as their definition and call sites must be in the same compilation unit).
 

_overviews/core/collections-migration-213.md

@@ -29,7 +29,7 @@ The most important changes in the Scala 2.13 collections library are:
 
 The [scala-collection-compat](https://github.com/scala/scala-collection-compat) is a library released for 2.11, 2.12 and 2.13 that provides some of the new APIs from Scala 2.13 for the older versions. This simplifies cross-building projects.
 
-The module also provides [migratrion rules](https://github.com/scala/scala-collection-compat#migration-tool) for [scalafix](https://scalacenter.github.io/scalafix/docs/users/installation.html) that can update a project's source code to work with the 2.13 collections library.
+The module also provides [migration rules](https://github.com/scala/scala-collection-compat#migration-tool) for [scalafix](https://scalacenter.github.io/scalafix/docs/users/installation.html) that can update a project's source code to work with the 2.13 collections library.
 
 ## scala.Seq, varargs and scala.IndexedSeq migration
 

_overviews/core/futures.md

@@ -665,16 +665,16 @@ multiple `andThen` calls are ordered, as in the following example
 which stores the recent posts from a social network to a mutable set
 and then renders all the posts to the screen:
 
-	val allposts = mutable.Set[String]()
+	val allPosts = mutable.Set[String]()
 
 	Future {
 	  session.getRecentPosts
 	} andThen {
-	  case Success(posts) => allposts ++= posts
+	  case Success(posts) => allPosts ++= posts
 	} andThen {
 	  case _ =>
 	  clearAll()
-	  for (post <- allposts) render(post)
+	  for (post <- allPosts) render(post)
 	}
 
 In summary, the combinators on futures are purely functional.

_overviews/core/implicit-classes.md

@@ -72,8 +72,8 @@ Implicit classes have the following restrictions:
 
 
     implicit class RichDate(date: java.util.Date) // OK!
-    implicit class Indexer[T](collecton: Seq[T], index: Int) // BAD!
-    implicit class Indexer[T](collecton: Seq[T])(implicit index: Index) // OK!
+    implicit class Indexer[T](collection: Seq[T], index: Int) // BAD!
+    implicit class Indexer[T](collection: Seq[T])(implicit index: Index) // OK!
 
 
 While it's possible to create an implicit class with more than one non-implicit argument, such classes

_overviews/macros/blackbox-whitebox.md

@@ -29,7 +29,7 @@ In fact, macros became an important part of our ecosystem so quickly that just a
 Macro flavors are plentiful, so we decided to carefully examine them to figure out which ones should be put in the standard. This entails answering a few important questions. Why are macros working so well? Why do people use them?
 
 Our hypothesis is that this happens because the hard to comprehend notion of metaprogramming expressed in def macros piggybacks on the familiar concept of a typed method call. Thanks to that, the code that users write can absorb more meaning without becoming bloated or losing
-compehensibility.
+comprehensibility.
 
 ## Blackbox and whitebox macros
 

_overviews/macros/changelog211.md

@@ -60,7 +60,7 @@ Quasiquotes is the single most impressive upgrade for reflection and macros in S
 
 16) **[knownDirectSubclasses is deemed to be officially broken](https://issues.scala-lang.org/browse/SI-7046)**. A lot of users who tried to traverse sealed hierarchies of classes have noticed that `ClassSymbol.knownDirectSubclasses` only works if invocations of their macros come after the definitions of those hierarchies in Scala's compilation order. For instance, if a sealed hierarchy is defined in the bottom of a source file, and a macro application is written in the top of the file, then knownDirectSubclasses will return an empty list. This is an issue that is deeply rooted in Scala's internal architecture, and we can't provide a fix for it in the near future.
 
-17) **showCode**. Along with `Tree.toString` that prints Scala-ish source code and `showRaw(tree)` that prints internal structures of trees, we now have `showCode` that prints compileable Scala source code corresponding to the provided tree, courtesy of Vladimir Nikolaev, who's done an amazing work of bringing this to life. We plan to eventually replace `Tree.toString` with `showCode`, but in Scala 2.11.0 these are two different methods.
+17) **showCode**. Along with `Tree.toString` that prints Scala-ish source code and `showRaw(tree)` that prints internal structures of trees, we now have `showCode` that prints compilable Scala source code corresponding to the provided tree, courtesy of Vladimir Nikolaev, who's done an amazing work of bringing this to life. We plan to eventually replace `Tree.toString` with `showCode`, but in Scala 2.11.0 these are two different methods.
 
 18) **[It is now possible to typecheck in type and pattern modes](https://issues.scala-lang.org/browse/SI-6814)**. A very convenient `Context.typeCheck` and `ToolBox.typeCheck` functionality of Scala 2.10.x had a significant inconvenience - it only worked for expressions, and typechecking something as a type or as a pattern required building dummy expressions. Now `typeCheck` has the mode parameter that take case of that difficulty.
 
@@ -170,7 +170,7 @@ Quasiquotes is the single most impressive upgrade for reflection and macros in S
     // provides a source compatibility stub
     // in Scala 2.10.x, it will make `import compat._` compile just fine,
     // even though `c.universe` doesn't have `compat`
-    // in Scala 2.11.0, it will be ignored, becase `import c.universe._`
+    // in Scala 2.11.0, it will be ignored, because `import c.universe._`
     // brings its own `compat` in scope and that one takes precedence
     private object HasCompat { val compat = ??? }; import HasCompat._
 

_overviews/parallel-collections/architecture.md

@@ -37,7 +37,7 @@ terms of two core abstractions-- `Splitter`s and `Combiner`s.
 ### Splitters
 
 The job of a `Splitter`, as its name suggests, is to split a parallel
-collection into a non-trival partition of its elements. The basic idea is to
+collection into a non-trivial partition of its elements. The basic idea is to
 split the collection into smaller parts until they are small enough to be
 operated on sequentially.
 
@@ -55,7 +55,7 @@ subsets of elements of the whole parallel collection. And similar to normal
 `Iterator`s, a `Splitter` is invalidated after its `split` method is invoked.
 
 In general, collections are partitioned using `Splitter`s into subsets of
-roughly the same size. In cases where more arbitrarily-sized partions are
+roughly the same size. In cases where more arbitrarily-sized partitions are
 required, in particular on parallel sequences, a `PreciseSplitter` is used,
 which inherits `Splitter` and additionally implements a precise split method,
 `psplit`.
@@ -82,7 +82,7 @@ and the type of the resulting collection, respectively.
 
 _Note:_ Given two `Combiner`s, `c1` and `c2` where `c1 eq c2` is `true`
 (meaning they're the same `Combiner`), invoking `c1.combine(c2)` always does
-nothing and simpy returns the receiving `Combiner`, `c1`.
+nothing and simply returns the receiving `Combiner`, `c1`.
 
 ## Hierarchy
 

_overviews/quasiquotes/definition-details.md

@@ -216,7 +216,7 @@ Abstract type definitions have the following shape:
     low: universe.Tree = <empty>
     high: universe.Tree = List[T]
 
-Whenever one of the bounds isn\'t available, it gets represented as an [empty tree](expression-details.html#empty). Here each of the type arguments is a type definition itself.
+Whenever one of the bounds isn't available, it gets represented as an [empty tree](expression-details.html#empty). Here each of the type arguments is a type definition itself.
 
 Another form of type definition is a type alias:
 
@@ -259,7 +259,7 @@ Alternatively you can also deconstruct arguments, separating implicit and non-im
     implparams: List[universe.ValDef] = List(implicit val y: Int = _)
     body: universe.Tree = x.$plus(y)
 
-This way of handling parameters will still work if the method doesn\'t have any implicit parameters and `implparams` will get extracted as an empty list:
+This way of handling parameters will still work if the method doesn't have any implicit parameters and `implparams` will get extracted as an empty list:
 
     scala> val q"def g(...$paramss)(implicit ..$implparams) = $rhs" =
                q"def g(x: Int)(y: Int) = x + y"
@@ -344,15 +344,15 @@ Packages are a fundamental primitive to organize source code. You can express th
       }
     })
 
-Quasiquotes don\'t support the inline package definition syntax that is usually used in the header of the source file (but it's equivalent to the supported one in terms of ASTs).
+Quasiquotes don't support the inline package definition syntax that is usually used in the header of the source file (but it's equivalent to the supported one in terms of ASTs).
 
 ## Package Object Definition
 
 Package objects are a cross between packages and object:
 
     q"package object $tname extends { ..$earlydefns } with ..$parents { $self => ..$stats }"
 
-All of the handling properties are equivalent to those of objects apart from the fact that they don\'t have [modifiers](#modifiers).
+All of the handling properties are equivalent to those of objects apart from the fact that they don't have [modifiers](#modifiers).
 
 Even though package and regular objects seem to be quite similar syntactically, they don't match one another:
 

_overviews/quasiquotes/expression-details.md

@@ -290,7 +290,7 @@ At the moment, tuples are only supported up to an arity of 22, but this is just
     scala> val `tuple 23 supported?` = definitions.TupleClass(23) != NoSymbol
     tuple 23 supported?: Boolean = false
 
-Despited the fact that `Tuple1` class exists there is no built-in syntax for it. Single parens around expression do not change its meaning:
+Despite the fact that `Tuple1` class exists there is no built-in syntax for it. Single parens around expression do not change its meaning:
 
     scala> val inparens = q"(a)"
     inparens: universe.Ident = a

_overviews/quasiquotes/intro.md

@@ -73,7 +73,7 @@ Each of these contexts is covered by a separate interpolator:
  tq | [types]({{ site.baseurl }}/overviews/quasiquotes/syntax-summary.html#types)
  pq | [patterns]({{ site.baseurl }}/overviews/quasiquotes/syntax-summary.html#patterns)
 
-Syntactical similarity between different contexts doesn\'t imply similarity between underlying trees:
+Syntactical similarity between different contexts doesn't imply similarity between underlying trees:
 
     scala> println(q"List[Int]" equalsStructure tq"List[Int]")
     false
@@ -110,7 +110,7 @@ Unquote splicing is a way to unquote a variable number of elements:
     scala> val fab = q"f(..$ab)"
     fab: universe.Tree = f(a, b)
 
-Dots before the unquotee annotate indicate a degree of flattenning and are called a *splicing rank*. `..$` expects the argument to be an `Iterable[Tree]` and `...$` expects an `Iterable[Iterable[Tree]]`.
+Dots before the unquotee annotate indicate a degree of flattening and are called a *splicing rank*. `..$` expects the argument to be an `Iterable[Tree]` and `...$` expects an `Iterable[Iterable[Tree]]`.
 
 Splicing can easily be combined with regular unquotation:
 

_overviews/quasiquotes/terminology.md

@@ -19,6 +19,6 @@ permalink: /overviews/quasiquotes/:title.html
 * **Tree deconstruction** refers to usages of quasiquotes as patterns to structurally tear apart trees.
 * **Unquoting** is a way of either putting things in or extracting things out of quasiquotes. Can be performed with `$` syntax within a quasiquote.
 * **Unquote splicing** (or just splicing) is another form of unquoting that flattens contents of the unquotee into a tree. Can be performed with either `..$` or `...$` syntax.
-* **Rank** is a degree of flattenning of unquotee: `rank($) == 0`, `rank(..$) == 1`, `rank(...$) == 2`.
+* **Rank** is a degree of flattening of unquotee: `rank($) == 0`, `rank(..$) == 1`, `rank(...$) == 2`.
 * [**Lifting**](lifting.html) is a way to unquote non-tree values and transform them into trees with the help of the `Liftable` typeclass.
 * [**Unlifting**](unlifting.html) is a way to unquote non-tree values out of quasiquote patterns with the help of the `Unliftable` typeclass.

_overviews/quasiquotes/type-details.md

@@ -92,7 +92,7 @@ Lastly and [similarly to expressions](expression-details.html#super-and-this) on
 
 ## Applied Type
 
-Instantiations of parametized types can be expressed with the help of applied types (type-level equivalent of type application):
+Instantiations of parameterized types can be expressed with the help of applied types (type-level equivalent of type application):
 
     scala> val applied = tq"Foo[A, B]"
     applied: universe.Tree = Foo[A, B]
@@ -151,7 +151,7 @@ Existential types consist of a type tree and a list of definitions:
     tpt: universe.Tree = List[T]
     defns: List[universe.MemberDef] = List(type T)
 
-Alternatively there is also an underscrore notation:
+Alternatively there is also an underscore notation:
 
     scala> val tq"$tpt forSome { ..$defns }" = tq"List[_]"
     tpt: universe.Tree = List[_$1]