Minor corrections to spec-docs

spec-docs/NameResolution.adoc

@@ -197,7 +197,7 @@ Note that only an extension receiver (`String` in this example) may be explicit.
 The reference to `Builder` will always be an implicit receiver.
 ====
 
-For now we suppose that `foo` in the call `a.foo()` is a regular function, not a variable of a function type.
+For now, we suppose that `foo` in the call `a.foo()` is a regular function and not a variable of a function type.
 The latter case will be covered in the section "Name resolution for the `invoke` convention".
 
 Several `foo` functions might be available in the context: members, extensions and member extensions.
@@ -224,7 +224,7 @@ Even though the extension function is more precise for the call (it takes `Strin
 If it was, it would be too easy to break existing code without noticing that by adding an extension.
 
 You see now that members go before extensions, but what about member extensions?
-They have higher priority compared to top-level extensions, but lower then local extensions.
+They have higher priority compared to top-level extensions, but lower than local extensions.
 Below we'll cover the details.
 
 [NOTE]
@@ -710,7 +710,7 @@ fun test(a: A, b: B, c: C) {
 In this example `foo` is declared as an extension property to `B` that has type `C.() -> Unit`.
 Its getter returns a lambda with receiver.
 Inside this lambda we can access its receiver of type `C` simply by `this`.
-Also we can access property's receiver of type `B` by specifying a label `this@foo` and the instance of outer class by writing `this@A`.
+Also, we can access property's receiver of type `B` by specifying a label `this@foo` and the instance of outer class by writing `this@A`.
 
 While resolving the call `foo` the compiler has to ensure that all necessary receivers are available: `A` and `B` to resolve a property `foo`, and `C` to call the hidden invoke function.
 ====
@@ -785,7 +785,7 @@ Step 1.
 
 The most specific candidate is found for the group consisting of both members and syntactic members.
 If such candidate exists, it's the result.
-Otherwise the result is determined in the step 2.
+Otherwise, the result is determined in the step 2.
 
 Step 2.
 `members -> most specific`
@@ -796,7 +796,7 @@ If no appropriate member is found, the name resolution algorithm proceeds as des
 (tries to find the appropriate function among local extensions, member extensions, etc.).
 
 Now we can see how this process works for `J` and `J1` classes defined above.
-For `j.foo()` call the first step returns the result, because the syntactic member for `foo` is chosen as the the most specific candidate.
+For `j.foo()` call the first step returns the result, because the syntactic member for `foo` is chosen as the most specific candidate.
 However, for `j1.foo()` the first step finishes with ambiguity, because two `foo` methods (1-syntactic and 2-declared explicitly) have the same signature.
 Then the second step produces the result, which is the foo-2 method, because only declared methods are considered.
 

spec-docs/annotation-arguments.md

@@ -51,7 +51,7 @@ Also, we now load all array arguments as varargs, which may break for the same r
 
 ## Loading Java Annotations
 
-Fictitious constructors for Java annotations sould be built as follows:
+Fictitious constructors for Java annotations could be built as follows:
 * if there is an element named `value`, it is put first on the parameter list
 * if all other elements have default values, and `value` has an array type, it is marked `vararg` and has the type of the elements of the array
 * parameters corresponding to all elements but `value` can not be used positionally, only named arguments are allowed for them (this requires adding a platform-specific check to `frontend.java`)

spec-docs/enums.md

@@ -35,7 +35,7 @@ enum class Foo(val s: String) {
 Issues
 * Enum literals syntax clash with annotation syntax
     * Option 1.1: Forbid short annotation syntax in enums. **downside**: cannot annotate functions/properties/classes in this enum
-    * Option 1.2: Add a separator between enum constants and members, and forbid short annotation syntax only on enum entriesc themselves. **downside**: separator is not intuitive, hard to think of when doing this for the first time (the error message will be rather clear and instructive, though)
+    * Option 1.2: Add a separator between enum constants and members, and forbid short annotation syntax only on enum entries themselves. **downside**: separator is not intuitive, hard to think of when doing this for the first time (the error message will be rather clear and instructive, though)
     * Option 1.3: prefix each entry with a soft-keyword, e.g. `entry`. **downside**: verbosity
     * Option 1.4 **chosen**: Add a semicolon separator after the last enum constant, **and** a comma separator between different enum constants.
 * How do we specify other supertypes for a constant (if any)

spec-docs/function-types.md

@@ -5,7 +5,7 @@
 * Get rid of 23 hardwired physical function classes. One of the problems with them is that they should be effectively duplicated in reflection which means a lot of physical classes in kotlin-runtime.jar.
 * Make extension functions assignable to normal functions (and vice versa), so that it's possible to do `listOfStrings.map(String::length)`
 * Allow functions with more than 23 parameters, theoretically any number of parameters (in practice 255 on JVM).
-* At the same time, allow to implement Kotlin functions easily from Java: `new Function2() { ... }` and overriding `invoke` only would be the best.
+* At the same time, allow implementing Kotlin functions easily from Java: `new Function2() { ... }` and overriding `invoke` only would be the best.
 Enabling SAM conversions on Java 8 would also be terrific.
 
 ## Brief solution overview
@@ -75,7 +75,7 @@ interface Function<out R>
 ```
 
 It's a physical interface, declared in platform-agnostic built-ins, and present in `kotlin-runtime.jar` for example.
-However its declaration is **empty** and should be empty because every physical JVM function class `Function0`, `Function1`, ...
+However, its declaration is **empty** and should be empty because every physical JVM function class `Function0`, `Function1`, ...
 inherits from it (and adds `invoke()`), and we don't want to override anything besides `invoke()` when doing it from Java code.
 
 ## Functions with 0..22 parameters at runtime

spec-docs/secondary-constructors.md

@@ -53,7 +53,7 @@ class Foo : Bar() { // Error
 
 When a primary constructor is present, explicit constructors are called *secondary*.
 
-Every class **must** have a constructor. the following is an error:
+Every class **must** have a constructor. The following is an error:
 ``` kotlin
 class Parent
 class Child : Parent { }
@@ -77,7 +77,7 @@ Passing lambdas outside parentheses is not allowed in `constructorDelegationCall
 ## Rules for delegating calls
 
 The only situation when an explicit constructor may not have an explicit delegating call is
-- when there's no primary constructor **and** teh superclass has a constructor that can be called with no parameters passed to it
+- when there's no primary constructor **and** the superclass has a constructor that can be called with no parameters passed to it
 
 ``` kotlin
 class Parent {}
@@ -98,9 +98,9 @@ class Child(): Parent() {
 ## Initialization code outside constructors
 
 The primary constructor's body consists of
-- super class intialization from class header
+- super class initialization from class header
 - assignments to properties from constructor parameters declared with `val` or `var`
-- property initializers and bodies of anonymous initializers following in the order of appearence in the class body
+- property initializers and bodies of anonymous initializers following in the order of appearance in the class body
 
 If the primary constructor is not present, property initializers and anonymous initializers are conceptually "prepended" to the body 
 of each explicit constructor that has a delegating call to super class, and their contents are checked accordingly for definite