Update wording and fix typos

docs/_config.yml

@@ -8,7 +8,7 @@ baseurl: "/mps-coderules" # the subpath of your site, e.g. /blog
 url: "https://jetbrains.github.io" # the base hostname & protocol for your site, e.g. http://example.com
 twitter_username: jetbrains_mps
 github_username:  jetbrains
-time: 2018-09-04
+time: 2018-09-05
 revision: 0.5.0
 copyright: JetBrains s.r.o.
 copyright_url: "https://jetbrains.com"

docs/content/evaluating.md

@@ -42,7 +42,7 @@ For example, type **node** can be assigned to source model location with *set ty
 ![](img/eval-settype-650.png)  
 _(example showing type assigned from a production)_
 
-Failures may be encountered during constraints program execution, such as a unification failure, and they are caught with the help of alternative body branches, where those are provided. An uncaught failure terminates program execution and is reported to the user.
+Failures may be encountered during constraints program execution, such as a unification failure, and they are caught with the help of alternative body branches, when those are provided. An uncaught failure terminates program execution and is reported to the user.
 
 In the following example, a potential error is caught in the `else` branch and a corresponding errors is reported. Execution of constraints program is not terminated though, so other problems may still be reported.
 

docs/content/language.md

@@ -26,11 +26,13 @@ The following table contains root concepts that belong to code rules definition.
 
 ### Handler
 
-*Handler* serves two purposes: it declares the constraints that can be used in the *head* of productions in this handler and its extensions, and it  also declares *rules*, which are, simply put, procedures applicable to specific concept and (optionally) its subconcepts.
+*Handler* serves two purposes: it declares the *constraints* that it processes, and it  also declares *rules*, which are, simply put, procedures applicable to specific concept and (optionally) its subconcepts. 
+
+Constraints declared by a handler are public symbols that serve as its API in the following sense. In *head* of productions of a handler and its extensions only those constraints can be used, that were declared in this handler or any handler it extends. On the other hand, any constraints can be used in *body*, provided the references to constraint declarations are resolved in the usual way.
 
 #### Rules
 
-The aim of rules defined by handlers contribute constraint productions. These are created with a DSL that allows mixing of productions and Java code, and can also include constraint fragments inside a production template.
+The aim of rules defined by handlers is to contribute constraint productions. These are created with a DSL that allows mixing of productions and Java code, and can also include constraint fragments inside a production template.
 
 The following example is from the experimental *control flow* aspect for baseLanguage. It demonstrates how a production is constructed using a template. A template is enclosed into a pair of `%% … %%` symbols and yields constraints wrapped into special `<% … %>` brackets. In this particular case `write/2` constraint is optional and is only added to the body of production in case the condition is satisfied (a location corresponding to a local variable is written to only if it has an initialiser).
 
@@ -71,9 +73,9 @@ Constraint productions are discussed in details in the section on Constraint Pro
 
 A production template has three parts called *head*, *guard*, and *body*. Their meanings correspond precisely to those defined for the constraint productions. 
 
-There is a certain limitation as to what *constraints* can be used in head: it can only contain constraints defined by this handler, or one of the handlers it extends. This limitation has its origin in the way productions are chosen when  an active constraint is being processed. Namely, productions to match an active constraint are selected from the handler declaring this constraint, and handlers that are its extensions. The order of productions within the handler matters, the ones declared on top are matched first. Productions from extending handlers are prepended to the list of productions of the handler they extend.
+There is a certain limitation as to what *constraints* can be used in head: it can only contain constraints defined by this handler, or one of the handlers it extends. This limitation has its origin in the way productions are chosen when an active constraint is being processed. Namely, productions to match an active constraint are selected from the handler declaring this constraint, and handlers that are its extensions. The order of productions within the handler matters, the ones declared on top are matched first. Productions from extending handlers are prepended to the list of productions of the handler they extend.
 
-Production’s body can contain any visible constraints, as well as *predicates*. A production must include either the body or the head, no production can omit both. Guard is optional, and it can only contain predicates.
+Production’s body can contain any visible constraints declared by handlers located in imported models, as well as *predicates*. A production must include either a body or a head, no production can omit both. Guard is optional, and it can only contain predicates.
 
 A production with an empty head, not declaring any constraints to serve as its input, is considered an *automatic* production and is triggered automatically on start of constraints program execution.
 

docs/content/processing.md

@@ -143,7 +143,7 @@ Body is a conjunction of predicates and constraint activations. When triggered,
 
 The procedure `processActive()` accepts a constraint occurrence that has been activated and proceeds as follows until this constraint is either discarded or suspended (moved to store). This procedure calls itself recursively on every constraint activation, so there might be many active constraints at any given moment, organised into a stack, which matches exactly the call stack of `processActive()`. 
 
-First, the procedure searches for “relevant” productions that declare a constraint in their heads matching the active constraint occurrence currently being processed. These  productions form a FIFO queue, corresponding to the order of productions within a handler. 
+First, the procedure searches for “relevant” productions that declare a constraint in their heads matching the active constraint occurrence currently being processed. These productions form a FIFO queue, corresponding to the order of productions within a handler.
 
 For each “relevant” production, which at least partially matches the currently active constraint occurrence, the vacant slots in production’s head are filled with matching constraints from the store, which were previously suspended. Once a full match with production’s head is established, the guard is checked.