Use explicit —s.

- Addresses aosabook#203.

blockcode/blockcode.markdown

@@ -5,7 +5,7 @@ _[Dethe](https://twitter.com/dethe) is a geek dad, aesthetic programmer, mentor,
 </markdown>
 In block-based programming languages, you write programs by dragging and connecting blocks that represent parts of the program. Block-based languages differ from conventional programming languages, in which you type words and symbols.
 
-Learning a programming language can be difficult because they are extremely sensitive to even the slightest of typos. Most programming languages are case-sensitive, have obscure syntax, and will refuse to run if you get so much as a semicolon in the wrong place --- or worse, leave one out. Further, most programming languages in use today are based on English and their syntax cannot be localized.
+Learning a programming language can be difficult because they are extremely sensitive to even the slightest of typos. Most programming languages are case-sensitive, have obscure syntax, and will refuse to run if you get so much as a semicolon in the wrong place&mdash;or worse, leave one out. Further, most programming languages in use today are based on English and their syntax cannot be localized.
 
 In contrast, a well-done block language can eliminate syntax errors completely. You can still create a program which does the wrong thing, but you cannot create one with the wrong syntax: the blocks just won't fit that way. Block languages are more discoverable: you can see all the constructs and libraries of the language right in the list of blocks. Further, blocks can be localized into any human language without changing the meaning of the programming language.
 
@@ -49,7 +49,7 @@ I've tried to follow some conventions and best practices throughout this project
 
 The code style is procedural, not object-oriented or functional. We could do the same things in any of these paradigms, but that would require more setup code and wrappers to impose on what exists already for the DOM. Recent work on [Custom Elements](http://webcomponents.org/) make it easier to work with the DOM in an OO way, and there has been a lot of great writing on [Functional JavaScript](https://leanpub.com/javascript-allonge/read), but either would require a bit of shoe-horning, so it felt simpler to keep it procedural.
 
-There are eight source files in this project, but `index.html` and `blocks.css` are basic structure and style for the app and won't be discussed. Two of the JavaScript files won't be discussed in any detail either: `util.js` contains some helpers and serves as a bridge between different browser implementations --- similar to a library like jQuery but in less than 50 lines of code. `file.js` is a similar utility used for loading and saving files and serializing scripts.
+There are eight source files in this project, but `index.html` and `blocks.css` are basic structure and style for the app and won't be discussed. Two of the JavaScript files won't be discussed in any detail either: `util.js` contains some helpers and serves as a bridge between different browser implementations&mdash;similar to a library like jQuery but in less than 50 lines of code. `file.js` is a similar utility used for loading and saving files and serializing scripts.
 
 These are the remaining files:
 

flow-shop/flow-shop.markdown

@@ -73,7 +73,7 @@ MAX_LNS_NEIGHBOURHOODS = 1000 # Maximum number of neighbours to explore in LNS
 
 There are two settings that should be explained further. The `TIME_INCREMENT` setting will be used as part of the dynamic strategy selection, and the `MAX_LNS_NEIGHBOURHOODS` setting will be used as part of the neighbourhood selection strategy. Both are described in more detail below.
 
-These settings could be exposed to the user as command line parameters, but at this stage we instead provide the input data as parameters to the program. The input problem --- a problem from the Taillard benchmark set --- is assumed to be in a standard format for flow shop scheduling. The following code is used as the `__main__` method for the solver file, and calls the appropriate functions based on the number of parameters input to the program:
+These settings could be exposed to the user as command line parameters, but at this stage we instead provide the input data as parameters to the program. The input problem—a problem from the Taillard benchmark set—is assumed to be in a standard format for flow shop scheduling. The following code is used as the `__main__` method for the solver file, and calls the appropriate functions based on the number of parameters input to the program:
 
 ```python
 if __name__ == '__main__':
@@ -113,7 +113,7 @@ def solve(data):
     strat_usage = {strategy: 0 for strategy in STRATEGIES}
 ```
 
-One appealing feature of the flow shop scheduling problem is that *every* permutation is a valid solution, and at least one will have the optimal makespan (though many will have horrible makespans). Thankfully, this allows us to forgo checking that we stay within the space of feasible solutions when going from one permutation to another --- everything is feasible!
+One appealing feature of the flow shop scheduling problem is that *every* permutation is a valid solution, and at least one will have the optimal makespan (though many will have horrible makespans). Thankfully, this allows us to forgo checking that we stay within the space of feasible solutions when going from one permutation to another—everything is feasible!
 
 However, to start a local search in the space of permutations, we must have an initial permutation. To keep things simple, we seed our local search by shuffling the list of jobs randomly:
 
@@ -420,7 +420,7 @@ Finally, we construct the neighbourhood by considering every permutation of the
     return candidates
 ```
 
-The final neighbourhood that we consider is commonly referred to as *Large Neighbourhood Search* (LNS). Intuitively, LNS works by considering small subsets of the current permutation in isolation --- locating the best permutation of the subset of jobs gives us a single candidate for the LNS neighbourhood. By repeating this process for several (or all) subsets of a particular size, we can increase the number of candidates in the neighbourhood. We limit the number that are considered through the `MAX_LNS_NEIGHBOURHOODS` parameter, as the number of neighbours can grow quite quickly. The first step in the LNS computation is to compute the random list of job sets that we will consider swapping using the `combinations` function of the `itertools` package:
+The final neighbourhood that we consider is commonly referred to as *Large Neighbourhood Search* (LNS). Intuitively, LNS works by considering small subsets of the current permutation in isolation—locating the best permutation of the subset of jobs gives us a single candidate for the LNS neighbourhood. By repeating this process for several (or all) subsets of a particular size, we can increase the number of candidates in the neighbourhood. We limit the number that are considered through the `MAX_LNS_NEIGHBOURHOODS` parameter, as the number of neighbours can grow quite quickly. The first step in the LNS computation is to compute the random list of job sets that we will consider swapping using the `combinations` function of the `itertools` package:
 
 ```python
 def neighbours_LNS(data, perm, size = 2):

functionalDB/functionalDB.markdown

@@ -377,7 +377,7 @@ The function `evolution-of` does exactly that. It returns a sequence of pairs, e
 
 So far, our discussion has focused on the structure of our data: what the core components are and how they are aggregated together. It's time to explore the dynamics of our system: how data is changed over time through the add--update--remove _data lifecycle_. 
 
-As we've already discussed, data in an archaeologist's world never actually changes. Once it is created, it exists forever and can only be hidden from the world by data in a newer layer. The term "hidden" is crucial here. Older data does not "disappear" --- it is buried, and can be revealed again by exposing an older layer. Conversely, updating data means obscuring the old by adding a new layer on top of it with something else. We can thus "delete" data by adding a layer of "nothing" on top of it. 
+As we've already discussed, data in an archaeologist's world never actually changes. Once it is created, it exists forever and can only be hidden from the world by data in a newer layer. The term "hidden" is crucial here. Older data does not "disappear"—it is buried, and can be revealed again by exposing an older layer. Conversely, updating data means obscuring the old by adding a new layer on top of it with something else. We can thus "delete" data by adding a layer of "nothing" on top of it. 
 
 This means that when we talk about data lifecycle, we are really talking about adding layers to our data over time. 
 
@@ -1258,7 +1258,7 @@ Finally, we remove all of the result clauses that are "empty" (i.e., their last
 \end{table}
 </latex>
 
-We are now ready to report the results. The result clause structure is unwieldy for this purpose, so we will convert it into an an index-like structure (map of maps) --- with a significant twist. 
+We are now ready to report the results. The result clause structure is unwieldy for this purpose, so we will convert it into an an index-like structure (map of maps)&mdash;with a significant twist. 
 
 To understand the twist, we must first introduce the idea of a _binding pair_, which is a pair that matches a variable name to its value. The variable name is the one used at the predicate clauses, and the value is the value found in the result clauses.
 

image-filters/image-filters.markdown

@@ -6,8 +6,8 @@ _Cate left the tech industry and spent a year finding her way back whilst buildi
 ## A Brilliant Idea (That Wasn’t All That Brilliant)
 
 When I was traveling in China I often saw series of four paintings showing the same
-place in different seasons. Color — the cool whites of winter, pale hues of
-spring, lush greens of summer, and reds and yellows of fall — is what
+place in different seasons. Color—the cool whites of winter, pale hues of
+spring, lush greens of summer, and reds and yellows of fall—is what
 visually 
 differentiates the seasons. Around 2011, I had what I thought was a brilliant
 idea: I wanted to be able to visualize a photo series as a series of colors. I
@@ -48,7 +48,7 @@ University, and later work, filled up my time with other people’s ideas and
 priorities. Part of finishing this project was learning how to carve out time
 to make progress on my own ideas; I required 
 about four hours of good mental time a week. A tool that allowed me to
-move faster was therefore really helpful, even necessary --- although it came with
+move faster was therefore really helpful, even necessary—although it came with
 its own set of problems, especially around writing tests. 
 
 I felt that thorough
@@ -91,8 +91,8 @@ a matter of seconds. However, a long long time ago (in digital terms),
 it was a process that took weeks.
 
 In the old days, we would take the picture, then when we had used a whole roll of film, we would
-take it in to be developed (often at the pharmacy). We'd pick up the developed pictures some days later --- 
-and discover that there was something wrong with many of them.
+take it in to be developed (often at the pharmacy). We'd pick up the developed pictures some days 
+later—and discover that there was something wrong with many of them.
 Hand not steady enough? Random person or thing that we didn’t notice at
 the time? Overexposed? Underexposed? Of course by then it was too late to remedy the problem.