Small corrections

chapters/1_introduction.tex

···
 
 \Cmls{} have been designed to tackle these issues.
 They serve as a level of abstraction between the modeller and the \solver{}.
+The typical process of a \cml{} is visualized in \cref{fig:intro-cml-flow}.
 Instead of providing a flat list of \variables{} and \constraints{}, a modeller creates a \cmodel{} using the more natural syntax of the \cml{}.
-A \cmodel{} can generally describe a class of problems through the use of \prbpars{}, values assigned by external input.
+A \cmodel{} can generally describe a class of problems through the use of \prbpars{}: values assigned by external input.
 Once given a complete \gls{assignment} of the \prbpars{}, the \cmodel{} forms an \instance{}.
-Central to the process of a \cml{}, the \instance{} is transformed, through \gls{rewriting}, into a \gls{slv-mod}, an encoding of the problem that can be used by the \solver{}.
-This process is visualized in \cref{fig:intro-cml-flow}.
+The \gls{rewriting} process of a \cml{} transforms a \cmodel{} into a \gls{slv-mod}: the encoding of the problem for the \solver{}.
 
 \begin{figure}
 	\centering
···
 \end{figure}
 
 Traditional \cmls{}, such as \glsxtrshort{ampl} \autocite{fourer-2003-ampl}, \gls{essence} \autocite{frisch-2007-essence}, and \glsxtrshort{opl} \autocite{van-hentenryck-1999-opl}, offer the modeller an expressive language that can be used to target a great variety of \solvers{}.
-However, these language lack a certain level of flexibility: the modeller is unable to capture common concepts used throughout a \cmodel{}; and the \solver{} cannot influence their way in which the problem is encoded.
+However, these language lack a certain level of flexibility: the modeller is unable to capture common concepts used throughout a \cmodel{}, and the \solver{} cannot influence their way in which the problem is encoded.
 
-This is a stark different to \gls{clp} languages, such Sictus Prolog \autocite{carlsson-1997-sicstus}, which are said to be the precursors to \cmls{}.
+This is a stark difference to \gls{clp} languages, such as Sictus Prolog \autocite{carlsson-1997-sicstus}, which are said to be the precursors to \cmls{}.
 In these languages, the modeller is encouraged to create high-level concepts and declare the way in which they are rewritten into \gls{native} \constraints{}.
 The downside of \gls{clp} languages is that, because of its search mechanism, the \solver{} is tightly integrated within the \gls{rewriting}.
 These languages thus lack the \solver{}-independence of \cmls{}.
 
 \minizinc{} \autocite{nethercote-2007-minizinc} is a functional \cml{} that operates on a level in between these two types of languages.
 Like a traditional \cml{}, it is a \solver{}-independent \cml{}.
-And like a \gls{clp} language, modellers can declare common concepts and control the encoding into the \gls{slv-mod} through the use of function definitions.
+Similarly, like a \gls{clp} language, modellers can declare common concepts and control the encoding into the \gls{slv-mod} through the use of function definitions.
 Fundamentally, in its \gls{rewriting} process \minizinc{} is a functional language.
 It continuously evaluates the calls in a \minizinc{} \instance{} until it reaches \gls{native} \constraints{}.
 Like other functional languages, \minizinc{} allows recursion; it can be used as a fully Turing complete programming language.
···
 
 \gls{clp}, as used for example in the Sictus Prolog language \autocite{carlsson-1997-sicstus}, offers a very different mechanism to create a \cmodel{}.
 In these languages, the modeller is encouraged to create high-level concepts and declare the way in which they are rewritten into \gls{native} \constraints{}.
-For example, the concepts of one task preceding another and non-overlapping of tasks could be defined in Prolog as:
+For example, the concepts of one task preceding another and non-overlapping of tasks could be defined in Prolog as follows.
 
 \begin{minted}[
   autogobble=true,