Address comments

Author: nicolasstucki

docs/docs/reference/auto-parameter-tupling-spec.md

@@ -18,7 +18,7 @@ xs.map {
   case (x, y) => x + y
 }
 ```
-While correct, this is also inconvenient. Instead, automatic tupling of function parameters proposed to be able to write it the following way:
+While correct, this is inconvenient. Instead, we propose to be able to write it the following way:
 
 ```scala
 xs.map {
@@ -30,21 +30,20 @@ or, equivalently:
 xs.map(_ + _)
 ```
 
-Generally, a function value with `n > 1` parameters can be converted to a pattern-matching closure using case if the expected type is a unary function type of the form `((T_1, ..., T_n)) => U`.
+Generally, a function value with `n > 1` parameters can be converted to a function with tupled arguments if the expected type is a unary function type of the form `((T_1, ..., T_n)) => U`.
 
 ### Type Checking
 
-Let a function `F` of the form `F = (p1, ..., pn) => E` for `n != 1`, parameters `p1, ..., pn`, and an expression `E`.
+Let a function `f` of the form `(p1, ..., pn) => e` for `n != 1`, parameters `p1, ..., pn`, and an expression `e`.
 
-
-If the expected type of `F` is a fully defined function type or SAM-type that has a
+If the expected type of `f` is a fully defined function type or SAM-type that has a
 single parameter of a subtype of `ProductN[T1, ..., Tn]`, where each type `Ti` fits the corresponding
 parameter `pi`.
 
-A type `T` fits a parameter `p` if one of the following two cases is `true`:
+A type `Ti` fits a parameter `pi` if one of the following two cases is `true`:
 
-* `p` comes without a type, i.e. it is a simple identifier or `_`.
-* `p` is of the form `x: U` or `_: U` and `T` conforms to `U`.
+* `pi` comes without a type, i.e. it is a simple identifier or `_`.
+* `pi` is of the form `x: Ui` or `_: Ui` and `Ti` conforms to `Ui`.
 
 Auto-tupling composes with eta-expansion. That is an n-ary function generated by eta-expansion
 can in turn be adapted to the expected type with auto-tupling.
@@ -53,7 +52,7 @@ can in turn be adapted to the expected type with auto-tupling.
 
 If the a function 
 ```scala
-(p1: T1, ..., pn: Tn) => E
+(p1: T1, ..., pn: Tn) => e
 ```
 
 is typed as `ProductN[T1, ..., Tn] => Te`, then it will be transformed to
@@ -63,7 +62,7 @@ is typed as `ProductN[T1, ..., Tn] => Te`, then it will be transformed to
    def p1: T1 = x._1
    ...
    def pn: Tn = x._n
-   E
+   e
 }
 ```
 
@@ -74,9 +73,9 @@ Translation of such a tuples would use the `apply` method on the tuple to access
 
 ### Migration
 
-Code like this could not be written before, hence the new notation would not be ambigouous after addoptation.
+Code like this could not be written before, hence the new notation would not be ambigouous after adoption.
 
-Thought it is possible that someone has written an implicit conversion for `(T1, ..., Tn) => R` into `TupleN[T1, ..., Tn]` 
+Though it is possible that someone has written an implicit conversion form `(T1, ..., Tn) => R` to `TupleN[T1, ..., Tn] => R`
 for some `n`. This change could be detected and fixed by `Scalafix`. Furthermore, such conversion would probably 
 be doing the same translation (semantically) but in a less efficient way.