Fix more typos

Author: odersky

docs/docs/reference/overview.md

@@ -23,16 +23,15 @@ The primary goal of the language constructs in this section is to make the langu
 
  - [Intersection types](http://dotty.epfl.ch/docs/reference/intersection-types.html) `A & B`
 
-   Replaces compound type `A with B` (the old syntax is kept for the moment but will
+   They replace compounds type `A with B` (the old syntax is kept for the moment but will
    be deprecated in the future). Intersection types are one of the core features of DOT. They
    are commutative: `A & B` and `B & A` represent the same type.
 
- - [Implicit function types(http://dotty.epfl.ch/docs/reference/implicit-function-types.html) `implicit A => B`.
+ - [Implicit function types](http://dotty.epfl.ch/docs/reference/implicit-function-types.html) `implicit A => B`.
 
    Methods and lambdas can have implicit parameters, so it's natural to extend the
    same property to function types. Implicit function types help ergonomics and performance
-   as well. They can replace many uses of monads at an order of magnitude improvement
-   in runtime speed, and with far better composability.
+   as well. They can replace many uses of monads, offering better composability and an order of magnitude improvement in runtime speed.
 
  - [Dependent function types](http://dotty.epfl.ch/docs/reference/dependent-function-types.html) `(x: T) => x.S`.
 
@@ -41,14 +40,13 @@ The primary goal of the language constructs in this section is to make the langu
 
  - [Trait parameters](http://dotty.epfl.ch/docs/reference/trait-parameters.html) `trait T(x: S)`
 
-   Trait can now have value parameters, just like classes do. This replaces the cumbersome
-   [early initializer](http://dotty.epfl.ch/docs/reference/dropped/early-initializers.html) syntax.
+   Traits can now have value parameters, just like classes do. This replaces the more complex [early initializer](http://dotty.epfl.ch/docs/reference/dropped/early-initializers.html) syntax.
 
  - [Type lambdas](http://dotty.epfl.ch/docs/reference/type-lambdas.html) `[X] => C[X]`
 
-   Type lambdas were encoded previously in an extremely roundabout way, exploiting
-   loopholes in Scala's type system which made it Turing complete and unsound. With
-   the removal of unrestricted type projection the loopholes are eliminated, so the
+   Type lambdas were encoded previously in a roundabout way, exploiting
+   loopholes in Scala's type system which made it Turing complete. With
+   the removal of [unrestricted type projection](dropped/type-projection.html), the loopholes are eliminated, so the
    previous encodings are no longer expressible. Type lambdas in the language provide
    a safe and more ergonomic alternative.
 
@@ -67,8 +65,8 @@ Listed in this section are new language constructs that help precise, typechecke
 
  - [Multiversal Equality](http://dotty.epfl.ch/docs/reference/multiversal-equality.html)
 
-   Multiversal equality is an opt in way to check that comparisons using `==` and
-   `!=` only apply to compatible types. It thus closes the biggest remaining hurdle
+   Multiversal equality is an opt-in way to check that comparisons using `==` and
+   `!=` only apply to compatible types. It thus removes the biggest remaining hurdle
    to type-based refactoring. Normally, one would wish that one could change the type
    of some value or operation in a large code base, fix all type errors, and obtain
    at the end a working program. But universal equality `==` works for all types.
@@ -90,8 +88,8 @@ Listed in this section are new language constructs that help precise, typechecke
    are not tracked. We want to put in the hooks to allow to change this over time. The idea
    is to treat effects as capabilities represented as implicit parameters. Some effect types
    will be defined by the language, others can be added by libraries. Initially, the language
-   will likely only cover exceptions as effect capabilities, but it can be extended later
-   to mutations and possibly other effects. To ensure backwards compatibility, all effect
+   will likely only cover exceptions as effect capabilities, but this can be extended later
+   to mutations and other effects. To ensure backwards compatibility, all effect
    capabilities are initially available in `Predef`. Un-importing effect capabilities from
    `Predef` will enable stricter effect checking, and provide stronger guarantees of purity.
 
@@ -103,9 +101,8 @@ The primary goal of the language constructs in this section is to make common pr
  - [Enums](http://dotty.epfl.ch/docs/reference/enums/enums.html) `enum Color { case Red, Green, Blue }`
 
    Enums give a simple way to express a type with a finite set of named values. They
-   are found in most languages. The previous encodings of enums in Scala were all had
-   problems that prevented universal adoption. The new native `enum` construct in Scala
-   is quite flexible; among others it gives a more concise way to write [algebraic data types](http://dotty.epfl.ch/docs/reference/enums/adts.html),
+   are found in most languages. The previous encodings of enums as library-defined types
+   were not fully satisfactory and consequently were used widely. The new native `enum` construct in Scala is quite flexible; among others it gives a more concise way to write [algebraic data types](http://dotty.epfl.ch/docs/reference/enums/adts.html),
    which would otherwise be expressed by a sealed base trait with case classes as alternatives.
    Scala enums will interoperate with  the host platform. They support multiversal equality
    out of the box, i.e. an enum can only be compared to values of the same enum type.
@@ -133,6 +130,5 @@ The primary goal of the language constructs in this section is to enable high-le
    Parameters of methods and functions can be declared `erased`. This means that
    the corresponding arguments are only used for type checking purposes and no code
    will be generated for them. Typical candidates for erased parameters are type
-   constraints impressed through implicits such as `=:=` and `<:<`. Erased parameters
-   help both runtime (since no argument has to be constructed) and compile time
-   (since potentially large arguments can be eliminated early).
+   constraints such as `=:=` and `<:<` that are expressed through implicits.
+   Erased parameters improve both run times (since no argument has to be constructed) and compile times (since potentially large arguments can be eliminated early).