Fixes to meta-programming doc

Author: odersky

docs/docs/reference/symmetric-meta-programming.md

@@ -32,7 +32,7 @@ prints it again in an error message if it evaluates to `false`.
       ~ assertImpl(’(expr))
 
     def assertImpl(expr: Expr[Boolean]) =
-      ’{ if !(~expr) then throw new AssertionError(s"failed assertion: ${~expr}") }
+      ’{ if !(~expr) then throw new AssertionError(s"failed assertion: ${~expr.toString}") }
 
 
 If `e` is an expression, then `’(e)` or `’{e}` represent the typed
@@ -491,14 +491,14 @@ is defined in the companion object of class `Expr` as follows:
 The conversion says that values of types implementing the `Liftable`
 type class can be converted ("lifted") automatically to `Expr`
 values. Dotty comes with instance definitions of `Liftable` for
-several types including all underlying types of literals. For example,
-`Int` values can be converted to `Expr[Int]` values by wrapping the
-value in a `Literal` tree node. This makes use of the underlying tree
-representation in the compiler for efficiency. But the `Liftable`
-instances are nevertheless not "magic" in the sense that they could
-all be defined in a user program without knowing anything about the
-representation of `Expr` trees. For instance, here is a possible
-instance of `Liftable[Boolean]`:
+several types including `Boolean`, `String`, and all primitive number
+types. For example, `Int` values can be converted to `Expr[Int]`
+values by wrapping the value in a `Literal` tree node. This makes use
+of the underlying tree representation in the compiler for
+efficiency. But the `Liftable` instances are nevertheless not "magic"
+in the sense that they could all be defined in a user program without
+knowing anything about the representation of `Expr` trees. For
+instance, here is a possible instance of `Liftable[Boolean]`:
 
     implicit def BooleanIsLiftable: Liftable[Boolean] = new {
       implicit def toExpr(b: Boolean) = if (b) ’(true) else ’(false)
@@ -532,6 +532,16 @@ In the end, `Liftable` resembles very much a serialization
 framework. Like the latter it can be derived systematically for all
 collections, case classes and enums.
 
+In fact, the initial example of assertions also uses a lifting conversion under the hood.
+Recall the failure clause:
+
+    throw new AssertionError(s"failed assertion: ${~expr.toString}") }
+
+Here, `expr.toString` yields `expr`'s representation in String form. That string
+is lifted to an `Expr[String]` since the required type of a splice argument is an `Expr`.
+The lifted result is then spliced in into the `AssertionError` argument, giving
+back again the original string representation of `expr`.
+
 ## Implementation
 
 ### Syntax changes
@@ -603,9 +613,9 @@ The syntax of terms, values, and types is given as follows:
                           ~t                splice
 
     Values        v  ::=  (x: T) => t       lambda
-                          ’q                pure quote
+                          ’u                quote
 
-    Quoted        q  ::=  x  |  (x: T) => q  |  q q  |  ’t
+    Simple terms  u  ::=  x  |  (x: T) => u  |  u u  |  ’t
 
     Types         T  ::=  A                 base type
                           T -> T            function type
@@ -635,7 +645,7 @@ We define a small step reduction relation `-->` with the following rules:
 
                 ((x: T) => t) v  -->  [x := v]t
 
-                          ~(’t)  -->  t
+                          ~(’u)  -->  u
 
                              t1  -->  t2
                           -----------------
@@ -648,7 +658,7 @@ position of an evaluation context.  Evaluation contexts `e` and
 splice evaluation context `e_s` are defined syntactically as follows:
 
     Eval context    e    ::=  [ ]  |  e t  |  v e  |  ’e_s[~e]
-    Splice context  e_s  ::=  [ ]  |  (x: T) => e_s  |  e_s t  |  q e_s
+    Splice context  e_s  ::=  [ ]  |  (x: T) => e_s  |  e_s t  |  u e_s
 
 ### Typing rules