changedDefinitionPlacement

book/src/pages/expressions/04-types.md

@@ -10,7 +10,13 @@ A type of `Int` means if the expression is successfully evaluated, then the valu
 
 We determine the type of an expression without running it. This means that *types are a property of expressions*. We can give a type to an expression even if, when we evaluate it, the computation fails. This is also why the type doesn't tell us the specific value the expression evaluates to: we'd have to evaluate the expression to know that.
 
-Types are worked out in a process known as a *type-checking*, which is part of *compilation*. Before a Scala program is run, it must be *compiled*. Compilation checks that a program makes sense. It must be syntactically correct, meaning it must be written according to the rules of Scala. For example `(1 + 2)` is syntactically correct, but `(1 + 2` is not because there is no `)` to match the `(`. It must also *type check*, meaning the types must be correct for the operations we're trying to do. `1 + 2` type checks (we are adding integers), but `1.toUpperCase` does not (there is no concept of upper and lower case for integers.)
+Types are worked out in a process known as a *type-checking*, which is part of *compilation*. Before a Scala program is run, it must be *compiled*. Compilation checks that a program makes sense. It must be syntactically correct, meaning it must be written according to the rules of Scala. For example `(1 + 2)` is syntactically correct, but `(1 + 2` is not because there is no `)` to match the `(`. 
+Here, "syntax" is the term we use for the rules defining the structure of symbols in a programming language. 
+In English, we are taught that a sentence can be constructed using the rule: subject + verb + object e.g. "the artist paints a cat".
+A programming language might have a different set of rules and symbols to read `Artist.paint(cat);`. 
+This is a general example—languages have syntax variations—and it is worth noting that the English sentence is purely descriptive while the general code example is instructing the computer to paint a cat using 'Artist', which could be a library or object. 
+
+It must also *type check*, meaning the types must be correct for the operations we're trying to do. `1 + 2` type checks (we are adding integers), but `1.toUpperCase` does not (there is no concept of upper and lower case for integers.)
 
 Only programs that successfully compile can be run. We can think of compilation as being analogous to the rules of grammar in writing. The sentence "FaRf  fjrmn;l df.fd" is syntactically incorrect in English. The arrangement of letters doesn't form any words. The sentence "dog flying a here no" is made out of valid words but their arrangement breaks the rules of grammar, which is analogous to the type checks that Scala performs.
 

book/src/pages/foreword-1.md

@@ -19,11 +19,8 @@ Since we're assuming you have little programming experience we won't go into the
 Suffice to say there are different ways to think about and write computer programs, and we've chosen the functional programming approach.
 
 The reasons for choosing functional programming are more interesting.
-It's common to teach programming by what we call the "bag of syntax" approach, where "syntax" is the term we use for the rules defining the structure of symbols in a programming language. 
-In English, we are taught that a sentence can be constructed using the rule: subject + verb + object e.g. "the artist paints a cat".
-A programming language might have a different set of rules and symbols to read `Artist.paint(cat);`. 
-This is a general example - languages have syntax variations, and it is worth noting that the English sentence is purely descriptive while the general code example is instructing the computer to paint a cat using 'Artist', which could be a library or object. 
-In the "bag of syntax" approach a programming language is taught a collection of syntactical features (variables, for loops, while loops, methods) and students are left to figure out on their own when to use each feature.
+It's common to teach programming by what we call the "bag of syntax" approach.
+In this approach a programming language is taught a collection of syntactical features (variables, for loops, while loops, methods) and students are left to figure out on their own when to use each feature.
 We've seen this method fail both when we were undergraduates learning programming, and as postgraduates teaching programming, as students simply have no systematic way to break down a problem and turn it into code.
 The result is that many students dropped out due to the poor quality of teaching.
 The students that remained tended to, like us, already have extensive programming experience.