docs: update highlighting

1 files changed, 8 insertions, 8 deletions

diff --git a/docs/book/SYNTAX.html b/docs/book/SYNTAX.html
index 4860718..6783b5e 100644
--- a/docs/book/SYNTAX.html
+++ b/docs/book/SYNTAX.html
@@ -176,7 +176,7 @@
                         <h1 id="syntax-a-casual-and-formal-look"><a class="header" href="#syntax-a-casual-and-formal-look">Syntax: A Casual and Formal Look</a></h1>
 <h2 id="call-syntax"><a class="header" href="#call-syntax">Call Syntax</a></h2>
 <p>There is little difference between a function, macro, and operator call. There are only a few forms such calls can take, too, though notably more than most other languages (due to, among other things, uniform function call syntax): hence this section.</p>
-<pre><code># The standard, unambiguous call.
+<pre><code class="language-puck"># The standard, unambiguous call.
 routine(1, 2, 3, 4)
 # The method call syntax equivalent.
 1.routine(2, 3, 4)
@@ -191,7 +191,7 @@ routine
 routine 1, 2, 3, 4
 </code></pre>
 <p>Binary operators have some special rules.</p>
-<pre><code># Valid call syntaxes for binary operators. What can constitute a binary
+<pre><code class="language-puck"># Valid call syntaxes for binary operators. What can constitute a binary
 # operator is constrained for parsing's sake. Whitespace is optional.
 1 + 2
 1+2
@@ -199,12 +199,12 @@ routine 1, 2, 3, 4
 +(1, 2)
 </code></pre>
 <p>As do unary operators.</p>
-<pre><code># The standard call for unary operators. Postfix.
+<pre><code class="language-puck"># The standard call for unary operators. Postfix.
 1?
 ?(1)
 </code></pre>
 <p>Method call syntax has a number of advantages: notably that it can be <em>chained</em>: acting as a natural pipe operator. Redundant parenthesis can also be omitted.</p>
-<pre><code># The following statements are equivalent:
+<pre><code class="language-puck"># The following statements are equivalent:
 foo.bar.baz
 foo().bar().baz()
 baz(bar(foo))
@@ -252,7 +252,7 @@ of this then ...
 of that then ...
 </code></pre>
 <p>A line beginning with a scope token is treated as attached to the previous expression.</p>
-<pre><code># Technically allowed. Please don't do this.
+<pre><code class="language-puck"># Technically allowed. Please don't do this.
 let foo
 = ...
 
@@ -271,7 +271,7 @@ then ...
 of that then ...
 </code></pre>
 <p>This <em>can</em> lead to some ugly possibilities for formatting that are best avoided.</p>
-<pre><code># Much preferred.
+<pre><code class="language-puck"># Much preferred.
 
 let foo =
   ...
@@ -298,7 +298,7 @@ of that then ...
 <p>First, a word on the distinction between <em>expressions</em> and <em>statements</em>. Expressions return a value. Statements do not. That is all.</p>
 <p>There are some syntactic constructs unambiguously recognizable as statements: all declarations, modules, and <code>use</code> statements. There are no syntactic constructs unambiguously recognizable as expressions. As calls returning <code>void</code> are treated as statements, and expressions that return a type could possibly return <code>void</code>, there is no explicit distinction between expressions and statements made in the parser: or anywhere before type-checking.</p>
 <p>Expressions can go almost anywhere. Our indentation rules above allow for it.</p>
-<pre><code># Some different formulations of valid expressions.
+<pre><code class="language-puck"># Some different formulations of valid expressions.
 
 if cond then
   this
@@ -320,7 +320,7 @@ let foo =
   else
     that
 </code></pre>
-<pre><code># Some different formulations of *invalid* expressions.
+<pre><code class="language-puck"># Some different formulations of *invalid* expressions.
 # These primarily break the rule that everything following a scope token
 # (ex. `=`, `do`, `then`) not at the end of the line must be self-contained.