Merge pull request #1355 from asakaev/fix-typo

Fix typos

Author: SethTisue

_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.