Fancy quotes

preserves.md

@@ -242,7 +242,7 @@ duplicate elements or for a dictionary to contain duplicate keys.
 
 Numeric data follow the
 [JSON grammar](https://tools.ietf.org/html/rfc8259#section-6), with
-the addition of a trailing "f" distinguishing `Float` from `Double`
+the addition of a trailing “f” distinguishing `Float` from `Double`
 values. `Float`s and `Double`s always have either a fractional part or
 an exponent part, where `SignedInteger`s never have
 either.[^reading-and-writing-floats-accurately]
@@ -339,7 +339,7 @@ URL-safe Base64 characters are allowed.
        ByteString =/ %s"#base64{" *(ws / base64char) ws "}" /
         base64char = %x41-5A / %x61-7A / %x30-39 / "+" / "/" / "-" / "_" / "="
 
-A `Symbol` may be written in a "bare" form[^cf-sexp-token] so long as
+A `Symbol` may be written in a “bare” form[^cf-sexp-token] so long as
 it conforms to certain restrictions on the characters appearing in the
 symbol. Alternatively, it may be written in a quoted form. The quoted
 form is much the same as the syntax for `String`s, including embedded
@@ -359,7 +359,7 @@ double quote mark.
                       category is Nd, Nl, No, or Pd>
 
   [^cf-sexp-token]: Compare with the [SPKI S-expression][sexp.txt]
-    definition of "token representation", and with the
+    definition of “token representation”, and with the
     [R6RS definition of identifiers](http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-7.html#node_sec_4.2.4).
 
 Finally, any `Value` may be represented by escaping from the textual
@@ -396,7 +396,7 @@ itself have annotations.
 
 Each annotation is preceded by `@`; the underlying annotated value
 follows its annotations. Here we extend only the syntactic nonterminal
-named "`Value`" without altering the semantic class of `Value`s.
+named “`Value`” without altering the semantic class of `Value`s.
 
 **Equivalence.** Annotations appear within syntax denoting a `Value`;
 however, the annotations are not part of the denoted value. They are
@@ -419,7 +419,7 @@ different.
 A `Repr` is a binary-syntax encoding, or representation, of either
 
  - a `Value`,
- - a "placeholder" for a `Value`, or
+ - a “placeholder” for a `Value`, or
  - an annotation on a `Repr`.
 
 Each `Repr` comprises one or more bytes describing the kind of
@@ -883,9 +883,9 @@ represent semi-structured data over `ByteString`, `String`,
     similar to Preserves. However, while they include binary data and
     sequences, and an obvious equivalence for them exists, they lack
     numbers *per se* as well as any kind of unordered structure such
-    as sets or maps. In addition, while "display hints" allow
+    as sets or maps. In addition, while “display hints” allow
     labelling of binary data with an intended interpretation, they
-    cannot be attached to any other kind of structure, and the "hint"
+    cannot be attached to any other kind of structure, and the “hint”
     itself can only be a binary blob.
 
 However, users need a wide variety of data types for representing
@@ -1030,13 +1030,13 @@ A `Tuple` is a `Record` with label `tuple` and zero or more fields,
 denoting an anonymous tuple of values.
 
 The 0-ary tuple, `<tuple>`, denotes the empty tuple, sometimes called
-"unit" or "void" (but *not* e.g. JavaScript's "undefined" value).
+“unit” or “void” (but *not* e.g. JavaScript's “undefined” value).
 
 ### Null and Undefined.
 
 Tony Hoare's
-"[billion-dollar mistake](https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions)"
-can be represented with the 0-ary `Record` `<null>`. An "undefined"
+“[billion-dollar mistake](https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions)”
+can be represented with the 0-ary `Record` `<null>`. An “undefined”
 value can be represented as `<undefined>`.
 
 ### Dates and Times.
@@ -1273,7 +1273,7 @@ binary data.
 ### JSON syntax doesn't *mean* anything
 
 When are two JSON values the same? When are they different?
-<!-- When is one JSON value "less than" another? -->
+<!-- When is one JSON value “less than” another? -->
 
 The specifications are largely silent on these questions. Different
 JSON implementations give different answers.
@@ -1355,7 +1355,7 @@ represented as strings with an implicit internal structure.
 There is no convention for *labelling* a value as belonging to a
 particular category. Instead, JSON-encoded data are often labelled in
 an ad-hoc way. Multiple incompatible approaches exist. For example, a
-"money" structure containing a `currency` field and an `amount` may be
+“money” structure containing a `currency` field and an `amount` may be
 represented in any number of ways:
 
     { "_type": "money", "currency": "EUR", "amount": 10 }
@@ -1364,11 +1364,11 @@ represented in any number of ways:
     { "@money": { "currency": "EUR", "amount": 10 } }
 
 This causes particular problems when JSON is used to represent *sum*
-or *union* types, such as "either a value or an error, but not both".
+or *union* types, such as “either a value or an error, but not both”.
 Again, multiple incompatible approaches exist.
 
 For example, imagine an API for depositing money in an account. The
-response might be either a "success" response indicating the new
+response might be either a “success” response indicating the new
 balance, or one of a set of possible errors.
 
 Sometimes, a *pair* of values is used, with `null` marking the option