grammar fix

Author: ivg

_posts/2019-08-15-knowledge-intro-1.md

@@ -12,7 +12,7 @@ This knowledge base is essentially a set of _objects_. Objects belong to _classe
 
 Object properties could be read or written. It is also possible to associate triggers with a property. Triggers are called _promises_ in our parlance. A promise is a function that will be called when a property of an object is accessed. The promises are stored procedures in our knowledge base and they act like the injection points for different plugins, e.g., a lifter is just a promise to provide the semantics property of an object of class `core-theory:program`. The promise itself can access any other properties of any other objects (which it can reach, of course), even including the property that it is providing (recursive case). Moreover, with each property, we can associate several promises (triggers). For example, we can have several lifters working at the same time. The knowledge system will take care of running and scheduling different promises and will compute the fixed point solution in linear time using stochastic fixed-point computation, and yadda, yadda. The point is that it will make it automatically and transparent to the user, and will guarantee the consistency of the result (e.g., that it doesn't depend on the order of evaluation of promises). It is also important to understand, that once a triggered property is computed it will be stored and never recomputed again<sup>1</sup>.
 
-Now let's look underneath the hood of the knowledge base to see what objects and classes do we have right now. If you will run `bap ./exe -dknowledge` you will find out that most of the objects that are currently stored in the base belong to the `core-theory:program` class. Later, we will add more classes, but to implement the `Bap.Std` interface this one was enough. So let's take a particular object as an example. The knowledge base is printed in the following format: `(<object> (<properties>))`. If an object has a symbolic identifier associated with it, then it will be printed, otherwise, a numeric identifier (basically a pointer) will be printed. The object class is not printed, but all objects are grouped by their class, with each new class opened with the `(in-class <class-name>)` statement. Also, note that all symbolic identifiers are properly namespaced, using the package system which is the same as in Common Lisp. All identifiers which are not belonging to the current package, denoted with the `(in-package <pkg>)` statement, are printed as `<package>:<name>`).
+Now let's look underneath the hood of the knowledge base to see what objects and classes do we have right now. If you will run `bap ./exe -dknowledge` you will find out that most of the objects that are currently stored in the base belong to the `core-theory:program` class. Later, we will add more classes, but to implement the `Bap.Std` interface this one was enough. So let's take a particular object as an example. The knowledge base is printed in the following format: `(<object> (<properties>))`. If an object has a symbolic identifier associated with it, then it will be printed, otherwise, a numeric identifier (basically a pointer) will be printed. The object class is not printed, but all objects are grouped by their class, with each new class opened with the `(in-class <class-name>)` statement. Also, note that all symbolic identifiers are properly namespaced, using the package system which is the same as in Common Lisp. All identifiers which do not belong to the current package, denoted with the `(in-package <pkg>)` statement, are printed as `<package>:<name>`).
 
 Now, we are ready to read the output of `-dknowledge`. In the following output, we have an object, that belongs to the `core-theory:program` class, which has a printed representation `core-theory:0x402fd0`. The printed representation looks very much like a number, and you may notice that it is indeed equal to the address of an instruction which this object denotes.