Address review comments

Author: odersky

docs/docs/reference/contextual/inferable-params.md

@@ -3,7 +3,7 @@ layout: doc-page
 title: "Inferable Parameters"
 ---
 
-Functional programming tends to express most dependencies as simple functions parameterization.
+Functional programming tends to express most dependencies as simple function parameterization.
 This is clean and powerful, but it sometimes leads to functions that take many parameters and
 call trees where the same value is passed over and over again in long call chains to many
 functions. Inferable parameters can help here since they enable the compiler to synthesize

docs/docs/reference/contextual/instance-defs.md

@@ -30,9 +30,9 @@ implied ListOrd[T] given (ord: Ord[T]) for Ord[List[T]] {
 }
 ```
 This code defines a trait `Ord` and two implied instance definitions. `IntOrd` defines
-an implied instance for the type `Ord[Int]` whereas `ListOrd` defines implied
-instances of `Ord[List[T]]` for all types `T` that come with an implied `Ord` instance themselves.
-The `given` clause in `ListOrd`  defines an [inferable parameter](./inferable-params.html).
+an implied instance for the type `Ord[Int]` whereas `ListOrd[T]` defines implied
+instances of `Ord[List[T]]` for all types `T` that come with an implied `Ord[T]` instance themselves.
+The `given` clause in `ListOrd` defines an [inferable parameter](./inferable-params.html).
 Inferable parameters are further explained in the next section.
 
 ## Anonymous Implied Instances
@@ -48,13 +48,11 @@ the type(s) in the `for` clause.
 
 ## Implied Alias Instances
 
-An implied alias instance defines an implied instance that is equal to some expression. E.g.,
+An implied alias instance defines an implied instance that is equal to some expression. E.g., assuming a global method `currentThreadPool` returning a value with a member `context`, one could define:
 ```scala
 implied ctx for ExecutionContext = currentThreadPool().context
 ```
-Here, we create an implied instance `ctx` of type `ExecutionContext` that resolves to the
-right hand side `currentThreadPool().context`. Each time an implied instance of `ExecutionContext`
-is demanded, the result of evaluating the right-hand side expression is returned.
+This creates an implied instance `ctx` of type `ExecutionContext` that resolves to the right hand side `currentThreadPool().context`. Each time an implied instance of `ExecutionContext` is demanded, the result of evaluating the right-hand side expression is returned.
 
 Alias instances may be anonymous, e.g.
 ```scala

docs/docs/reference/contextual/query-types-spec.md

@@ -42,11 +42,11 @@ the inferable parameters `xi`.
 
 The query literal is evaluated as the instance creation
 expression:
-
-    new scala.ImplicitFunctionN[T1, ..., Tn, T] {
-      def apply given (x1: T1, ..., xn: Tn): T = e
-    }
-
+```scala
+new scala.ImplicitFunctionN[T1, ..., Tn, T] {
+  def apply given (x1: T1, ..., xn: Tn): T = e
+}
+```
 In the case of a single untyped parameter, `given (x) => e` can be
 abbreviated to `given x => e`.
 

docs/docs/reference/contextual/query-types.md

@@ -112,7 +112,7 @@ With that setup, the table construction code above compiles and expands to:
 ```
 ### Example: Postconditions
 
-As a larger example, here is a way to define constructs for checking arbitrary postconditions using `ensuring` so that the checked result can be referred to simply by `result`. The example combines opaque aliases, context query types, and extension methods to provide a zero-overhead abstraction.
+As a larger example, here is a way to define constructs for checking arbitrary postconditions using an extension method `ensuring`so that the checked result can be referred to simply by `result`. The example combines opaque aliases, context query types, and extension methods to provide a zero-overhead abstraction.
 
 ```scala
 object PostConditions {

docs/docs/reference/contextual/relationship-implicits.md

@@ -82,7 +82,8 @@ The `infer` method corresponds to `implicitly` in Scala 2.
 Context bounds are the same in both language versions. They expand to the respective forms of implicit parameters.
 
 **Note:** To ease migration, context bounds in Dotty map for a limited time to old-style implicit parameters for which arguments can be passed either with `given` or
-with a normal application.
+with a normal application. Once old-style implicits are deprecated, context bounds
+will map to inferable parameters instead.
 
 ### Extension Methods