diff --git a/docs/fpp-spec.html b/docs/fpp-spec.html
index c5caeb31f..b5f73f6b4 100644
--- a/docs/fpp-spec.html
+++ b/docs/fpp-spec.html
@@ -5,7 +5,7 @@
 <meta http-equiv="X-UA-Compatible" content="IE=edge">
 <meta name="viewport" content="width=device-width, initial-scale=1.0">
 <meta name="generator" content="Asciidoctor 2.0.20">
-<title>The F Prime Prime (FPP) Language Specification, Unreleased, after v2.1.0</title>
+<title>The F Prime Prime (FPP) Language Specification, v2.2.0</title>
 <link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Open+Sans:300,300italic,400,400italic,600,600italic%7CNoto+Serif:400,400italic,700,700italic%7CDroid+Sans+Mono:400,700">
 <style>
 /*! Asciidoctor default stylesheet | MIT License | https://asciidoctor.org */
@@ -436,7 +436,7 @@
 </head>
 <body class="article toc2 toc-left">
 <div id="header">
-<h1>The F Prime Prime (FPP) Language Specification, Unreleased, after v2.1.0</h1>
+<h1>The F Prime Prime (FPP) Language Specification, v2.2.0</h1>
 <div id="toc" class="toc2">
 <div id="toctitle">Table of Contents</div>
 <ul class="sectlevel1">
@@ -526,10 +526,9 @@ <h1>The F Prime Prime (FPP) Language Specification, Unreleased, after v2.1.0</h1
 <li><a href="#Definitions_State-Machine-Definitions">5.10. State Machine Definitions</a>
 <ul class="sectlevel3">
 <li><a href="#Definitions_State-Machine-Definitions_Syntax">5.10.1. Syntax</a></li>
-<li><a href="#Definitions_State-Machine-Definitions_Semantics">5.10.2. Semantics</a></li>
-<li><a href="#Definitions_State-Machine-Definitions_The-Transition-Graph">5.10.3. The Transition Graph</a></li>
-<li><a href="#Definitions_State-Machine-Definitions_Scoping-of-Names">5.10.4. Scoping of Names</a></li>
-<li><a href="#Definitions_State-Machine-Definitions_Examples">5.10.5. Examples</a></li>
+<li><a href="#Definitions_State-Machine-Definitions_Static-Semantics">5.10.2. Static Semantics</a></li>
+<li><a href="#Definitions_State-Machine-Definitions_Dynamic-Semantics">5.10.3. Dynamic Semantics</a></li>
+<li><a href="#Definitions_State-Machine-Definitions_Examples">5.10.4. Examples</a></li>
 </ul>
 </li>
 <li><a href="#Definitions_Struct-Definitions">5.11. Struct Definitions</a>
@@ -557,11 +556,11 @@ <h1>The F Prime Prime (FPP) Language Specification, Unreleased, after v2.1.0</h1
 <li><a href="#State-Machine-Behavior-Elements_Action-Definitions_Examples">6.1.3. Examples</a></li>
 </ul>
 </li>
-<li><a href="#State-Machine-Behavior-Elements_Enter-Expressions">6.2. Enter Expressions</a>
+<li><a href="#State-Machine-Behavior-Elements_Do-Expressions">6.2. Do Expressions</a>
 <ul class="sectlevel3">
-<li><a href="#State-Machine-Behavior-Elements_Enter-Expressions_Syntax">6.2.1. Syntax</a></li>
-<li><a href="#State-Machine-Behavior-Elements_Enter-Expressions_Semantics">6.2.2. Semantics</a></li>
-<li><a href="#State-Machine-Behavior-Elements_Enter-Expressions_Examples">6.2.3. Examples</a></li>
+<li><a href="#State-Machine-Behavior-Elements_Do-Expressions_Syntax">6.2.1. Syntax</a></li>
+<li><a href="#State-Machine-Behavior-Elements_Do-Expressions_Semantics">6.2.2. Semantics</a></li>
+<li><a href="#State-Machine-Behavior-Elements_Do-Expressions_Examples">6.2.3. Examples</a></li>
 </ul>
 </li>
 <li><a href="#State-Machine-Behavior-Elements_Guard-Definitions">6.3. Guard Definitions</a>
@@ -574,15 +573,17 @@ <h1>The F Prime Prime (FPP) Language Specification, Unreleased, after v2.1.0</h1
 <li><a href="#State-Machine-Behavior-Elements_Initial-Transition-Specifiers">6.4. Initial Transition Specifiers</a>
 <ul class="sectlevel3">
 <li><a href="#State-Machine-Behavior-Elements_Initial-Transition-Specifiers_Syntax">6.4.1. Syntax</a></li>
-<li><a href="#State-Machine-Behavior-Elements_Initial-Transition-Specifiers_Semantics">6.4.2. Semantics</a></li>
-<li><a href="#State-Machine-Behavior-Elements_Initial-Transition-Specifiers_Examples">6.4.3. Examples</a></li>
+<li><a href="#State-Machine-Behavior-Elements_Initial-Transition-Specifiers_Static-Semantics">6.4.2. Static Semantics</a></li>
+<li><a href="#State-Machine-Behavior-Elements_Initial-Transition-Specifiers_Dynamic-Semantics">6.4.3. Dynamic Semantics</a></li>
+<li><a href="#State-Machine-Behavior-Elements_Initial-Transition-Specifiers_Examples">6.4.4. Examples</a></li>
 </ul>
 </li>
 <li><a href="#State-Machine-Behavior-Elements_Junction-Definitions">6.5. Junction Definitions</a>
 <ul class="sectlevel3">
 <li><a href="#State-Machine-Behavior-Elements_Junction-Definitions_Syntax">6.5.1. Syntax</a></li>
-<li><a href="#State-Machine-Behavior-Elements_Junction-Definitions_Semantics">6.5.2. Semantics</a></li>
-<li><a href="#State-Machine-Behavior-Elements_Junction-Definitions_Examples">6.5.3. Examples</a></li>
+<li><a href="#State-Machine-Behavior-Elements_Junction-Definitions_Static-Semantics">6.5.2. Static Semantics</a></li>
+<li><a href="#State-Machine-Behavior-Elements_Junction-Definitions_Dynamic-Semantics">6.5.3. Dynamic Semantics</a></li>
+<li><a href="#State-Machine-Behavior-Elements_Junction-Definitions_Examples">6.5.4. Examples</a></li>
 </ul>
 </li>
 <li><a href="#State-Machine-Behavior-Elements_Signal-Definitions">6.6. Signal Definitions</a>
@@ -595,15 +596,40 @@ <h1>The F Prime Prime (FPP) Language Specification, Unreleased, after v2.1.0</h1
 <li><a href="#State-Machine-Behavior-Elements_State-Definitions">6.7. State Definitions</a>
 <ul class="sectlevel3">
 <li><a href="#State-Machine-Behavior-Elements_State-Definitions_Syntax">6.7.1. Syntax</a></li>
-<li><a href="#State-Machine-Behavior-Elements_State-Definitions_Semantics">6.7.2. Semantics</a></li>
-<li><a href="#State-Machine-Behavior-Elements_State-Definitions_Examples">6.7.3. Examples</a></li>
+<li><a href="#State-Machine-Behavior-Elements_State-Definitions_Static-Semantics">6.7.2. Static Semantics</a></li>
+<li><a href="#State-Machine-Behavior-Elements_State-Definitions_Dynamic-Semantics">6.7.3. Dynamic Semantics</a></li>
+<li><a href="#State-Machine-Behavior-Elements_State-Definitions_Examples">6.7.4. Examples</a></li>
 </ul>
 </li>
-<li><a href="#State-Machine-Behavior-Elements_State-Transition-Specifiers">6.8. State Transition Specifiers</a>
+<li><a href="#State-Machine-Behavior-Elements_State-Entry-Specifiers">6.8. State Entry Specifiers</a>
 <ul class="sectlevel3">
-<li><a href="#State-Machine-Behavior-Elements_State-Transition-Specifiers_Syntax">6.8.1. Syntax</a></li>
-<li><a href="#State-Machine-Behavior-Elements_State-Transition-Specifiers_Semantics">6.8.2. Semantics</a></li>
-<li><a href="#State-Machine-Behavior-Elements_State-Transition-Specifiers_Examples">6.8.3. Examples</a></li>
+<li><a href="#State-Machine-Behavior-Elements_State-Entry-Specifiers_Syntax">6.8.1. Syntax</a></li>
+<li><a href="#State-Machine-Behavior-Elements_State-Entry-Specifiers_Semantics">6.8.2. Semantics</a></li>
+<li><a href="#State-Machine-Behavior-Elements_State-Entry-Specifiers_Examples">6.8.3. Examples</a></li>
+</ul>
+</li>
+<li><a href="#State-Machine-Behavior-Elements_State-Exit-Specifiers">6.9. State Exit Specifiers</a>
+<ul class="sectlevel3">
+<li><a href="#State-Machine-Behavior-Elements_State-Exit-Specifiers_Syntax">6.9.1. Syntax</a></li>
+<li><a href="#State-Machine-Behavior-Elements_State-Exit-Specifiers_Semantics">6.9.2. Semantics</a></li>
+<li><a href="#State-Machine-Behavior-Elements_State-Exit-Specifiers_Examples">6.9.3. Examples</a></li>
+</ul>
+</li>
+<li><a href="#State-Machine-Behavior-Elements_State-Transition-Specifiers">6.10. State Transition Specifiers</a>
+<ul class="sectlevel3">
+<li><a href="#State-Machine-Behavior-Elements_State-Transition-Specifiers_Syntax">6.10.1. Syntax</a></li>
+<li><a href="#State-Machine-Behavior-Elements_State-Transition-Specifiers_Static-Semantics">6.10.2. Static Semantics</a></li>
+<li><a href="#State-Machine-Behavior-Elements_State-Transition-Specifiers_The-State-Transition-Map">6.10.3. The State Transition Map</a></li>
+<li><a href="#State-Machine-Behavior-Elements_State-Transition-Specifiers_Dynamic-Semantics">6.10.4. Dynamic Semantics</a></li>
+<li><a href="#State-Machine-Behavior-Elements_State-Transition-Specifiers_Examples">6.10.5. Examples</a></li>
+</ul>
+</li>
+<li><a href="#State-Machine-Behavior-Elements_Transition-Expressions">6.11. Transition Expressions</a>
+<ul class="sectlevel3">
+<li><a href="#State-Machine-Behavior-Elements_Transition-Expressions_Syntax">6.11.1. Syntax</a></li>
+<li><a href="#State-Machine-Behavior-Elements_Transition-Expressions_Static-Semantics">6.11.2. Static Semantics</a></li>
+<li><a href="#State-Machine-Behavior-Elements_Transition-Expressions_Dynamic-Semantics">6.11.3. Dynamic Semantics</a></li>
+<li><a href="#State-Machine-Behavior-Elements_Transition-Expressions_Examples">6.11.4. Examples</a></li>
 </ul>
 </li>
 </ul>
@@ -704,8 +730,9 @@ <h1>The F Prime Prime (FPP) Language Specification, Unreleased, after v2.1.0</h1
 <li><a href="#Specifiers_State-Machine-Instance-Specifiers">7.14. State Machine Instance Specifiers</a>
 <ul class="sectlevel3">
 <li><a href="#Specifiers_State-Machine-Instance-Specifiers_Syntax">7.14.1. Syntax</a></li>
-<li><a href="#Specifiers_State-Machine-Instance-Specifiers_Semantics">7.14.2. Semantics</a></li>
-<li><a href="#Specifiers_State-Machine-Instance-Specifiers_Examples">7.14.3. Examples</a></li>
+<li><a href="#Specifiers_State-Machine-Instance-Specifiers_Static-Semantics">7.14.2. Static Semantics</a></li>
+<li><a href="#Specifiers_State-Machine-Instance-Specifiers_Dynamic-Semantics">7.14.3. Dynamic Semantics</a></li>
+<li><a href="#Specifiers_State-Machine-Instance-Specifiers_Examples">7.14.4. Examples</a></li>
 </ul>
 </li>
 <li><a href="#Specifiers_Telemetry-Channel-Specifiers">7.15. Telemetry Channel Specifiers</a>
@@ -888,44 +915,55 @@ <h1>The F Prime Prime (FPP) Language Specification, Unreleased, after v2.1.0</h1
 </li>
 </ul>
 </li>
-<li><a href="#Values">19. Values</a>
+<li><a href="#Type-Options">19. Type Options</a>
+<ul class="sectlevel2">
+<li><a href="#Type-Options_Conversion-of-Type-Options">19.1. Conversion of Type Options</a></li>
+<li><a href="#Type-Options_Computing-a-Common-Type-Option">19.2. Computing a Common Type Option</a>
+<ul class="sectlevel3">
+<li><a href="#Type-Options_Computing-a-Common-Type-Option_Pairs-of-Type-Options">19.2.1. Pairs of Type Options</a></li>
+<li><a href="#Type-Options_Computing-a-Common-Type-Option_Lists-of-Type-Options">19.2.2. Lists of Type Options</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><a href="#Values">20. Values</a>
 <ul class="sectlevel2">
-<li><a href="#Values_Primitive-Integer-Values">19.1. Primitive Integer Values</a></li>
-<li><a href="#Values_Integer-Values">19.2. Integer Values</a></li>
-<li><a href="#Values_Floating-Point-Values">19.3. Floating-Point Values</a></li>
-<li><a href="#Values_Boolean-Values">19.4. Boolean Values</a></li>
-<li><a href="#Values_String-Values">19.5. String Values</a></li>
-<li><a href="#Values_Abstract-Type-Values">19.6. Abstract Type Values</a></li>
-<li><a href="#Values_Anonymous-Array-Values">19.7. Anonymous Array Values</a></li>
-<li><a href="#Values_Array-Values">19.8. Array Values</a></li>
-<li><a href="#Values_Enumeration-Values">19.9. Enumeration Values</a></li>
-<li><a href="#Values_Anonymous-Struct-Values">19.10. Anonymous Struct Values</a></li>
-<li><a href="#Values_Struct-Values">19.11. Struct Values</a></li>
-<li><a href="#Values_Serialized-Sizes">19.12. Serialized Sizes</a></li>
+<li><a href="#Values_Primitive-Integer-Values">20.1. Primitive Integer Values</a></li>
+<li><a href="#Values_Integer-Values">20.2. Integer Values</a></li>
+<li><a href="#Values_Floating-Point-Values">20.3. Floating-Point Values</a></li>
+<li><a href="#Values_Boolean-Values">20.4. Boolean Values</a></li>
+<li><a href="#Values_String-Values">20.5. String Values</a></li>
+<li><a href="#Values_Abstract-Type-Values">20.6. Abstract Type Values</a></li>
+<li><a href="#Values_Anonymous-Array-Values">20.7. Anonymous Array Values</a></li>
+<li><a href="#Values_Array-Values">20.8. Array Values</a></li>
+<li><a href="#Values_Enumeration-Values">20.9. Enumeration Values</a></li>
+<li><a href="#Values_Anonymous-Struct-Values">20.10. Anonymous Struct Values</a></li>
+<li><a href="#Values_Struct-Values">20.11. Struct Values</a></li>
+<li><a href="#Values_Serialized-Sizes">20.12. Serialized Sizes</a></li>
 </ul>
 </li>
-<li><a href="#Evaluation">20. Evaluation</a>
+<li><a href="#Evaluation">21. Evaluation</a>
 <ul class="sectlevel2">
-<li><a href="#Evaluation_Evaluating-Expressions">20.1. Evaluating Expressions</a></li>
-<li><a href="#Evaluation_Type-Conversion">20.2. Type Conversion</a>
+<li><a href="#Evaluation_Evaluating-Expressions">21.1. Evaluating Expressions</a></li>
+<li><a href="#Evaluation_Type-Conversion">21.2. Type Conversion</a>
 <ul class="sectlevel3">
-<li><a href="#Evaluation_Type-Conversion_Unsigned-Primitive-Integer-Values">20.2.1. Unsigned Primitive Integer Values</a></li>
-<li><a href="#Evaluation_Type-Conversion_Signed-Primitive-Integer-Values">20.2.2. Signed Primitive Integer Values</a></li>
-<li><a href="#Evaluation_Type-Conversion_Primitive-Integer-Values-of-Mixed-Sign">20.2.3. Primitive Integer Values of Mixed Sign</a></li>
-<li><a href="#Evaluation_Type-Conversion_Primitive-and-Non-Primitive-Integer-Values">20.2.4. Primitive and Non-Primitive Integer Values</a></li>
-<li><a href="#Evaluation_Type-Conversion_Floating-Point-Values">20.2.5. Floating-Point Values</a></li>
-<li><a href="#Evaluation_Type-Conversion_Array-Values">20.2.6. Array Values</a></li>
-<li><a href="#Evaluation_Type-Conversion_Structure-Values">20.2.7. Structure Values</a></li>
+<li><a href="#Evaluation_Type-Conversion_Unsigned-Primitive-Integer-Values">21.2.1. Unsigned Primitive Integer Values</a></li>
+<li><a href="#Evaluation_Type-Conversion_Signed-Primitive-Integer-Values">21.2.2. Signed Primitive Integer Values</a></li>
+<li><a href="#Evaluation_Type-Conversion_Primitive-Integer-Values-of-Mixed-Sign">21.2.3. Primitive Integer Values of Mixed Sign</a></li>
+<li><a href="#Evaluation_Type-Conversion_Primitive-and-Non-Primitive-Integer-Values">21.2.4. Primitive and Non-Primitive Integer Values</a></li>
+<li><a href="#Evaluation_Type-Conversion_Floating-Point-Values">21.2.5. Floating-Point Values</a></li>
+<li><a href="#Evaluation_Type-Conversion_Array-Values">21.2.6. Array Values</a></li>
+<li><a href="#Evaluation_Type-Conversion_Structure-Values">21.2.7. Structure Values</a></li>
 </ul>
 </li>
 </ul>
 </li>
-<li><a href="#Analysis-and-Translation">21. Analysis and Translation</a>
+<li><a href="#Analysis-and-Translation">22. Analysis and Translation</a>
 <ul class="sectlevel2">
-<li><a href="#Analysis-and-Translation_Analysis">21.1. Analysis</a></li>
-<li><a href="#Analysis-and-Translation_Analysis-Tools">21.2. Analysis Tools</a></li>
-<li><a href="#Analysis-and-Translation_Translation">21.3. Translation</a></li>
-<li><a href="#Analysis-and-Translation_Translation-Tools">21.4. Translation Tools</a></li>
+<li><a href="#Analysis-and-Translation_Analysis">22.1. Analysis</a></li>
+<li><a href="#Analysis-and-Translation_Analysis-Tools">22.2. Analysis Tools</a></li>
+<li><a href="#Analysis-and-Translation_Translation">22.3. Translation</a></li>
+<li><a href="#Analysis-and-Translation_Translation-Tools">22.4. Translation Tools</a></li>
 </ul>
 </li>
 </ul>
@@ -2759,9 +2797,7 @@ <h3 id="Definitions_State-Machine-Definitions">5.10. State Machine Definitions</
 </div>
 <div class="paragraph">
 <p><strong>Implementation note:</strong>
-Support for state machines will be implemented in two phases.
-Phase 1 will implement external state machine definitions only.
-Phase 2 will add support for internal state machine definitions.</p>
+As of FPP v2.2.0, only external state machine definitions are implemented.</p>
 </div>
 <div class="sect3">
 <h4 id="Definitions_State-Machine-Definitions_Syntax">5.10.1. Syntax</h4>
@@ -2798,9 +2834,14 @@ <h4 id="Definitions_State-Machine-Definitions_Syntax">5.10.1. Syntax</h4>
 </li>
 </ul>
 </div>
+<div class="paragraph">
+<p>The <strong>transitive members</strong> of a state machine definition <em>M</em> are
+(1) the elements of <em>M</em> and (2)
+the members of any state definition that is a transitive member of <em>M</em>.</p>
+</div>
 </div>
 <div class="sect3">
-<h4 id="Definitions_State-Machine-Definitions_Semantics">5.10.2. Semantics</h4>
+<h4 id="Definitions_State-Machine-Definitions_Static-Semantics">5.10.2. Static Semantics</h4>
 <div class="olist arabic">
 <ol class="arabic">
 <li>
@@ -2826,17 +2867,21 @@ <h4 id="Definitions_State-Machine-Definitions_Semantics">5.10.2. Semantics</h4>
 </li>
 <li>
 <p><em>M</em> must satisfy the rules described
-<a href="#Definitions_State-Machine-Definitions_The-Transition-Graph">below</a>
+<a href="#Definitions_State-Machine-Definitions_Static-Semantics_The-Transition-Graph">below</a>
 for the induced transition graph.</p>
 </li>
+<li>
+<p><em>M</em> must satisfy the rules described
+<a href="#Definitions_State-Machine-Definitions_Static-Semantics_Typed-Elements">below</a>
+for typed elements.</p>
+</li>
 </ol>
 </div>
 </li>
 </ol>
 </div>
-</div>
-<div class="sect3">
-<h4 id="Definitions_State-Machine-Definitions_The-Transition-Graph">5.10.3. The Transition Graph</h4>
+<div class="sect4">
+<h5 id="Definitions_State-Machine-Definitions_Static-Semantics_The-Transition-Graph">The Transition Graph</h5>
 <div class="paragraph">
 <p>If present, the optional state machine member sequence <em>M</em>
 induces a directed graph called the <strong>transition graph</strong>, defined as
@@ -2845,24 +2890,30 @@ <h4 id="Definitions_State-Machine-Definitions_The-Transition-Graph">5.10.3. The
 <div class="olist arabic">
 <ol class="arabic">
 <li>
-<p>The nodes of the transition graph are the initial transition specifiers,
-state definitions, and
+<p>The nodes of the transition graph are the state definitions and
 junction definitions that are transitive members of <em>M</em>.</p>
 </li>
 <li>
-<p>The <strong>transitive members</strong> of <em>M</em> are (i) the elements of <em>M</em> and (ii)
-the members of any state definition that is a transitive member of <em>M</em>.</p>
+<p>The <strong>initial node</strong> of the transition graph is the state definition
+or junction definition referred to in the unique initial transition specifier
+that is an element of <em>M</em>.</p>
 </li>
 <li>
-<p>The arcs of the transition graph are given by the <a href="#State-Machine-Behavior-Elements_Enter-Expressions">enter expressions</a> <em>e</em> that are parts of transitive members of <em>M</em>.
-Each enter expression represents an arc from an <strong>initial node</strong> to a <strong>terminal node</strong>.
-The initial node is defined as follows:</p>
+<p>The arcs of the transition graph are given by the
+<a href="#State-Machine-Behavior-Elements_Transition-Expressions">transition expressions</a> <em>e</em> that appear in (1) initial transition specifiers
+that are members of states that are transitive members of <em>M</em> and (2)
+state transition specifiers that are transitive members of <em>M</em> and (3)
+junction definitions that are transitive members of <em>M</em>.
+Each transition expression represents an arc from a <strong>start node</strong> to an
+<strong>end node</strong>.
+The start node is defined as follows:</p>
 <div class="olist loweralpha">
 <ol class="loweralpha" type="a">
 <li>
 <p>If <em>e</em> appears in an
-<a href="#State-Machine-Behavior-Elements_Initial-Transition-Specifiers">initial transition specifier</a> <em>I</em>, then the initial node
-is <em>I</em>.</p>
+<a href="#State-Machine-Behavior-Elements_Initial-Transition-Specifiers">initial transition specifier</a> <em>I</em>, then the initial node is the
+<a href="#State-Machine-Behavior-Elements_State-Definitions">state definition</a>
+immediately enclosing <em>I</em>.</p>
 </li>
 <li>
 <p>If <em>e</em> appears in a
@@ -2879,10 +2930,9 @@ <h4 id="Definitions_State-Machine-Definitions_The-Transition-Graph">5.10.3. The
 </ol>
 </div>
 <div class="paragraph">
-<p>In any case,
-the terminal node is the state definition or junction definition
-<a href="#Definitions_State-Machine-Definitions_Scoping-of-Names">referred to</a>
-in <em>e</em> after the keyword <code>enter</code>.</p>
+<p>The terminal node is the state or junction definition
+<a href="#Definitions_State-Machine-Definitions_Static-Semantics_Scoping-of-Names">referred to</a>
+in <em>e</em>.</p>
 </div>
 </li>
 </ol>
@@ -2894,20 +2944,96 @@ <h4 id="Definitions_State-Machine-Definitions_The-Transition-Graph">5.10.3. The
 <div class="olist arabic">
 <ol class="arabic">
 <li>
-<p>Each state machine definition and each junction definition in
-<em>T</em> must be the terminal node of at least one arc.</p>
+<p>Each state definition and each junction definition in
+<em>T</em> must be reachable from the initial node of <em>T</em>.</p>
 </li>
 <li>
 <p>Let <em>S</em> be the subgraph of <em>T</em> consisting of all
-and only the junction definitions and the arcs whose initial
-and terminal nodes are junction definitions.
+and only the junction definitions and the arcs whose start
+and end nodes are junction definitions.
 There must be no cycles in <em>S</em>.</p>
 </li>
 </ol>
 </div>
 </div>
-<div class="sect3">
-<h4 id="Definitions_State-Machine-Definitions_Scoping-of-Names">5.10.4. Scoping of Names</h4>
+<div class="sect4">
+<h5 id="Definitions_State-Machine-Definitions_Static-Semantics_Typed-Elements">Typed Elements</h5>
+<div class="paragraph">
+<p>A <strong>typed element</strong> <em>e</em> is an
+<a href="#State-Machine-Behavior-Elements_Initial-Transition-Specifiers">initial transition specifier</a>,
+a
+<a href="#State-Machine-Behavior-Elements_State-Entry-Specifiers">state entry specifier</a>,
+a
+<a href="#State-Machine-Behavior-Elements_State-Transition-Specifiers">state transition specifier</a>,
+a
+<a href="#State-Machine-Behavior-Elements_State-Exit-Specifiers">state exit specifier</a>,
+or a
+<a href="#State-Machine-Behavior-Elements_Junction-Definitions">junction definition</a>.
+A typed element <em>e</em> <strong>points to</strong> a junction <em>J</em> if</p>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p><em>e</em> is an initial transition specifier, and its transition expression
+refers to <em>J</em>; or</p>
+</li>
+<li>
+<p><em>e</em> is a state transition specifier with a transition expression that refers to
+<em>J</em>; or</p>
+</li>
+<li>
+<p><em>e</em> is a junction, and at least one of its transition expressions
+refers to <em>J</em>.</p>
+</li>
+</ol>
+</div>
+<div class="paragraph">
+<p>It must be possible to assign <a href="#Type-Options">type options</a>
+to all the typed elements in a state machine definition in
+the following way.
+If not, an error results.</p>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The type option of each initial transition specifier, state entry
+specifier, and state exit specifier is <em>None</em>.</p>
+</li>
+<li>
+<p>The type option of each state transition specifier <em>S</em> is the type
+option specified in the definition of the signal specified in <em>S</em>
+after the keyword <code>on</code>.</p>
+</li>
+<li>
+<p>The type option of a junction <em>J</em> is the
+<a href="#Type-Options_Computing-a-Common-Type-Option_Lists-of-Type-Options">common type option</a> of the type options of the typed elements
+that point to <em>J</em>.</p>
+</li>
+</ol>
+</div>
+<div class="paragraph">
+<p>For each typed element <em>e</em></p>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>Let <em>O</em> be the type option assigned to <em>e</em> as described above.</p>
+</li>
+<li>
+<p>For every action <em>A</em> appearing in the list of <code>do</code> actions specified in <em>e</em>,
+<em>O</em> must be <a href="#Type-Options_Conversion-of-Type-Options">convertible to</a>
+the type option specified in <em>A</em>.</p>
+</li>
+<li>
+<p>For every guard <em>G</em> appearing in an <code>if</code> construct in <em>e</em>,
+<em>O</em> must be <a href="#Type-Options_Conversion-of-Type-Options">convertible to</a>
+the type option specified in <em>G</em>.</p>
+</li>
+</ol>
+</div>
+</div>
+<div class="sect4">
+<h5 id="Definitions_State-Machine-Definitions_Static-Semantics_Scoping-of-Names">Scoping of Names</h5>
 <div class="paragraph">
 <p>Inside the optional state machine member sequence, the following
 rules govern the assignment of names to definitions and the resolution
@@ -2981,31 +3107,67 @@ <h4 id="Definitions_State-Machine-Definitions_Scoping-of-Names">5.10.4. Scoping
 </ol>
 </div>
 </div>
+</div>
+<div class="sect3">
+<h4 id="Definitions_State-Machine-Definitions_Dynamic-Semantics">5.10.3. Dynamic Semantics</h4>
+<div class="paragraph">
+<p>An internal state machine <em>M</em> has the following runtime behavior:</p>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p><em>M</em> maintains a current state <em>S</em>.
+The current state is undefined until initialization occurs.
+From that point on, the current state is always a leaf state.</p>
+</li>
+<li>
+<p><em>M</em> provides a function for initializing the state machine.
+It runs the
+<a href="#State-Machine-Behavior-Elements_Initial-Transition-Specifiers_Dynamic-Semantics">behavior associated with the initial transition specifier of <em>M</em></a>.</p>
+</li>
+<li>
+<p>For each signal <em>s</em>, <em>M</em> provides a function for sending <em>s</em>.
+This function has a typed argument with type <em>T</em> if and only if
+the <a href="#State-Machine-Behavior-Elements_Signal-Definitions">definition of signal <em>s</em></a>
+has type <em>T</em>.
+It runs the
+<a href="#State-Machine-Behavior-Elements_State-Transition-Specifiers_Dynamic-Semantics">behavior associated with <em>s</em> in the current state <em>S</em></a>.
+This behavior may cause one or more actions to be performed,
+and it may cause the current state to change.</p>
+</li>
+</ol>
+</div>
+<div class="paragraph">
+<p>The functions are called by the code that is generated when a
+state machine is <a href="#Specifiers_State-Machine-Instance-Specifiers">instantiated</a>
+as part of an active or queued component.</p>
+</div>
+</div>
 <div class="sect3">
-<h4 id="Definitions_State-Machine-Definitions_Examples">5.10.5. Examples</h4>
+<h4 id="Definitions_State-Machine-Definitions_Examples">5.10.4. Examples</h4>
 <div class="listingblock">
 <div class="content">
 <pre class="prettyprint highlight"><code data-lang="fpp">state machine MonitorSm {
 
-  signal Complete
-  signal Drive
-  signal Calibrate
-  signal RTI
-  signal Stop
-  signal Fault
-
-  action init2
   action doCalibrate
+  action init2
   action motorControl
   action reportFault
 
   guard calibrateReady
 
+  signal Calibrate
+  signal Complete
+  signal Drive
+  signal Fault
+  signal RTI
+  signal Stop
+
   initial enter DeviceOn
 
   state DeviceOn {
 
-    initial do init2 enter Initializing
+    initial do { init2 } enter Initializing
 
     state Initializing {
       on Complete enter Idle
@@ -3017,13 +3179,13 @@ <h4 id="Definitions_State-Machine-Definitions_Examples">5.10.5. Examples</h4>
     }
 
     state Calibrating {
-      on RTI do doCalibrate
-      on Fault do reportFault enter Idle
+      on RTI do { doCalibrate }
+      on Fault do { reportFault } enter Idle
       on Complete enter Idle
     }
 
     state Driving {
-      on RTI do motorControl
+      on RTI do { motorControl }
       on Stop enter Idle
     }
 
@@ -3769,68 +3931,55 @@ <h4 id="State-Machine-Behavior-Elements_Action-Definitions_Examples">6.1.3. Exam
 </div>
 </div>
 <div class="sect2">
-<h3 id="State-Machine-Behavior-Elements_Enter-Expressions">6.2. Enter Expressions</h3>
+<h3 id="State-Machine-Behavior-Elements_Do-Expressions">6.2. Do Expressions</h3>
 <div class="paragraph">
-<p>An <strong>enter expression</strong> specifies a transition as part of an
-<a href="#State-Machine-Behavior-Elements_Initial-Transition-Specifiers">initial transition</a>,
-a <a href="#State-Machine-Behavior-Elements_State-Transition-Specifiers">state transition</a>,
+<p>An <strong>do expression</strong> specifies a list of actions as part of an
+<a href="#State-Machine-Behavior-Elements_Initial-Transition-Specifiers">initial transition specifier</a>,
+a <a href="#State-Machine-Behavior-Elements_State-Transition-Specifiers">state transition specifier</a>,
+a <a href="#State-Machine-Behavior-Elements_State-Entry-Specifiers">state entry specifier</a>,
+a <a href="#State-Machine-Behavior-Elements_State-Exit-Specifiers">state exit specifier</a>,
 or
-a <a href="#State-Machine-Behavior-Elements_Junction-Definitions">junction</a>.
-The transition enters a state or junction and optionally performs
-some action.</p>
+a <a href="#State-Machine-Behavior-Elements_Junction-Definitions">junction definition</a>.</p>
 </div>
 <div class="sect3">
-<h4 id="State-Machine-Behavior-Elements_Enter-Expressions_Syntax">6.2.1. Syntax</h4>
+<h4 id="State-Machine-Behavior-Elements_Do-Expressions_Syntax">6.2.1. Syntax</h4>
 <div class="paragraph">
-<p><em>[</em>
-<code>do</code> <a href="#Lexical-Elements_Identifiers"><em>identifier</em></a>
-<em>]</em>
-<code>enter</code> <a href="#Scoping-of-Names_Qualified-Identifiers"><em>qual-ident</em></a></p>
+<p><code>do</code> <code>{</code> <em>action-sequence</em> <code>}</code></p>
+</div>
+<div class="paragraph">
+<p><em>action-sequence</em> is an
+<a href="#Element-Sequences">element sequence</a> in
+which each element is an <a href="#Lexical-Elements_Identifiers"><em>identifier</em></a>
+and the terminating punctuation is a comma.</p>
 </div>
 </div>
 <div class="sect3">
-<h4 id="State-Machine-Behavior-Elements_Enter-Expressions_Semantics">6.2.2. Semantics</h4>
-<div class="olist arabic">
-<ol class="arabic">
-<li>
-<p>If present, the optional identifier after the keyword <code>do</code> must
-<a href="#Definitions_State-Machine-Definitions_Scoping-of-Names">refer</a>
+<h4 id="State-Machine-Behavior-Elements_Do-Expressions_Semantics">6.2.2. Semantics</h4>
+<div class="paragraph">
+<p>Each identifier in the action sequence must
+<a href="#Definitions_State-Machine-Definitions_Static-Semantics_Scoping-of-Names">refer</a>
 to an
-<a href="#State-Machine-Behavior-Elements_Action-Definitions">action definition</a>.
-It specifies an action to perform when making the transition.</p>
-</li>
-<li>
-<p>The qualified identifier after the keyword <code>enter</code> must
-<a href="#Definitions_State-Machine-Definitions_Scoping-of-Names">refer</a>
-to a
-<a href="#State-Machine-Behavior-Elements_State-Definitions">state definition</a>
-or a
-<a href="#State-Machine-Behavior-Elements_Junction-Definitions">junction definition</a>
-It is the state or junction that is entered.</p>
-</li>
-</ol>
+<a href="#State-Machine-Behavior-Elements_Action-Definitions">action definition</a>.</p>
 </div>
 </div>
 <div class="sect3">
-<h4 id="State-Machine-Behavior-Elements_Enter-Expressions_Examples">6.2.3. Examples</h4>
+<h4 id="State-Machine-Behavior-Elements_Do-Expressions_Examples">6.2.3. Examples</h4>
 <div class="listingblock">
 <div class="content">
 <pre class="prettyprint highlight"><code data-lang="fpp">state machine Device {
 
-  signal PowerOn
-
-  action getReady
-
-  guard initComplete
+  action powerActuator
+  action powerGyro
+  action powerGimbal
 
-  initial enter OFF
-
-  state OFF {
-    on PowerOn if initComplete do getReady enter ON
+  state ON {
+    entry do {
+      powerActuator
+      powerGyro
+      powerGimbal
+    }
   }
 
-  state ON
-
 }</code></pre>
 </div>
 </div>
@@ -3920,25 +4069,47 @@ <h3 id="State-Machine-Behavior-Elements_Initial-Transition-Specifiers">6.4. Init
 <h4 id="State-Machine-Behavior-Elements_Initial-Transition-Specifiers_Syntax">6.4.1. Syntax</h4>
 <div class="paragraph">
 <p><code>initial</code>
-<a href="#State-Machine-Behavior-Elements_Enter-Expressions"><em>enter-expression</em></a></p>
+<a href="#State-Machine-Behavior-Elements_Transition-Expressions"><em>transition-expression</em></a></p>
 </div>
 </div>
 <div class="sect3">
-<h4 id="State-Machine-Behavior-Elements_Initial-Transition-Specifiers_Semantics">6.4.2. Semantics</h4>
+<h4 id="State-Machine-Behavior-Elements_Initial-Transition-Specifiers_Static-Semantics">6.4.2. Static Semantics</h4>
 <div class="paragraph">
 <p>The state definition or junction definition referred to in the
-enter expression must be a member of the same
+transition expression must <strong>lead to a member</strong> of the same
 state machine definition or state definition in which the initial
 transition specifier appears.</p>
 </div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>A state definition <em>D</em> leads to a member of a state machine definition <em>M</em>
+(respectively a state <em>S</em>) if <em>D</em> is a member of <em>M</em> (respectively <em>S</em>).</p>
+</li>
+<li>
+<p>A junction definition <em>D</em> leads to a member of a state machine definition <em>M</em>
+(respectively as state <em>S</em>) if it is a member of <em>M</em> (respectively <em>S</em>)
+and the state or junction definitions referred to in <em>D</em> lead to members of
+<em>M</em> (respectively <em>S</em>).</p>
+</li>
+</ol>
+</div>
+</div>
+<div class="sect3">
+<h4 id="State-Machine-Behavior-Elements_Initial-Transition-Specifiers_Dynamic-Semantics">6.4.3. Dynamic Semantics</h4>
+<div class="paragraph">
+<p>To run an initial transition specifier <em>I</em> with transition expression <em>E</em>,
+we <a href="#State-Machine-Behavior-Elements_Transition-Expressions_Dynamic-Semantics">run <em>E</em> in the context of <em>I</em></a>.</p>
+</div>
 </div>
 <div class="sect3">
-<h4 id="State-Machine-Behavior-Elements_Initial-Transition-Specifiers_Examples">6.4.3. Examples</h4>
+<h4 id="State-Machine-Behavior-Elements_Initial-Transition-Specifiers_Examples">6.4.4. Examples</h4>
 <div class="listingblock">
 <div class="content">
 <pre class="prettyprint highlight"><code data-lang="fpp">state machine Device {
 
-  action initDevices
+  action initDev1
+  action initDev2
 
   # When the state machine starts up, enter the ON state
   initial enter ON
@@ -3946,7 +4117,11 @@ <h4 id="State-Machine-Behavior-Elements_Initial-Transition-Specifiers_Examples">
   state ON {
 
     # When entering the ON state, enter the POWERING_UP substate
-    initial do initDevices enter POWERING_UP
+    initial do {
+      initDev1
+      initDev2
+    } \
+    enter POWERING_UP
 
     state POWERING_UP
 
@@ -3972,13 +4147,13 @@ <h4 id="State-Machine-Behavior-Elements_Junction-Definitions_Syntax">6.5.1. Synt
 <div class="paragraph">
 <p><code>junction</code> <a href="#Lexical-Elements_Identifiers"><em>identifier</em></a>
 <code>{</code>
-<code>if</code> <a href="#Lexical-Elements_Identifiers"><em>identifier</em></a> <a href="#State-Machine-Behavior-Elements_Enter-Expressions"><em>enter-expression</em></a>
-<code>else</code> <a href="#State-Machine-Behavior-Elements_Enter-Expressions"><em>enter-expression</em></a>
+<code>if</code> <a href="#Lexical-Elements_Identifiers"><em>identifier</em></a> <a href="#State-Machine-Behavior-Elements_Transition-Expressions"><em>transition-expression</em></a>
+<code>else</code> <a href="#State-Machine-Behavior-Elements_Transition-Expressions"><em>transition-expression</em></a>
 <code>}</code></p>
 </div>
 </div>
 <div class="sect3">
-<h4 id="State-Machine-Behavior-Elements_Junction-Definitions_Semantics">6.5.2. Semantics</h4>
+<h4 id="State-Machine-Behavior-Elements_Junction-Definitions_Static-Semantics">6.5.2. Static Semantics</h4>
 <div class="olist arabic">
 <ol class="arabic">
 <li>
@@ -3986,21 +4161,47 @@ <h4 id="State-Machine-Behavior-Elements_Junction-Definitions_Semantics">6.5.2. S
 </li>
 <li>
 <p>The identifier after the keyword <code>if</code> must
-<a href="#Definitions_State-Machine-Definitions_Scoping-of-Names">refer</a>
+<a href="#Definitions_State-Machine-Definitions_Static-Semantics_Scoping-of-Names">refer</a>
 to a
 <a href="#State-Machine-Behavior-Elements_Guard-Definitions">guard definition</a>.
 It specifies the guard that controls the branch.</p>
 </li>
 <li>
-<p>Each of the enter expressions must be valid.
-The first enter expression is run if the guard evaluates to <code>true</code>;
-otherwise the second enter expression is run.</p>
+<p>Each of the transition expressions must be valid.
+The first transition expression is run if the guard evaluates to <code>true</code>;
+otherwise the second transition expression is run.</p>
 </li>
 </ol>
 </div>
 </div>
 <div class="sect3">
-<h4 id="State-Machine-Behavior-Elements_Junction-Definitions_Examples">6.5.3. Examples</h4>
+<h4 id="State-Machine-Behavior-Elements_Junction-Definitions_Dynamic-Semantics">6.5.3. Dynamic Semantics</h4>
+<div class="paragraph">
+<p>Each junction <em>J</em> has the following <strong>entry behavior</strong>:</p>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>Evaluate the guard of <em>J</em>.</p>
+</li>
+<li>
+<p>If <em>J</em> evaluates to <code>true</code>, then
+<a href="#State-Machine-Behavior-Elements_Transition-Expressions_Dynamic-Semantics">run the <code>if</code> transition expression in the context of <em>J</em></a>.</p>
+</li>
+<li>
+<p>Otherwise run the <code>else</code> transition expression in the context of <em>J</em>.</p>
+</li>
+</ol>
+</div>
+<div class="paragraph">
+<p>If any of the guard or the transition expressions requires a typed argument
+<em>v</em>, then according to the static semantics, <em>v</em> must be available,
+and it must have a compatible type.
+Use <em>v</em> to evaluate the guard or run the transition expression.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="State-Machine-Behavior-Elements_Junction-Definitions_Examples">6.5.4. Examples</h4>
 <div class="listingblock">
 <div class="content">
 <pre class="prettyprint highlight"><code data-lang="fpp">state machine Device {
@@ -4012,7 +4213,7 @@ <h4 id="State-Machine-Behavior-Elements_Junction-Definitions_Examples">6.5.3. Ex
 
   junction J1 {
     if coldStart enter OFF \
-    else do initPower enter ON
+    else do { initPower } enter ON
   }
 
   state OFF
@@ -4136,11 +4337,17 @@ <h4 id="State-Machine-Behavior-Elements_State-Definitions_Syntax">6.7.1. Syntax<
 <li>
 <p>A <a href="#State-Machine-Behavior-Elements_State-Transition-Specifiers">state transition specifier</a></p>
 </li>
+<li>
+<p>A <a href="#State-Machine-Behavior-Elements_State-Entry-Specifiers">state entry specifier</a></p>
+</li>
+<li>
+<p>A <a href="#State-Machine-Behavior-Elements_State-Exit-Specifiers">state exit specifier</a></p>
+</li>
 </ul>
 </div>
 </div>
 <div class="sect3">
-<h4 id="State-Machine-Behavior-Elements_State-Definitions_Semantics">6.7.2. Semantics</h4>
+<h4 id="State-Machine-Behavior-Elements_State-Definitions_Static-Semantics">6.7.2. Static Semantics</h4>
 <div class="olist arabic">
 <ol class="arabic">
 <li>
@@ -4152,65 +4359,124 @@ <h4 id="State-Machine-Behavior-Elements_State-Definitions_Semantics">6.7.2. Sema
 <div class="olist loweralpha">
 <ol class="loweralpha" type="a">
 <li>
-<p><em>M</em> must contain exactly one initial transition specifier <em>I</em>.
+<p>If <em>M</em> contains at least one state definition, then <em>M</em> must contain exactly
+one initial transition specifier <em>I</em>.
 <em>I</em> specifies the sub-state to enter on entry to the outer state.</p>
 </li>
 <li>
+<p><em>M</em> may not contain more than one state entry specifier.
+If <em>M</em> has a state entry specifier <em>S</em>, then the <strong>entry actions</strong> of
+<em>M</em> are the actions specified in <em>S</em>, in the order specified.
+Otherwise <em>M</em> has no entry actions.</p>
+</li>
+<li>
+<p><em>M</em> may not contain more than one state exit specifier.
+If <em>M</em> has a state exit specifier <em>S</em>, then the <strong>exit actions</strong> of
+<em>M</em> are the actions specified in <em>S</em>, in the order specified.
+Otherwise <em>M</em> has no exit actions.</p>
+</li>
+<li>
 <p>No two <a href="#State-Machine-Behavior-Elements_State-Transition-Specifiers">state
 transition specifiers</a> that are members of <em>M</em> may
-<a href="#Definitions_State-Machine-Definitions_Scoping-of-Names">refer</a> to the same
+<a href="#Definitions_State-Machine-Definitions_Static-Semantics_Scoping-of-Names">refer</a> to the same
 signal definition.</p>
 </li>
 </ol>
 </div>
 </li>
+<li>
+<p>If the state definition member sequence <em>M</em> is present and <em>M</em>
+contains at least one state definition, then the
+state definition is called an <strong>inner state definition</strong>.
+Otherwise it is called a <strong>leaf state definition</strong>.</p>
+</li>
+</ol>
+</div>
+</div>
+<div class="sect3">
+<h4 id="State-Machine-Behavior-Elements_State-Definitions_Dynamic-Semantics">6.7.3. Dynamic Semantics</h4>
+<div class="paragraph">
+<p>Each state definition <em>S</em> has the following <strong>entry behavior</strong>:</p>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>Run the entry actions, if any, of <em>S</em>.
+According to the static semantics, the entry actions must
+not require a typed argument.</p>
+</li>
+<li>
+<p>If <em>S</em> is an inner state, then run the
+<a href="#State-Machine-Behavior-Elements_Initial-Transition-Specifiers_Dynamic-Semantics">behavior</a> of the initial transition of <em>S</em>.</p>
+</li>
+<li>
+<p>Otherwise set the current state of the state machine to <em>S</em>.</p>
+</li>
 </ol>
 </div>
 </div>
 <div class="sect3">
-<h4 id="State-Machine-Behavior-Elements_State-Definitions_Examples">6.7.3. Examples</h4>
+<h4 id="State-Machine-Behavior-Elements_State-Definitions_Examples">6.7.4. Examples</h4>
 <div class="listingblock">
 <div class="content">
 <pre class="prettyprint highlight"><code data-lang="fpp">state machine MonitorSm {
 
-  signal Complete
-  signal Drive
-  signal Calibrate
-  signal RTI
-  signal Stop
-  signal Fault
-
-  action init2
   action doCalibrate
+  action heaterOff
+  action heaterOn
+  action init1
+  action init2
+  action monitorOff
+  action monitorOn
   action motorControl
   action reportFault
+  action stopMotor
 
   guard calibrateReady
 
+  signal Calibrate
+  signal Complete
+  signal Drive
+  signal Fault
+  signal RTI
+  signal Stop
+
   initial enter DEVICE_ON
 
   state DEVICE_ON {
 
-    initial do init2 enter INITIALIZING
+    initial do {
+      init1
+      init2
+     } \
+     enter INITIALIZING
 
     state INITIALIZING {
       on Complete enter IDLE
     }
 
     state IDLE {
+      entry do {
+        heaterOff
+        monitorOff
+      }
+      exit do {
+        heaterOn
+        monitorOn
+      }
       on Drive enter DRIVING
       on Calibrate if calibrateReady enter CALIBRATING
     }
 
     state CALIBRATING {
-      on RTI do doCalibrate
-      on Fault do reportFault enter Idle
+      on RTI do { doCalibrate }
+      on Fault do { reportFault } enter Idle
       on Complete enter IDLE
     }
 
     state DRIVING {
-      on RTI do motorControl
-      on Stop enter IDLE
+      on RTI do { motorControl }
+      on Stop do { stopMotor } enter IDLE
     }
 
   }
@@ -4221,98 +4487,408 @@ <h4 id="State-Machine-Behavior-Elements_State-Definitions_Examples">6.7.3. Examp
 </div>
 </div>
 <div class="sect2">
-<h3 id="State-Machine-Behavior-Elements_State-Transition-Specifiers">6.8. State Transition Specifiers</h3>
+<h3 id="State-Machine-Behavior-Elements_State-Entry-Specifiers">6.8. State Entry Specifiers</h3>
+<div class="paragraph">
+<p>A <strong>state entry specifier</strong> is part of a
+<a href="#State-Machine-Behavior-Elements_State-Definitions">state definition</a>.
+It specifies the actions to take when entering the state.</p>
+</div>
+<div class="sect3">
+<h4 id="State-Machine-Behavior-Elements_State-Entry-Specifiers_Syntax">6.8.1. Syntax</h4>
+<div class="paragraph">
+<p><code>entry</code> <a href="#State-Machine-Behavior-Elements_Do-Expressions"><em>do-expression</em></a></p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="State-Machine-Behavior-Elements_State-Entry-Specifiers_Semantics">6.8.2. Semantics</h4>
+<div class="paragraph">
+<p>The do expression must be valid.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="State-Machine-Behavior-Elements_State-Entry-Specifiers_Examples">6.8.3. Examples</h4>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code data-lang="fpp">state machine Device {
+
+  action heaterOn
+  action monitorOn
+
+  state RUNNING {
+    entry do {
+      heaterOn
+      monitorOn
+    }
+
+  }
+
+}</code></pre>
+</div>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="State-Machine-Behavior-Elements_State-Exit-Specifiers">6.9. State Exit Specifiers</h3>
+<div class="paragraph">
+<p>A <strong>state exit specifier</strong> is part of a
+<a href="#State-Machine-Behavior-Elements_State-Definitions">state definition</a>.
+It specifies the actions to take when exiting the state.</p>
+</div>
+<div class="sect3">
+<h4 id="State-Machine-Behavior-Elements_State-Exit-Specifiers_Syntax">6.9.1. Syntax</h4>
+<div class="paragraph">
+<p><code>exit</code> <a href="#State-Machine-Behavior-Elements_Do-Expressions"><em>do-expression</em></a></p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="State-Machine-Behavior-Elements_State-Exit-Specifiers_Semantics">6.9.2. Semantics</h4>
+<div class="paragraph">
+<p>The do expression must be valid.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="State-Machine-Behavior-Elements_State-Exit-Specifiers_Examples">6.9.3. Examples</h4>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code data-lang="fpp">state machine Device {
+
+  action heaterOff
+  action monitorOff
+
+  state RUNNING {
+    exit do {
+      heaterOff
+      monitorOff
+    }
+
+  }
+
+}</code></pre>
+</div>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="State-Machine-Behavior-Elements_State-Transition-Specifiers">6.10. State Transition Specifiers</h3>
 <div class="paragraph">
 <p>A <strong>state transition specifier</strong> is part of a
 <a href="#State-Machine-Behavior-Elements_State-Definitions">state definition</a>.
 It specifies a transition from the state in which it appears.</p>
 </div>
 <div class="sect3">
-<h4 id="State-Machine-Behavior-Elements_State-Transition-Specifiers_Syntax">6.8.1. Syntax</h4>
+<h4 id="State-Machine-Behavior-Elements_State-Transition-Specifiers_Syntax">6.10.1. Syntax</h4>
 <div class="paragraph">
 <p><code>on</code> <a href="#Lexical-Elements_Identifiers"><em>identifier</em></a>
 <em>[</em>
 <code>if</code> <a href="#Lexical-Elements_Identifiers"><em>identifier</em></a>
 <em>]</em>
-<em>enter-or-do</em></p>
+<em>transition-or-do</em></p>
 </div>
 <div class="paragraph">
-<p><em>enter-or-do</em> is one of the following:</p>
+<p><em>transition-or-do</em> is one of the following:</p>
 </div>
 <div class="olist arabic">
 <ol class="arabic">
 <li>
-<p><a href="#State-Machine-Behavior-Elements_Enter-Expressions"><em>enter-expression</em></a></p>
+<p><a href="#State-Machine-Behavior-Elements_Transition-Expressions"><em>transition-expression</em></a></p>
 </li>
 <li>
-<p><code>do</code> <a href="#Lexical-Elements_Identifiers"><em>identifier</em></a></p>
+<p><a href="#State-Machine-Behavior-Elements_Do-Expressions"><em>do-expression</em></a></p>
 </li>
 </ol>
 </div>
 </div>
 <div class="sect3">
-<h4 id="State-Machine-Behavior-Elements_State-Transition-Specifiers_Semantics">6.8.2. Semantics</h4>
+<h4 id="State-Machine-Behavior-Elements_State-Transition-Specifiers_Static-Semantics">6.10.2. Static Semantics</h4>
 <div class="olist arabic">
 <ol class="arabic">
 <li>
 <p>The identifier after the keyword <code>on</code> must
-<a href="#Definitions_State-Machine-Definitions_Scoping-of-Names">refer</a>
+<a href="#Definitions_State-Machine-Definitions_Static-Semantics_Scoping-of-Names">refer</a>
 to a
 <a href="#State-Machine-Behavior-Elements_Signal-Definitions">signal definition</a>.
 It names the signal that causes the transition to occur.</p>
 </li>
 <li>
 <p>If present, the optional identifier after the keyword <code>if</code> must
-<a href="#Definitions_State-Machine-Definitions_Scoping-of-Names">refer</a>
+<a href="#Definitions_State-Machine-Definitions_Static-Semantics_Scoping-of-Names">refer</a>
 to a
 <a href="#State-Machine-Behavior-Elements_Guard-Definitions">guard definition</a>.
 It specifies a guard for the transition.</p>
 </li>
 <li>
-<p>The first form of the syntax specifies a target state and an optional action.
-The enter expression must be valid.
-The target state in the enter expression may be the same as the
-enclosing state; in this case the transition is called a <strong>self transition</strong>.
-When making a self transition, the state machine runs the code associated with
-exiting and then re-entering the state.</p>
+<p>The first form of the <em>transition-or-do</em> syntax specifies an <strong>external
+transition</strong>, i.e., an optional list of actions and a target state or junction.</p>
 </li>
 <li>
-<p>Second form of the syntax specifies an
-<strong>internal transition</strong>, i.e., an action to take while remaining
+<p>The second form of the <em>transition-or-do</em> syntax specifies an
+<strong>internal transition</strong>, i.e., a list of actions to take while remaining
 in the same state.
-When making an internal transition, the exit and re-entry code is not run.
-The identifier after the keyword <code>do</code> must
-<a href="#Definitions_State-Machine-Definitions_Scoping-of-Names">refer</a>
-to an
-<a href="#State-Machine-Behavior-Elements_Action-Definitions">action definition</a>.</p>
+The do expression must be valid.</p>
+</li>
+</ol>
+</div>
+</div>
+<div class="sect3">
+<h4 id="State-Machine-Behavior-Elements_State-Transition-Specifiers_The-State-Transition-Map">6.10.3. The State Transition Map</h4>
+<div class="paragraph">
+<p>The set of all state transition specifiers in a state machine
+induces a <strong>state transition map</strong> <em>m: Signal x State &#8594; GuardedTransition</em>,
+where a guarded transition is a pair consisting of an optional guard
+and a transition or do expression.
+The map <em>m</em> is constructed as follows.
+Let <em>T</em> be a state transition specifier with signal <em>s</em>, optional guard <em>g</em>,
+and transition or do expression <em>t</em>, defined in state <em>S</em>.</p>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>If <em>S</em> is a leaf state, then <em>m</em> maps <em>(s, S)</em> to <em>(g, t)</em>.</p>
+</li>
+<li>
+<p>Otherwise, for each leaf state <em>S<sub>i</sub></em> that is transitively
+contained in <em>S</em>, <em>m</em> maps <em>(s, S<sub>i</sub>)</em> to <em>(g, t)</em>, unless
+the mapping is overridden.
+Overriding occurs when another state <em>S'</em> that is transitively contained in <em>S</em>
+maps <em>(s, S<sub>i</sub>)</em> to <em>(g',t')</em> according to items (1) or (2).
+In that case, the mapping lower in the hierarchy takes precedence.
+This overriding behavior is called <strong>behavioral polymorphism</strong>.</p>
 </li>
 </ol>
 </div>
 </div>
 <div class="sect3">
-<h4 id="State-Machine-Behavior-Elements_State-Transition-Specifiers_Examples">6.8.3. Examples</h4>
+<h4 id="State-Machine-Behavior-Elements_State-Transition-Specifiers_Dynamic-Semantics">6.10.4. Dynamic Semantics</h4>
+<div class="paragraph">
+<p>Let <em>M</em> be a state machine.
+Suppose <em>M</em> is in state <em>S</em>.
+Let <em>m</em> be the state transition map of <em>M</em>, defined in the previous section.
+Let <em>s</em> be a signal of <em>M</em>.
+<strong>Sending</strong> signal <em>s</em> to <em>M</em> results in the following behavior:</p>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>If <em>(s,S)</em> is not in the domain of <em>m</em>, then do nothing.</p>
+</li>
+<li>
+<p>Otherwise</p>
+<div class="olist loweralpha">
+<ol class="loweralpha" type="a">
+<li>
+<p>Let <em>(g,t) =  m(s,S)</em>.</p>
+</li>
+<li>
+<p>Evaluate the guard <em>g</em>.
+If the result is <code>false</code>, then do nothing.
+Otherwise</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>If <em>t</em> is a do expression <em>E</em>, then perform the actions
+listed in <em>E</em>, if any, in the order listed.</p>
+</li>
+<li>
+<p>Otherwise <em>t</em> is a transition expression <em>E</em>.
+<a href="#State-Machine-Behavior-Elements_Transition-Expressions_Dynamic-Semantics">Run <em>E</em> in the context of <em>S</em></a>.</p>
+</li>
+</ol>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ol>
+</div>
+<div class="paragraph">
+<p>If any of the guard, do expression, or transition expression requires a
+typed argument <em>v</em>, then according to the static semantics, <em>v</em> must
+be available, and it must have a compatible type.
+Use <em>v</em> to evaluate the guard, run the do expression, or run
+the transition expression.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="State-Machine-Behavior-Elements_State-Transition-Specifiers_Examples">6.10.5. Examples</h4>
 <div class="listingblock">
 <div class="content">
 <pre class="prettyprint highlight"><code data-lang="fpp">state machine Device {
 
-  signal RTI
-  signal PowerOn
-
   action performStuff
-  action getReady
+  action powerHeater
+  action powerSensor
 
   guard initComplete
 
+  signal PowerOn
+  signal RTI
+
   initial enter OFF
 
   state OFF {
-    on PowerOn if initComplete do getReady enter ON
+    on PowerOn if initComplete do {
+      powerHeater
+      powerSensor
+    } \
+    enter ON
   }
 
   state ON {
-    on RTI do performStuff
+    on RTI do { performStuff }
   }
 
+}</code></pre>
+</div>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="State-Machine-Behavior-Elements_Transition-Expressions">6.11. Transition Expressions</h3>
+<div class="paragraph">
+<p>An <strong>transition expression</strong> specifies a transition as part of an
+<a href="#State-Machine-Behavior-Elements_Initial-Transition-Specifiers">initial transition</a>,
+a <a href="#State-Machine-Behavior-Elements_State-Transition-Specifiers">state transition</a>,
+or
+a <a href="#State-Machine-Behavior-Elements_Junction-Definitions">junction</a>.
+The transition performs zero or more actions and then
+enters a state or junction.</p>
+</div>
+<div class="sect3">
+<h4 id="State-Machine-Behavior-Elements_Transition-Expressions_Syntax">6.11.1. Syntax</h4>
+<div class="paragraph">
+<p><em>[</em>
+<a href="#State-Machine-Behavior-Elements_Do-Expressions"><em>do-expression</em></a>
+<em>]</em>
+<code>enter</code> <a href="#Scoping-of-Names_Qualified-Identifiers"><em>qual-ident</em></a></p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="State-Machine-Behavior-Elements_Transition-Expressions_Static-Semantics">6.11.2. Static Semantics</h4>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The do expression specifies the list of actions to be
+performed when making the transition.
+If there are no actions, the do expression may be omitted.</p>
+</li>
+<li>
+<p>The qualified identifier after the keyword <code>enter</code> must
+<a href="#Definitions_State-Machine-Definitions_Static-Semantics_Scoping-of-Names">refer</a>
+to a
+<a href="#State-Machine-Behavior-Elements_State-Definitions">state definition</a>
+or a
+<a href="#State-Machine-Behavior-Elements_Junction-Definitions">junction definition</a>
+It is the state or junction that is entered in the transition.</p>
+</li>
+</ol>
+</div>
+</div>
+<div class="sect3">
+<h4 id="State-Machine-Behavior-Elements_Transition-Expressions_Dynamic-Semantics">6.11.3. Dynamic Semantics</h4>
+<div class="paragraph">
+<p>A transition expression <em>E</em> is run in the context of an
+initial transition specifier, a leaf state definition,
+or a junction definition.</p>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>To run <em>E</em> in the context of an initial transition specifier
+<em>I</em>, do the following:</p>
+<div class="olist loweralpha">
+<ol class="loweralpha" type="a">
+<li>
+<p>Perform the actions, if any, specified in <em>E</em>, in the order specified.</p>
+</li>
+<li>
+<p>Run the entry behavior of the
+<a href="#State-Machine-Behavior-Elements_State-Definitions_Dynamic-Semantics">state</a>
+or
+<a href="#State-Machine-Behavior-Elements_Junction-Definitions_Dynamic-Semantics">junction</a>
+referred to in <em>E</em>.</p>
+</li>
+</ol>
+</div>
+<div class="paragraph">
+<p>According to the static semantics, actions and the entry behavior must not require
+a typed argument.</p>
+</div>
+</li>
+<li>
+<p>To run <em>E</em> in the context of a leaf state definition or junction definition <em>D</em>,
+do the following:</p>
+<div class="olist loweralpha">
+<ol class="loweralpha" type="a">
+<li>
+<p>Let <em>T</em> be the state or junction which is the target of <em>E</em>.</p>
+</li>
+<li>
+<p>Let <em>P</em> be the <strong>lowest common ancestor</strong> of <em>D</em> and <em>T</em>.
+The lowest common ancestor is defined as follows:</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>A <strong>point in the state hierarchy</strong> is either the entire state machine
+or a state definition.</p>
+</li>
+<li>
+<p>The lowest common ancestor of <em>D</em> and <em>T</em> is the lowest
+point in the state hierarchy such that (A)
+by descending from <em>P</em> at least once it is possible to reach <em>D</em> and (B)
+by descending from <em>P</em> at least once it is possible to reach <em>T</em>.</p>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>Ascend through the state hierarchy from <em>D</em> to <em>P</em>.
+When passing out of a state <em>S</em>, perform the
+<a href="#State-Machine-Behavior-Elements_State-Definitions_Static-Semantics">exit actions</a> of <em>S</em>, in the order specified.</p>
+</li>
+<li>
+<p>Perform the actions, if any, specified in <em>E</em>, in the order specified.</p>
+</li>
+<li>
+<p>Descend through the state hierarchy from <em>P</em> to the point just above <em>T</em>.
+When passing into a state <em>S</em>, perform the
+<a href="#State-Machine-Behavior-Elements_State-Definitions_Static-Semantics">entry actions</a> of <em>S</em>, in the order specified.</p>
+</li>
+<li>
+<p>Run the entry behavior of the
+<a href="#State-Machine-Behavior-Elements_State-Definitions_Dynamic-Semantics">state</a>
+or
+<a href="#State-Machine-Behavior-Elements_Junction-Definitions_Dynamic-Semantics">junction</a>
+<em>T</em>.</p>
+</li>
+</ol>
+</div>
+<div class="paragraph">
+<p>According to the static semantics, if any of the actions or the
+entry behavior requires a typed argument <em>v</em>, then <em>v</em> must
+be available, and it must have a compatible type.
+Use <em>v</em> to call the action or run the behavior.</p>
+</div>
+</li>
+</ol>
+</div>
+</div>
+<div class="sect3">
+<h4 id="State-Machine-Behavior-Elements_Transition-Expressions_Examples">6.11.4. Examples</h4>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code data-lang="fpp">state machine Device {
+
+  action initDev1
+  action initDev2
+
+  initial do {
+    initDev1
+    initDev2
+  } \
+  enter OFF
+
+  state OFF
+
 }</code></pre>
 </div>
 </div>
@@ -6209,7 +6785,7 @@ <h4 id="Specifiers_State-Machine-Instance-Specifiers_Syntax">7.14.1. Syntax</h4>
 </div>
 </div>
 <div class="sect3">
-<h4 id="Specifiers_State-Machine-Instance-Specifiers_Semantics">7.14.2. Semantics</h4>
+<h4 id="Specifiers_State-Machine-Instance-Specifiers_Static-Semantics">7.14.2. Static Semantics</h4>
 <div class="olist arabic">
 <ol class="arabic">
 <li>
@@ -6230,7 +6806,35 @@ <h4 id="Specifiers_State-Machine-Instance-Specifiers_Semantics">7.14.2. Semantic
 </div>
 </div>
 <div class="sect3">
-<h4 id="Specifiers_State-Machine-Instance-Specifiers_Examples">7.14.3. Examples</h4>
+<h4 id="Specifiers_State-Machine-Instance-Specifiers_Dynamic-Semantics">7.14.3. Dynamic Semantics</h4>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>Specifying one or more instances of a state machine <em>M</em> in a component <em>C</em>
+causes the following code to be generated as part of <em>C</em>:</p>
+<div class="olist loweralpha">
+<ol class="loweralpha" type="a">
+<li>
+<p>Pure virtual functions corresponding to the actions and guards of <em>M</em>.</p>
+</li>
+<li>
+<p>For each signal <em>s</em> of <em>M</em>, a function for sending <em>s</em> to <em>M</em>.
+The signal function may or may not have a typed argument, depending
+on the definition of <em>s</em>.
+The signal and the argument, if any, are serialized on the component
+queue and dispatched from the queue in the ordinary way for
+an F Prime active or queued component.
+Upon dispatching a signal, the signal and argument, if any,
+are used to call the <a href="#Definitions_State-Machine-Definitions_Dynamic-Semantics">function for sending <em>s</em> to <em>M</em></a>.</p>
+</li>
+</ol>
+</div>
+</li>
+</ol>
+</div>
+</div>
+<div class="sect3">
+<h4 id="Specifiers_State-Machine-Instance-Specifiers_Examples">7.14.4. Examples</h4>
 <div class="listingblock">
 <div class="content">
 <pre class="prettyprint highlight"><code data-lang="fpp">state machine M {
@@ -8372,7 +8976,9 @@ <h3 id="Types_Primitive-Integer-Types">17.1. Primitive Integer Types</h3>
 <div class="paragraph">
 <p>The <strong>primitive integer types</strong> correspond to the
 <a href="#Type-Names_Primitive-Integer-Type-Names">primitive integer type names</a>
-and are written in the same way, e.g., <code>U32</code>.</p>
+and are written in the same way, e.g., <code>U32</code>.
+The primitive integer types whose names start with <code>I</code> are <strong>signed</strong>.
+The primitive integer types whose names start with <code>U</code> are <strong>unsigned</strong>.</p>
 </div>
 </div>
 <div class="sect2">
@@ -9183,24 +9789,160 @@ <h4 id="Type-Checking_Computing-a-Common-Type_Lists-of-Types">18.14.2. Lists of
 <p>Check that \$n &gt; 0\$. If not, then throw an error.</p>
 </li>
 <li>
-<p>Compute the type \$T_1\$ of \$e_1\$.</p>
+<p>Let \$T'_1\$ be \$T_1\$.</p>
+</li>
+<li>
+<p>For each \$i in [2,n\$], compute the
+<a href="#Type-Options_Computing-a-Common-Type-Option">common type option</a> \$T'_i\$ of \$T'_(i-1)\$ and \$T_i\$.</p>
+</li>
+<li>
+<p>Use \$T'_n\$ as the common type option of the list.</p>
+</li>
+</ol>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="Type-Options">19. Type Options</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>A <strong>type option</strong> is one of the following:</p>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p><em>Some</em> \$T\$, representing a value of type \$T\$.</p>
+</li>
+<li>
+<p><em>None</em>, representing no value.</p>
+</li>
+</ol>
+</div>
+<div class="paragraph">
+<p>Type options are used to specify the optional types associated with
+signals, actions, and guards in <a href="#Definitions_State-Machine-Definitions">state
+machine definitions</a>.</p>
+</div>
+<div class="sect2">
+<h3 id="Type-Options_Conversion-of-Type-Options">19.1. Conversion of Type Options</h3>
+<div class="paragraph">
+<p>We say that a type option \$O_1\$ <strong>may be converted to</strong> another type option
+\$O_2\$ in the following cases.</p>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>Any type option may be converted to <em>None</em>.</p>
 </li>
 <li>
-<p>For each \$i in [2,n\$]</p>
+<p><em>Some</em> \$T_1\$ may be converted to <em>Some</em> \$T_2\$ in the following cases:</p>
 <div class="olist loweralpha">
 <ol class="loweralpha" type="a">
 <li>
-<p>Compute the type \$T\$ of \$e_i\$.</p>
+<p>\$T_1\$ and \$T_2\$ are <a href="#Type-Checking_Identical-Types">identical types</a>.</p>
+</li>
+<li>
+<p>\$T_1\$ and \$T_2\$ are both
+<a href="#Types_Primitive-Integer-Types">signed primitive integer types</a>,
+and \$T_2\$ is at least as wide as \$T_1\$.</p>
+</li>
+<li>
+<p>\$T_1\$ and \$T_2\$ are both
+<a href="#Types_Primitive-Integer-Types">unsigned primitive integer types</a>,
+and \$T_2\$ is at least as wide as \$T_1\$.</p>
+</li>
+<li>
+<p>\$T_1\$ and \$T_2\$ are both
+<a href="#Types_Floating-Point-Types">floating-point types</a>,
+and \$T_2\$ is at least as wide as \$T_1\$.</p>
 </li>
 <li>
-<p>Compute the <a href="#Type-Checking_Computing-a-Common-Type">common type</a>
-\$T_i\$ of \$T_(i-1)\$ and \$T\$.</p>
+<p>\$T_1\$ and \$T_2\$ are both <a href="#Types_String-Types">string types</a>.</p>
+</li>
+</ol>
+</div>
 </li>
 </ol>
 </div>
+</div>
+<div class="sect2">
+<h3 id="Type-Options_Computing-a-Common-Type-Option">19.2. Computing a Common Type Option</h3>
+<div class="sect3">
+<h4 id="Type-Options_Computing-a-Common-Type-Option_Pairs-of-Type-Options">19.2.1. Pairs of Type Options</h4>
+<div class="paragraph">
+<p>Here are the rules for resolving two type options \$O_1\$ and \$O_2\$ to
+a common type option \$O\$:</p>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>If either or both of \$O_1\$ and \$O_2\$ is <em>None</em>, then
+let \$O\$ be <em>None</em>.</p>
+</li>
+<li>
+<p>Otherwise let \$O_1\$ be <em>Some</em> \$T_1\$, and let
+\$O_2\$ be <em>Some</em> \$T_2\$.
+Let \$O\$ be <em>Some</em> \$T\$, where \$T\$
+is computed as follows:</p>
+<div class="olist loweralpha">
+<ol class="loweralpha" type="a">
+<li>
+<p>If \$T_1\$ and \$T_2\$ are <a href="#Type-Checking_Identical-Types">identical types</a>,
+then let \$T\$ be \$T_1\$.</p>
+</li>
+<li>
+<p>Otherwise if \$T_1\$ and \$T_2\$ are both
+<a href="#Types_Primitive-Integer-Types">signed primitive integer types</a>,
+then let \$T\$ be the wider of the two types.</p>
+</li>
+<li>
+<p>Otherwise if \$T_1\$ and \$T_2\$ are both
+<a href="#Types_Primitive-Integer-Types">unsigned primitive integer types</a>,
+then let \$T\$ be the wider of the two types.</p>
+</li>
+<li>
+<p>Otherwise if \$T_1\$ and \$T_2\$ are both
+<a href="#Types_Floating-Point-Types">floating-point types</a>,
+then let \$T\$ be the wider of the two types.</p>
+</li>
+<li>
+<p>Otherwise if \$T_1\$ and \$T_2\$ are both
+<a href="#Types_String-Types">string types</a>, then
+then let \$T\$ be <code>string</code>.</p>
+</li>
+<li>
+<p>Otherwise the attempted resolution is invalid.
+Throw an error.</p>
+</li>
+</ol>
+</div>
+</li>
+</ol>
+</div>
+</div>
+<div class="sect3">
+<h4 id="Type-Options_Computing-a-Common-Type-Option_Lists-of-Type-Options">19.2.2. Lists of Type Options</h4>
+<div class="paragraph">
+<p>To compute a common type for a list of type options
+\$O_1, ... , O_n\$, do the following:</p>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>Check that \$n &gt; 0\$. If not, then throw an error.</p>
+</li>
+<li>
+<p>Let \$O'_1\$ be \$O_1\$.</p>
+</li>
+<li>
+<p>For each \$i in [2,n\$], compute the
+<a href="#Type-Checking_Computing-a-Common-Type">common type</a> \$O'_i\$ of
+\$O'_(i-1)\$ and \$O_i\$.</p>
 </li>
 <li>
-<p>Use \$T_n\$ as the common type of the list.</p>
+<p>Use \$O'_n\$ as the common type of the list.</p>
 </li>
 </ol>
 </div>
@@ -9209,7 +9951,7 @@ <h4 id="Type-Checking_Computing-a-Common-Type_Lists-of-Types">18.14.2. Lists of
 </div>
 </div>
 <div class="sect1">
-<h2 id="Values">19. Values</h2>
+<h2 id="Values">20. Values</h2>
 <div class="sectionbody">
 <div class="paragraph">
 <p>A <strong>value</strong> is one of the following:</p>
@@ -9255,7 +9997,7 @@ <h2 id="Values">19. Values</h2>
 <p>Every value belongs to exactly one type.</p>
 </div>
 <div class="sect2">
-<h3 id="Values_Primitive-Integer-Values">19.1. Primitive Integer Values</h3>
+<h3 id="Values_Primitive-Integer-Values">20.1. Primitive Integer Values</h3>
 <div class="paragraph">
 <p>A <strong>primitive integer value</strong> is an ordinary (mathematical) integer value
 together with a
@@ -9285,7 +10027,7 @@ <h3 id="Values_Primitive-Integer-Values">19.1. Primitive Integer Values</h3>
 </div>
 </div>
 <div class="sect2">
-<h3 id="Values_Integer-Values">19.2. Integer Values</h3>
+<h3 id="Values_Integer-Values">20.2. Integer Values</h3>
 <div class="paragraph">
 <p>An <strong>integer value</strong> is an ordinary (mathematical) integer value.
 It has type <em>Integer</em>.
@@ -9294,7 +10036,7 @@ <h3 id="Values_Integer-Values">19.2. Integer Values</h3>
 </div>
 </div>
 <div class="sect2">
-<h3 id="Values_Floating-Point-Values">19.3. Floating-Point Values</h3>
+<h3 id="Values_Floating-Point-Values">20.3. Floating-Point Values</h3>
 <div class="paragraph">
 <p>A <strong>floating-point value</strong> is an IEEE floating-point value of 4- or 8-byte
 width. Formally, the set of floating-point values is the disjoint union
@@ -9316,14 +10058,14 @@ <h3 id="Values_Floating-Point-Values">19.3. Floating-Point Values</h3>
 </div>
 </div>
 <div class="sect2">
-<h3 id="Values_Boolean-Values">19.4. Boolean Values</h3>
+<h3 id="Values_Boolean-Values">20.4. Boolean Values</h3>
 <div class="paragraph">
 <p>A <strong>Boolean value</strong> is one of the values <code>true</code> and <code>false</code>.
 Its type is <code>bool</code>.</p>
 </div>
 </div>
 <div class="sect2">
-<h3 id="Values_String-Values">19.5. String Values</h3>
+<h3 id="Values_String-Values">20.5. String Values</h3>
 <div class="paragraph">
 <p>A <strong>string value</strong> is a sequence of characters that can be
 represented as a <a href="#Expressions_String-Literals">string literal expression</a>.
@@ -9333,7 +10075,7 @@ <h3 id="Values_String-Values">19.5. String Values</h3>
 </div>
 </div>
 <div class="sect2">
-<h3 id="Values_Abstract-Type-Values">19.6. Abstract Type Values</h3>
+<h3 id="Values_Abstract-Type-Values">20.6. Abstract Type Values</h3>
 <div class="paragraph">
 <p>An <strong>abstract type value</strong> is a value associated with an abstract
 type.
@@ -9342,7 +10084,7 @@ <h3 id="Values_Abstract-Type-Values">19.6. Abstract Type Values</h3>
 </div>
 </div>
 <div class="sect2">
-<h3 id="Values_Anonymous-Array-Values">19.7. Anonymous Array Values</h3>
+<h3 id="Values_Anonymous-Array-Values">20.7. Anonymous Array Values</h3>
 <div class="paragraph">
 <p>An <strong>anonymous array value</strong> is a value associated with an anonymous
 array type.
@@ -9355,7 +10097,7 @@ <h3 id="Values_Anonymous-Array-Values">19.7. Anonymous Array Values</h3>
 </div>
 </div>
 <div class="sect2">
-<h3 id="Values_Array-Values">19.8. Array Values</h3>
+<h3 id="Values_Array-Values">20.8. Array Values</h3>
 <div class="paragraph">
 <p>An <strong>array value</strong> is a value associated with an array type.
 We write an array value like an <a href="#Values_Anonymous-Array-Values">anonymous array
@@ -9386,7 +10128,7 @@ <h3 id="Values_Array-Values">19.8. Array Values</h3>
 </div>
 </div>
 <div class="sect2">
-<h3 id="Values_Enumeration-Values">19.9. Enumeration Values</h3>
+<h3 id="Values_Enumeration-Values">20.9. Enumeration Values</h3>
 <div class="paragraph">
 <p>An <strong>enumeration value</strong> is a value associated with an
 <a href="#Definitions_Enumerated-Constant-Definitions">enumerated constant definition</a>.
@@ -9398,7 +10140,7 @@ <h3 id="Values_Enumeration-Values">19.9. Enumeration Values</h3>
 </div>
 </div>
 <div class="sect2">
-<h3 id="Values_Anonymous-Struct-Values">19.10. Anonymous Struct Values</h3>
+<h3 id="Values_Anonymous-Struct-Values">20.10. Anonymous Struct Values</h3>
 <div class="paragraph">
 <p>An <strong>anonymous struct value</strong> is a value associated with an
 <a href="#Types_Internal-Types_Anonymous-Struct-Types">anonymous struct
@@ -9413,7 +10155,7 @@ <h3 id="Values_Anonymous-Struct-Values">19.10. Anonymous Struct Values</h3>
 </div>
 </div>
 <div class="sect2">
-<h3 id="Values_Struct-Values">19.11. Struct Values</h3>
+<h3 id="Values_Struct-Values">20.11. Struct Values</h3>
 <div class="paragraph">
 <p>A <strong>struct value</strong> is a value associated with a
 <a href="#Types_Struct-Types">struct type</a>.
@@ -9445,7 +10187,7 @@ <h3 id="Values_Struct-Values">19.11. Struct Values</h3>
 </div>
 </div>
 <div class="sect2">
-<h3 id="Values_Serialized-Sizes">19.12. Serialized Sizes</h3>
+<h3 id="Values_Serialized-Sizes">20.12. Serialized Sizes</h3>
 <div class="paragraph">
 <p>Every value <em>v</em> whose type has a syntactic representation in FPP has a
 <strong>serialized size</strong>.  This is the number of bytes required to represent <em>v</em> in
@@ -9497,7 +10239,7 @@ <h3 id="Values_Serialized-Sizes">19.12. Serialized Sizes</h3>
 </div>
 </div>
 <div class="sect1">
-<h2 id="Evaluation">20. Evaluation</h2>
+<h2 id="Evaluation">21. Evaluation</h2>
 <div class="sectionbody">
 <div class="paragraph">
 <p><strong>Evaluation</strong> is the process of transforming an <a href="#Expressions">expression</a> into
@@ -9507,7 +10249,7 @@ <h2 id="Evaluation">20. Evaluation</h2>
 in resolving expressions to compile-time constant values.</p>
 </div>
 <div class="sect2">
-<h3 id="Evaluation_Evaluating-Expressions">20.1. Evaluating Expressions</h3>
+<h3 id="Evaluation_Evaluating-Expressions">21.1. Evaluating Expressions</h3>
 <div class="paragraph">
 <p>Evaluation of expressions occurs as stated in the
 <a href="#Expressions">expression descriptions</a>. Evaluation of integer
@@ -9518,14 +10260,14 @@ <h3 id="Evaluation_Evaluating-Expressions">20.1. Evaluating Expressions</h3>
 </div>
 </div>
 <div class="sect2">
-<h3 id="Evaluation_Type-Conversion">20.2. Type Conversion</h3>
+<h3 id="Evaluation_Type-Conversion">21.2. Type Conversion</h3>
 <div class="paragraph">
 <p>The following rules govern the conversion of a value \$v_1\$ of type
 \$T_1\$
 to a value \$v_2\$ of type \$T_2\$.</p>
 </div>
 <div class="sect3">
-<h4 id="Evaluation_Type-Conversion_Unsigned-Primitive-Integer-Values">20.2.1. Unsigned Primitive Integer Values</h4>
+<h4 id="Evaluation_Type-Conversion_Unsigned-Primitive-Integer-Values">21.2.1. Unsigned Primitive Integer Values</h4>
 <div class="olist arabic">
 <ol class="arabic">
 <li>
@@ -9547,7 +10289,7 @@ <h4 id="Evaluation_Type-Conversion_Unsigned-Primitive-Integer-Values">20.2.1. Un
 </div>
 </div>
 <div class="sect3">
-<h4 id="Evaluation_Type-Conversion_Signed-Primitive-Integer-Values">20.2.2. Signed Primitive Integer Values</h4>
+<h4 id="Evaluation_Type-Conversion_Signed-Primitive-Integer-Values">21.2.2. Signed Primitive Integer Values</h4>
 <div class="olist arabic">
 <ol class="arabic">
 <li>
@@ -9567,7 +10309,7 @@ <h4 id="Evaluation_Type-Conversion_Signed-Primitive-Integer-Values">20.2.2. Sign
 </div>
 </div>
 <div class="sect3">
-<h4 id="Evaluation_Type-Conversion_Primitive-Integer-Values-of-Mixed-Sign">20.2.3. Primitive Integer Values of Mixed Sign</h4>
+<h4 id="Evaluation_Type-Conversion_Primitive-Integer-Values-of-Mixed-Sign">21.2.3. Primitive Integer Values of Mixed Sign</h4>
 <div class="paragraph">
 <p>If \$T_1\$ and \$T_2\$ are primitive integer types with one signed and
 one unsigned,
@@ -9592,7 +10334,7 @@ <h4 id="Evaluation_Type-Conversion_Primitive-Integer-Values-of-Mixed-Sign">20.2.
 </div>
 </div>
 <div class="sect3">
-<h4 id="Evaluation_Type-Conversion_Primitive-and-Non-Primitive-Integer-Values">20.2.4. Primitive and Non-Primitive Integer Values</h4>
+<h4 id="Evaluation_Type-Conversion_Primitive-and-Non-Primitive-Integer-Values">21.2.4. Primitive and Non-Primitive Integer Values</h4>
 <div class="paragraph">
 <p>If \$T_1\$ is <em>Integer</em> and \$T_2\$ is a primitive integer type, then
 proceed as if \$T_1\$ were a signed primitive integer
@@ -9607,7 +10349,7 @@ <h4 id="Evaluation_Type-Conversion_Primitive-and-Non-Primitive-Integer-Values">2
 </div>
 </div>
 <div class="sect3">
-<h4 id="Evaluation_Type-Conversion_Floating-Point-Values">20.2.5. Floating-Point Values</h4>
+<h4 id="Evaluation_Type-Conversion_Floating-Point-Values">21.2.5. Floating-Point Values</h4>
 <div class="paragraph">
 <p>We use the standard rules for IEEE floating-point values to convert
 among integer values to and from floating-point values and
@@ -9615,7 +10357,7 @@ <h4 id="Evaluation_Type-Conversion_Floating-Point-Values">20.2.5. Floating-Point
 </div>
 </div>
 <div class="sect3">
-<h4 id="Evaluation_Type-Conversion_Array-Values">20.2.6. Array Values</h4>
+<h4 id="Evaluation_Type-Conversion_Array-Values">21.2.6. Array Values</h4>
 <div class="paragraph">
 <p>If \$T_2\$ is an array type and \$T_1 = T_2\$, then
 let \$v_2 = v_1\$.</p>
@@ -9643,7 +10385,7 @@ <h4 id="Evaluation_Type-Conversion_Array-Values">20.2.6. Array Values</h4>
 </div>
 </div>
 <div class="sect3">
-<h4 id="Evaluation_Type-Conversion_Structure-Values">20.2.7. Structure Values</h4>
+<h4 id="Evaluation_Type-Conversion_Structure-Values">21.2.7. Structure Values</h4>
 <div class="paragraph">
 <p>If \$T_2\$ is a struct type and \$T_1 = T_2\$, then
 let \$v_2 = v_1\$.</p>
@@ -9677,10 +10419,10 @@ <h4 id="Evaluation_Type-Conversion_Structure-Values">20.2.7. Structure Values</h
 </div>
 </div>
 <div class="sect1">
-<h2 id="Analysis-and-Translation">21. Analysis and Translation</h2>
+<h2 id="Analysis-and-Translation">22. Analysis and Translation</h2>
 <div class="sectionbody">
 <div class="sect2">
-<h3 id="Analysis-and-Translation_Analysis">21.1. Analysis</h3>
+<h3 id="Analysis-and-Translation_Analysis">22.1. Analysis</h3>
 <div class="paragraph">
 <p><strong>Analysis</strong> is the process of checking a source model.
 It usually involves the following steps:</p>
@@ -9697,7 +10439,7 @@ <h3 id="Analysis-and-Translation_Analysis">21.1. Analysis</h3>
 </div>
 </div>
 <div class="sect2">
-<h3 id="Analysis-and-Translation_Analysis-Tools">21.2. Analysis Tools</h3>
+<h3 id="Analysis-and-Translation_Analysis-Tools">22.2. Analysis Tools</h3>
 <div class="paragraph">
 <p>An <strong>analysis tool</strong> is a tool that reads in and analyzes FPP
 source files, but does not generate any code.
@@ -9721,7 +10463,7 @@ <h3 id="Analysis-and-Translation_Analysis-Tools">21.2. Analysis Tools</h3>
 </div>
 </div>
 <div class="sect2">
-<h3 id="Analysis-and-Translation_Translation">21.3. Translation</h3>
+<h3 id="Analysis-and-Translation_Translation">22.3. Translation</h3>
 <div class="paragraph">
 <p><strong>Translation</strong> is the process of performing analysis and
 generating code.</p>
@@ -9746,7 +10488,7 @@ <h3 id="Analysis-and-Translation_Translation">21.3. Translation</h3>
 </div>
 </div>
 <div class="sect2">
-<h3 id="Analysis-and-Translation_Translation-Tools">21.4. Translation Tools</h3>
+<h3 id="Analysis-and-Translation_Translation-Tools">22.4. Translation Tools</h3>
 <div class="paragraph">
 <p>A <strong>translation tool</strong> is a tool that translates FPP source files.
 A translation tool typically accepts the following two kinds of
@@ -9785,7 +10527,7 @@ <h3 id="Analysis-and-Translation_Translation-Tools">21.4. Translation Tools</h3>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 2024-08-27 14:18:25 -0700
+Last updated 2024-10-01 09:00:17 -0700
 </div>
 </div>
 <script src="code-prettify/run_prettify.js"></script>
diff --git a/docs/fpp-users-guide.html b/docs/fpp-users-guide.html
index 1965c0706..07b84a31b 100644
--- a/docs/fpp-users-guide.html
+++ b/docs/fpp-users-guide.html
@@ -5,7 +5,7 @@
 <meta http-equiv="X-UA-Compatible" content="IE=edge">
 <meta name="viewport" content="width=device-width, initial-scale=1.0">
 <meta name="generator" content="Asciidoctor 2.0.20">
-<title>The F Prime Prime (FPP) User&#8217;s Guide, Unreleased, after v2.1.0</title>
+<title>The F Prime Prime (FPP) User&#8217;s Guide, v2.2.0</title>
 <link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Open+Sans:300,300italic,400,400italic,600,600italic%7CNoto+Serif:400,400italic,700,700italic%7CDroid+Sans+Mono:400,700">
 <style>
 /*! Asciidoctor default stylesheet | MIT License | https://asciidoctor.org */
@@ -436,7 +436,7 @@
 </head>
 <body class="article toc2 toc-left">
 <div id="header">
-<h1>The F Prime Prime (FPP) User&#8217;s Guide, Unreleased, after v2.1.0</h1>
+<h1>The F Prime Prime (FPP) User&#8217;s Guide, v2.2.0</h1>
 <div id="toc" class="toc2">
 <div id="toctitle">Table of Contents</div>
 <ul class="sectlevel1">
@@ -12530,7 +12530,7 @@ <h4 id="Writing-C-Plus-Plus-Implementations_Implementing-Deployments_Public-Symb
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 2024-08-27 14:20:30 -0700
+Last updated 2024-10-01 08:57:40 -0700
 </div>
 </div>
 <script src="code-prettify/run_prettify.js"></script>
diff --git a/docs/spec/Analysis-and-Translation.adoc b/docs/spec/Analysis-and-Translation.adoc
index 306ff1420..e083405c2 100644
--- a/docs/spec/Analysis-and-Translation.adoc
+++ b/docs/spec/Analysis-and-Translation.adoc
@@ -20,13 +20,13 @@ Source files for analysis are provided in one of two ways:
 2. On standard input, if there are no arguments.
 
 For example, the command `analyze file1.fpp file2.fpp`
-says to read in the translation units `file1.fpp` and `file2.fpp` and perform 
+says to read in the translation units `file1.fpp` and `file2.fpp` and perform
 analysis on the model consisting of these two translation units.
 The command `cat file1.fpp file2.fpp | analyze` is functionally equivalent.
 
 === Translation
 
-*Translation* is the process of performing analysis and 
+*Translation* is the process of performing analysis and
 generating code.
 
 Translation usually involves the following steps:
@@ -36,7 +36,7 @@ Translation usually involves the following steps:
 . If step (1) succeeded, code generation.
 
 FPP is intended to support a variety of translation
-strategies. For example, we need to generate (1) C++ code for FSW and 
+strategies. For example, we need to generate (1) C++ code for FSW and
 (2) XML, Python, or other code to export to ground tools.
 
 === Translation Tools
@@ -54,11 +54,11 @@ For example, when translating a component _C_, a tool may read
 in files containing the definitions of the ports used in _C_,
 but not translate those files.
 
-Source files for translation are provided as for 
+Source files for translation are provided as for
 <<Analysis-and-Translation_Analysis-Tools,analysis tools>>.
 Imported source files are specified as arguments to a `-i` flag.
 
 For example, the command `translate -i file1.fpp,file2.fpp file3.fpp`
 says to import `file1.fpp` and `file2.fpp` and translate `file3.fpp`.
-The command `translate -i file1.fpp,file2.fpp < file3.fpp` is functionally 
+The command `translate -i file1.fpp,file2.fpp < file3.fpp` is functionally
 equivalent.
diff --git a/docs/spec/Comments-and-Annotations.adoc b/docs/spec/Comments-and-Annotations.adoc
index 2c9f9599e..0bbcf506b 100644
--- a/docs/spec/Comments-and-Annotations.adoc
+++ b/docs/spec/Comments-and-Annotations.adoc
@@ -26,7 +26,7 @@ To write a multiline comment, precede each line with `#`:
 An *annotation* is similar to a
 <<Comments-and-Annotations_Comments,comment>>, but it is attached to a
 syntactic element of a model, and it is preserved during
-<<Analysis-and-Translation,analysis and translation>>.  The precise use of 
+<<Analysis-and-Translation,analysis and translation>>.  The precise use of
 annotations depends on the translator. A typical use
 is to include annotations as comments in generated code.
 
@@ -88,13 +88,13 @@ module M {
 ==== Multiline Annotations
 
 You can write several pre-annotations in a row before an
-<<Comments-and-Annotations_Annotations_Where-Annotations-Can-Occur, 
+<<Comments-and-Annotations_Annotations_Where-Annotations-Can-Occur,
 annotatable element>> _e_.
 In this case, all the pre-annotations are attached to the
 element, in the order that they appear.
 
 Similarly, you can write several post-annotations in a row after an
-<<Comments-and-Annotations_Annotations_Where-Annotations-Can-Occur, 
+<<Comments-and-Annotations_Annotations_Where-Annotations-Can-Occur,
 annotatable element>> _e_.
 In this case, all the post-annotations are attached to the
 element, in the order that they appear.
diff --git a/docs/spec/Definitions-and-Uses.adoc b/docs/spec/Definitions-and-Uses.adoc
index ca027f5d6..947326405 100644
--- a/docs/spec/Definitions-and-Uses.adoc
+++ b/docs/spec/Definitions-and-Uses.adoc
@@ -12,7 +12,7 @@ according to the
 A use is a *qualifying use* if it qualifies another use. For example, in
 the following code
 
-* The expression `M.a` contains the expression `M`, which is a qualifying use 
+* The expression `M.a` contains the expression `M`, which is a qualifying use
 of the module `M`. It qualifies the use `M.a`.
 * The expression `M.a` is not a qualifying use.
 
@@ -31,15 +31,15 @@ If a use _u_ is not a qualifying use, then we say it is a *non-qualifying use*.
 
 === Use-Def Graph
 
-The set of definitions and 
+The set of definitions and
 <<Definitions-and-Uses_Uses,non-qualifying uses>>
 in an FPP model induces a directed
 graph called the *use-def graph*. In this graph,
 
 . The nodes are the definitions.
 
-. There is an edge from each definition _d_ to the definitions 
-stem:[d_1, ..., d_n] corresponding to the non-qualifying uses 
+. There is an edge from each definition _d_ to the definitions
+stem:[d_1, ..., d_n] corresponding to the non-qualifying uses
 stem:[u_1, ..., u_n] appearing in _d_.
 
 For example, in the following code, the use-def graph has two nodes `a` and
@@ -86,10 +86,10 @@ However, it is a qualifying use.
 === Order of Definitions and Uses
 
 So long as the
-<<Definitions-and-Uses_Use-Def-Graph,use-def graph>> is acyclic, there is no 
+<<Definitions-and-Uses_Use-Def-Graph,use-def graph>> is acyclic, there is no
 constraint either on the ordering of
 definitions and uses within a
-<<Translation-Units-and-Models,translation unit>>, 
+<<Translation-Units-and-Models,translation unit>>,
 or on the distribution of definitions and uses among translation
 units. For example, if the definition `constant c = 0` appears anywhere
 in any translation unit of a model _M_, then the use of `c` as a
diff --git a/docs/spec/Definitions/Array-Definitions.adoc b/docs/spec/Definitions/Array-Definitions.adoc
index 1d7582534..540c3798f 100644
--- a/docs/spec/Definitions/Array-Definitions.adoc
+++ b/docs/spec/Definitions/Array-Definitions.adoc
@@ -1,6 +1,6 @@
 === Array Definitions
 
-An *array definition* defines a new array type and associates a name with 
+An *array definition* defines a new array type and associates a name with
 it.
 
 ==== Syntax
@@ -8,7 +8,7 @@ it.
 `array` <<Lexical-Elements_Identifiers,_identifier_>> `=`
 `[` <<Expressions,_expression_>> `]` <<Type-Names,_type-name_>>
 _[_
-`default` <<Expressions,_expression_>> 
+`default` <<Expressions,_expression_>>
 _]_
 _[_
 `format` <<Expressions_String-Literals,_string-literal_>>
@@ -17,7 +17,7 @@ _]_
 ==== Semantics
 
 The identifier is the name _N_ of the new type.
-The first expression must evaluate to a compile-time constant numeric value _n_ 
+The first expression must evaluate to a compile-time constant numeric value _n_
 whose value is greater than zero and less than or equal to 256.
 _type-name_ names the type _T_ of each array element.
 
@@ -25,14 +25,14 @@ The definition associates the name _N_ with a new type _T'_
 that represents an array of _n_ elements of type _T_.
 
 The expression following the keyword `default` is optional.
-If present, it specifies the <<Types_Default-Values,default value>> associated 
+If present, it specifies the <<Types_Default-Values,default value>> associated
 with the type.
 The type of the expression must be
 <<Type-Checking_Type-Conversion,convertible to>> _T'_.
 
 The optional format specifier specifies a <<Format-Strings,format string>>.
 When displaying the array, the format is applied to each element of the array.
-There is one argument to the format string, which is an array member.  
+There is one argument to the format string, which is an array member.
 
 ==== Examples
 
diff --git a/docs/spec/Definitions/Component-Definitions.adoc b/docs/spec/Definitions/Component-Definitions.adoc
index d9983e2e7..5346821f6 100644
--- a/docs/spec/Definitions/Component-Definitions.adoc
+++ b/docs/spec/Definitions/Component-Definitions.adoc
@@ -378,7 +378,7 @@ active component DeviceMgr {
   # ----------------------------------------------------------------------
   # Commands
   # ----------------------------------------------------------------------
-  
+
   @ Send a Start event to the specified device
   async command START(
     @ The device number
diff --git a/docs/spec/Definitions/Constant-Definitions.adoc b/docs/spec/Definitions/Constant-Definitions.adoc
index 8b55da3f8..ac0510f55 100644
--- a/docs/spec/Definitions/Constant-Definitions.adoc
+++ b/docs/spec/Definitions/Constant-Definitions.adoc
@@ -16,7 +16,7 @@ model.
 _expression_ must
 <<Evaluation,evaluate>>
 to a compile-time constant value _v_. At any model point where the
-<<Scoping-of-Names_Qualified-Identifiers,qualified identifier>> _Q_ refers to 
+<<Scoping-of-Names_Qualified-Identifiers,qualified identifier>> _Q_ refers to
 the constant definition according to the
 <<Scoping-of-Names_Resolution-of-Qualified-Identifiers,scoping
 rules for names>>, you can use _Q_ as a name for _v_.
diff --git a/docs/spec/Definitions/Enum-Definitions.adoc b/docs/spec/Definitions/Enum-Definitions.adoc
index c3853c4e5..49c570834 100644
--- a/docs/spec/Definitions/Enum-Definitions.adoc
+++ b/docs/spec/Definitions/Enum-Definitions.adoc
@@ -5,12 +5,12 @@ An *enum definition* does two things:
 .  It defines a type stem:[T] and associates a name stem:[N] with stem:[T]. Elsewhere
 in the model, you can use stem:[N] to refer to stem:[T].
 
-.  It associates several named constants stem:[C_1, ..., C_n] with stem:[T].  
+.  It associates several named constants stem:[C_1, ..., C_n] with stem:[T].
 These
 constants, called the *enumerated constants* of stem:[T], are the values that
 an expression of type stem:[T] may attain. Elsewhere in the model, you can
 use the <<Scoping-of-Names_Qualified-Identifiers,qualified
-identifiers>> stem:[N] `.` stem:[C_1, ..., N] `.` stem:[C_n] 
+identifiers>> stem:[N] `.` stem:[C_1, ..., N] `.` stem:[C_n]
 to refer to the enumerated
 constants.
 
@@ -20,7 +20,7 @@ constants.
 _[_ `:` <<Type-Names,_type-name_>> _]_
 `{` _enum-constant-sequence_ `}`
 _[_
-`default` <<Expressions,_expression_>> 
+`default` <<Expressions,_expression_>>
 _]_
 
 _enum-constant-sequence_ is an
@@ -30,9 +30,9 @@ constant definitions>>, and the terminating punctuation is a comma.
 
 ==== Semantics
 
-The enumerated constants have the <<Types_Enum-Types,enum type>> defined in the 
+The enumerated constants have the <<Types_Enum-Types,enum type>> defined in the
 enum definition. During
-<<Analysis-and-Translation,analysis>>, they are represented as values of 
+<<Analysis-and-Translation,analysis>>, they are represented as values of
 a primitive integer type, called the
 *representation type*.
 
@@ -45,7 +45,7 @@ representation type.
 No two enumerated constants may have the same value after the conversion.
 
 The expression following the keyword `default` is optional.
-If present, it specifies the <<Types_Default-Values,default value>> associated 
+If present, it specifies the <<Types_Default-Values,default value>> associated
 with the enum definition.
 The type of the expression must be the type of the enum definition.
 
@@ -59,7 +59,7 @@ the implied representation type is `I32`.
 If _type-name_ appears after the identifier, then the semantic
 analyzer does the following:
 
-. Check that _type-name_ names a <<Types_Primitive-Integer-Types,primitive 
+. Check that _type-name_ names a <<Types_Primitive-Integer-Types,primitive
 integer type>>.
 If not, throw an error.
 
diff --git a/docs/spec/Definitions/Enumerated-Constant-Definitions.adoc b/docs/spec/Definitions/Enumerated-Constant-Definitions.adoc
index b10ffc4a0..b38996fbb 100644
--- a/docs/spec/Definitions/Enumerated-Constant-Definitions.adoc
+++ b/docs/spec/Definitions/Enumerated-Constant-Definitions.adoc
@@ -2,7 +2,7 @@
 
 An *enumerated constant definition* is an element of an
 <<Definitions_Enum-Definitions,enum
-definition>>. Like a 
+definition>>. Like a
 <<Definitions_Constant-Definitions,constant
 definition>>, it associates a value with a named constant. It also
 establishes that the constant is one of the values of the type defined
@@ -20,7 +20,7 @@ _]_
 If present, _expression_ must
 <<Evaluation,evaluate>>
 to a compile-time constant value _v_. At any model point where the
-<<Scoping-of-Names_Qualified-Identifiers,qualified identifier>> _Q_ refers to 
+<<Scoping-of-Names_Qualified-Identifiers,qualified identifier>> _Q_ refers to
 the enumerated constant definition according to the
 <<Scoping-of-Names_Resolution-of-Qualified-Identifiers,scoping
 rules for names>>, you can use _Q_ as a name for the value that results
diff --git a/docs/spec/Definitions/Module-Definitions.adoc b/docs/spec/Definitions/Module-Definitions.adoc
index 5104742f3..1febecba4 100644
--- a/docs/spec/Definitions/Module-Definitions.adoc
+++ b/docs/spec/Definitions/Module-Definitions.adoc
@@ -11,7 +11,7 @@ It is similar to a namespace in C++ or a package in Java or Scala.
 `{` _module-member-sequence_ `}`
 
 _module-member-sequence_ is an
-<<Element-Sequences,element sequence>> in 
+<<Element-Sequences,element sequence>> in
 which each element is a *module member*,
 and the terminating punctuation is a semicolon.
 A module member is one of the following:
diff --git a/docs/spec/Definitions/State-Machine-Definitions.adoc b/docs/spec/Definitions/State-Machine-Definitions.adoc
index 03c634786..ddf94f41a 100644
--- a/docs/spec/Definitions/State-Machine-Definitions.adoc
+++ b/docs/spec/Definitions/State-Machine-Definitions.adoc
@@ -14,9 +14,7 @@ specifies the behavior of a state machine and
 causes an implementation to be generated.
 
 *Implementation note:*
-Support for state machines will be implemented in two phases.
-Phase 1 will implement external state machine definitions only.
-Phase 2 will add support for internal state machine definitions.
+As of FPP v2.2.0, only external state machine definitions are implemented.
 
 ==== Syntax
 
@@ -36,7 +34,11 @@ A state machine member is one of the following:
 * A <<State-Machine-Behavior-Elements_Signal-Definitions,signal definition>>
 * A <<State-Machine-Behavior-Elements_State-Definitions,state definition>>
 
-==== Semantics
+The *transitive members* of a state machine definition _M_ are
+(1) the elements of _M_ and (2)
+the members of any state definition that is a transitive member of _M_.
+
+==== Static Semantics
 
 . The identifier is the name of the state machine.
 
@@ -55,31 +57,41 @@ satisfy the following rules:
 The initial transition occurs when the state machine starts up.
 
 .. _M_ must satisfy the rules described
-<<Definitions_State-Machine-Definitions_The-Transition-Graph,below>>
+<<Definitions_State-Machine-Definitions_Static-Semantics_The-Transition-Graph,below>>
 for the induced transition graph.
 
-==== The Transition Graph
+.. _M_ must satisfy the rules described
+<<Definitions_State-Machine-Definitions_Static-Semantics_Typed-Elements,below>>
+for typed elements.
+
+===== The Transition Graph
 
 If present, the optional state machine member sequence _M_
 induces a directed graph called the *transition graph*, defined as
 follows:
 
-. The nodes of the transition graph are the initial transition specifiers,
-state definitions, and
+. The nodes of the transition graph are the state definitions and
 junction definitions that are transitive members of _M_.
 
-. The *transitive members* of _M_ are (i) the elements of _M_ and (ii)
-the members of any state definition that is a transitive member of _M_.
+. The *initial node* of the transition graph is the state definition
+or junction definition referred to in the unique initial transition specifier
+that is an element of _M_.
 
-. The arcs of the transition graph are given by the <<State-Machine-Behavior-Elements_Enter-Expressions,
-enter expressions>> _e_ that are parts of transitive members of _M_.
-Each enter expression represents an arc from an *initial node* to a *terminal node*.
-The initial node is defined as follows:
+. The arcs of the transition graph are given by the
+<<State-Machine-Behavior-Elements_Transition-Expressions,
+transition expressions>> _e_ that appear in (1) initial transition specifiers
+that are members of states that are transitive members of _M_ and (2)
+state transition specifiers that are transitive members of _M_ and (3)
+junction definitions that are transitive members of _M_.
+Each transition expression represents an arc from a *start node* to an
+*end node*.
+The start node is defined as follows:
 
 .. If _e_ appears in an
 <<State-Machine-Behavior-Elements_Initial-Transition-Specifiers,
-initial transition specifier>> _I_, then the initial node
-is _I_.
+initial transition specifier>> _I_, then the initial node is the
+<<State-Machine-Behavior-Elements_State-Definitions,state definition>>
+immediately enclosing _I_.
 
 .. If _e_ appears in a
 <<State-Machine-Behavior-Elements_State-Transition-Specifiers,
@@ -93,23 +105,74 @@ immediately enclosing _T_.
 _J_, then the initial node is _J_.
 
 +
-In any case,
-the terminal node is the state definition or junction definition
-<<Definitions_State-Machine-Definitions_Scoping-of-Names,referred to>>
-in _e_ after the keyword `enter`.
+The terminal node is the state or junction definition
+<<Definitions_State-Machine-Definitions_Static-Semantics_Scoping-of-Names,referred to>>
+in _e_.
 
 If the optional state machine member sequence is present, then
 the transition graph _T_ must satisfy the following rules:
 
-. Each state machine definition and each junction definition in
-_T_ must be the terminal node of at least one arc.
+.  Each state definition and each junction definition in
+_T_ must be reachable from the initial node of _T_.
 
 . Let _S_ be the subgraph of _T_ consisting of all
-and only the junction definitions and the arcs whose initial
-and terminal nodes are junction definitions.
+and only the junction definitions and the arcs whose start
+and end nodes are junction definitions.
 There must be no cycles in _S_.
 
-==== Scoping of Names
+===== Typed Elements
+
+A *typed element* _e_ is an
+<<State-Machine-Behavior-Elements_Initial-Transition-Specifiers,initial transition specifier>>,
+a
+<<State-Machine-Behavior-Elements_State-Entry-Specifiers,state entry specifier>>,
+a
+<<State-Machine-Behavior-Elements_State-Transition-Specifiers,state transition specifier>>,
+a
+<<State-Machine-Behavior-Elements_State-Exit-Specifiers,state exit specifier>>,
+or a
+<<State-Machine-Behavior-Elements_Junction-Definitions,junction definition>>.
+A typed element _e_ *points to* a junction _J_ if
+
+. _e_ is an initial transition specifier, and its transition expression
+refers to _J_; or
+
+. _e_ is a state transition specifier with a transition expression that refers to
+_J_; or
+
+. _e_ is a junction, and at least one of its transition expressions
+refers to _J_.
+
+It must be possible to assign <<Type-Options,type options>>
+to all the typed elements in a state machine definition in
+the following way.
+If not, an error results.
+
+. The type option of each initial transition specifier, state entry
+specifier, and state exit specifier is _None_.
+
+. The type option of each state transition specifier _S_ is the type
+option specified in the definition of the signal specified in _S_
+after the keyword `on`.
+
+. The type option of a junction _J_ is the
+<<Type-Options_Computing-a-Common-Type-Option_Lists-of-Type-Options,
+common type option>> of the type options of the typed elements
+that point to _J_.
+
+For each typed element _e_
+
+. Let _O_ be the type option assigned to _e_ as described above.
+
+. For every action _A_ appearing in the list of `do` actions specified in _e_,
+_O_ must be <<Type-Options_Conversion-of-Type-Options,convertible to>>
+the type option specified in _A_.
+
+. For every guard _G_ appearing in an `if` construct in _e_,
+_O_ must be <<Type-Options_Conversion-of-Type-Options,convertible to>>
+the type option specified in _G_.
+
+===== Scoping of Names
 
 Inside the optional state machine member sequence, the following
 rules govern the assignment of names to definitions and the resolution
@@ -169,6 +232,33 @@ with the following modifications:
 
 . The brace-delimited definitions are state definitions.
 
+==== Dynamic Semantics
+
+An internal state machine _M_ has the following runtime behavior:
+
+. _M_ maintains a current state _S_.
+The current state is undefined until initialization occurs.
+From that point on, the current state is always a leaf state.
+
+. _M_ provides a function for initializing the state machine.
+It runs the
+<<State-Machine-Behavior-Elements_Initial-Transition-Specifiers_Dynamic-Semantics,
+behavior associated with the initial transition specifier of _M_>>.
+
+. For each signal _s_, _M_ provides a function for sending _s_.
+This function has a typed argument with type _T_ if and only if
+the <<State-Machine-Behavior-Elements_Signal-Definitions,definition of signal _s_>>
+has type _T_.
+It runs the
+<<State-Machine-Behavior-Elements_State-Transition-Specifiers_Dynamic-Semantics,
+behavior associated with _s_ in the current state _S_>>.
+This behavior may cause one or more actions to be performed,
+and it may cause the current state to change.
+
+The functions are called by the code that is generated when a
+state machine is <<Specifiers_State-Machine-Instance-Specifiers,instantiated>>
+as part of an active or queued component.
+
 ==== Examples
 
 [source,fpp]
@@ -176,25 +266,25 @@ with the following modifications:
 
 state machine MonitorSm {
 
-  signal Complete
-  signal Drive
-  signal Calibrate
-  signal RTI
-  signal Stop
-  signal Fault
-
-  action init2
   action doCalibrate
+  action init2
   action motorControl
   action reportFault
 
   guard calibrateReady
 
+  signal Calibrate
+  signal Complete
+  signal Drive
+  signal Fault
+  signal RTI
+  signal Stop
+
   initial enter DeviceOn
 
   state DeviceOn {
 
-    initial do init2 enter Initializing
+    initial do { init2 } enter Initializing
 
     state Initializing {
       on Complete enter Idle
@@ -206,13 +296,13 @@ state machine MonitorSm {
     }
 
     state Calibrating {
-      on RTI do doCalibrate
-      on Fault do reportFault enter Idle
+      on RTI do { doCalibrate }
+      on Fault do { reportFault } enter Idle
       on Complete enter Idle
     }
 
     state Driving {
-      on RTI do motorControl
+      on RTI do { motorControl }
       on Stop enter Idle
     }
 
diff --git a/docs/spec/Definitions/Struct-Definitions.adoc b/docs/spec/Definitions/Struct-Definitions.adoc
index 17cc5e7e5..2ad9e3248 100644
--- a/docs/spec/Definitions/Struct-Definitions.adoc
+++ b/docs/spec/Definitions/Struct-Definitions.adoc
@@ -14,7 +14,7 @@ in which the elements are struct type members, and the terminating
 punctuation is a comma.
 A *struct type member* has the following syntax:
 
-<<Lexical-Elements_Identifiers,_identifier_>> `:` 
+<<Lexical-Elements_Identifiers,_identifier_>> `:`
 _[_
 `[` <<Expressions,_expression_>> `]`
 _]_
@@ -26,22 +26,22 @@ _]_
 ==== Semantics
 
 The identifier is the name _N_ of the type.  The definition associates the name
-_N_ with a 
+_N_ with a
 <<Types_Struct-Types,struct type>> _T_ representing a structure with named members, each
 of the specified type.  Each
 identifier appearing in the struct type member sequence must be distinct.
 
-The optional expression `[` _e_ `]` for a struct member specifies the 
+The optional expression `[` _e_ `]` for a struct member specifies the
 *size* of the member, i.e., the number of elements stored in the member.
 If present, _e_ must have a
 <<Types_Internal-Types_Numeric-Types,numeric type>>, and it must
-evaluate to a value greater than zero after conversion to 
+evaluate to a value greater than zero after conversion to
 <<Types_Internal-Types_Integer,_Integer_>>.
 If _e_ is not present, then default size is one.
 If a member _m_ has size greater than one, then _m_
 is translated to an array in the implementation language.
 
-The optional format specifier for a struct member specifies a 
+The optional format specifier for a struct member specifies a
 <<Format-Strings,format string>>.
 The format is applied when displaying the struct member.
 There is one argument to the format string, which is the member value.
diff --git a/docs/spec/Definitions/Topology-Definitions.adoc b/docs/spec/Definitions/Topology-Definitions.adoc
index 8eeeb0896..cf87392d4 100644
--- a/docs/spec/Definitions/Topology-Definitions.adoc
+++ b/docs/spec/Definitions/Topology-Definitions.adoc
@@ -12,17 +12,17 @@ The connections are merged graph by graph.
 
 ==== Syntax
 
-`topology` 
+`topology`
 <<Lexical-Elements_Identifiers,_identifier_>>
 `{` _topology-member-sequence_ `}`
 
 _topology-member-sequence_ is an
-<<Element-Sequences,element sequence>> in 
+<<Element-Sequences,element sequence>> in
 which each element is a *topology member*,
 and the terminating punctuation is a semicolon.
 A topology member is one of the following:
 
-* A <<Specifiers_Component-Instance-Specifiers,component 
+* A <<Specifiers_Component-Instance-Specifiers,component
 instance specifier>>
 
 * A <<Specifiers_Connection-Graph-Specifiers,connection graph specifier>>
@@ -40,7 +40,7 @@ according to the following algorithm:
 <<Definitions_Topology-Definitions_Semantics_Resolving-to-a-Partially-Numbered-Topology,
 partially numbered topology>> _T'_.
 
-. Apply 
+. Apply
 <<Definitions_Topology-Definitions_Semantics_Automatic-Numbering-of-Ports,
 automatic numbering of ports>>
 to _T'_.
@@ -56,7 +56,7 @@ it is specified in the model source.
 appearing in _D_,
 if _E_ has a port number  expression _e_ in the FPP source, then
 <<Evaluation,evaluate>> _e_,
-<<Type-Checking_Type-Conversion,convert>> the result to a value _n_ of type 
+<<Type-Checking_Type-Conversion,convert>> the result to a value _n_ of type
 _Integer_, and assign the port number _n_ at that position.
 Check that _n_ is in bounds for the port instance being numbered.
 
@@ -91,18 +91,18 @@ connections C { a.b -> c.d, e.f -> g.h }
 
 . Compute the set _S_ of topologies transitively imported into _T_.
 
-. For each topology _T'_ in _S_, 
+. For each topology _T'_ in _S_,
 <<Specifiers_Topology-Import-Specifiers,import the instances>>
 of _T'_ into _T_.
 
-. Check that the connections discovered in step 3 are between port 
+. Check that the connections discovered in step 3 are between port
 instances present in _T_.
 
-. For each topology _T'_ in _S_, 
+. For each topology _T'_ in _S_,
 <<Specifiers_Topology-Import-Specifiers,import the connections>>
 of _T'_ into _T_.
 
-. Resolve 
+. Resolve
 <<Specifiers_Connection-Graph-Specifiers,graph pattern specifiers>>,
 adding connections to _T_.
 Add only connections that are not already present in _T_.
@@ -118,7 +118,7 @@ FPP automatically assigns port numbers as follows.
 *Check output port numbers:*
 At each output port _p_ of each component instance _I_, check that
 
-. The number of connections is in bounds for the 
+. The number of connections is in bounds for the
 size of _I_ `.` _p_.
 
 . There is no pair of connections stem:[c_1] and stem:[c_2]
@@ -140,30 +140,30 @@ For each instance _I_ in the topology:
 .  For each
 <<Specifiers_Port-Matching-Specifiers,port matching specifier>>
 `match` stem:[p_1] `with` stem:[p_2] appearing in the definition of _C_:
- 
+
 ..  For each connection stem:[c_1] with an endpoint at _I_ `.` stem:[p_1]:
- 
+
 ... Let _I'_ be the component instance at the other endpoint
 of stem:[c_1].
- 
+
 ... Check that there is one and only one connection
 stem:[c_2] from _I'_ to _I_ `.` stem:[p_2].
 
 .. Check that the connections stem:[c_2] computed in the previous
 step are all the connections at _I_ `.` stem:[p_2].
- 
+
 .. For each pair stem:[(c_1,c_2)] that has both port numbers assigned,
 check that the port numbers match.
 For each pair stem:[(c_1,c_2)] that has exactly one port number assigned,
 assign the other one to match.
- 
+
 .. Traverse the pairs stem:[(c_1,c_2)] according to the
 <<Definitions_Topology-Definitions_Semantics_Ordering-of-Connections,
 order>> of the connections stem:[c_1], least to greatest.
 For each pair stem:[(c_1,c_2)] that does not yet have assigned
 port numbers, find the lowest available port number
 and assign it at _I_ `.` stem:[p_1] and _I_ `.` stem:[p_2].
-A port number is available if (a) it is in bounds for the 
+A port number is available if (a) it is in bounds for the
 port instance being numbered; and (b)
 it is not already assigned to the same port instance
 in the topology.
@@ -174,7 +174,7 @@ have the same array size and
 the same port numbers assigned so far, so the lowest
 available port number is the same for both.
 
-*Apply general numbering:* 
+*Apply general numbering:*
 Fill in any remaining port numbers.
 
 . Traverse the connections
@@ -182,11 +182,11 @@ Fill in any remaining port numbers.
 in order>>, least to greatest.
 
 . For each output endpoint _P_ in each connection _C_,
-if no port number is already assigned, then assign the lowest available port 
+if no port number is already assigned, then assign the lowest available port
 number at position _P_.
 
 
-. For each input endpoint _P_ in each connection _C_, if no port number is 
+. For each input endpoint _P_ in each connection _C_, if no port number is
 already assigned, then assign the port number zero.
 
 See Example 4 in the <<Definitions_Topology-Definitions_Examples,Examples section>>.
@@ -229,7 +229,7 @@ and stem:[n_2].
 
 . Otherwise stem:[e_1] and stem:[e_2] are equal in the ordering.
 
-*Connections:* A *connection* is stem:[e_1] `pass:[->]` 
+*Connections:* A *connection* is stem:[e_1] `pass:[->]`
 stem:[e_2],
 where stem:[e_1] and stem:[e_2] are the connection endpoints.
 FPP orders connections stem:[c_1] and stem:[c_2] as follows:
@@ -245,7 +245,7 @@ stem:[e_2],
 then stem:[c_1] is less than (respectively greater than) stem:[c_2].
 
 . Otherwise if stem:[e'_1] is less than (respectively greater than)
-stem:[e'_2], then stem:[c_1] is less than (respectively greater than) 
+stem:[e'_2], then stem:[c_1] is less than (respectively greater than)
 stem:[c_2].
 
 . Otherwise stem:[c_1] and stem:[c_2] are equal in the ordering.
@@ -260,7 +260,7 @@ stem:[c_2].
 topology CDH {
 
   # ----------------------------------------------------------------------
-  # Public instances 
+  # Public instances
   # ----------------------------------------------------------------------
 
   instance commandDispatcher
@@ -275,7 +275,7 @@ topology CDH {
   instance timeSource
 
   # ----------------------------------------------------------------------
-  # Private instances 
+  # Private instances
   # ----------------------------------------------------------------------
 
   private instance socketGroundInterface
@@ -288,9 +288,9 @@ topology CDH {
   event connections instance eventLogger
   time connections instance timeSource
 
-  # ---------------------------------------------------------------------- 
+  # ----------------------------------------------------------------------
   # Connection graphs
-  # ---------------------------------------------------------------------- 
+  # ----------------------------------------------------------------------
 
   connections CommandSequences {
     commandSequencer.comCmdOut -> commandDispatcher.comCmdIn
@@ -331,13 +331,13 @@ topology CDH {
 topology AttitudeControl {
 
   # ----------------------------------------------------------------------
-  # Imported topologies 
+  # Imported topologies
   # ----------------------------------------------------------------------
 
   import CDH
 
   # ----------------------------------------------------------------------
-  # Public instances 
+  # Public instances
   # ----------------------------------------------------------------------
 
   instance acsRateGroup
@@ -345,7 +345,7 @@ topology AttitudeControl {
   ...
 
   # ----------------------------------------------------------------------
-  # Private instances 
+  # Private instances
   # ----------------------------------------------------------------------
 
   instance socketGroundInterface
@@ -396,7 +396,7 @@ topology AttitudeControl {
 topology Release {
 
   # ----------------------------------------------------------------------
-  # Imported topologies 
+  # Imported topologies
   # ----------------------------------------------------------------------
 
   import AttitudeControl
@@ -422,7 +422,7 @@ topology B {
   instance c
   instance d
   instance e
-  instance f 
+  instance f
 
   connections C1 {
     a.p1[0] -> c.p[0]
diff --git a/docs/spec/Element-Sequences.adoc b/docs/spec/Element-Sequences.adoc
index 441ea6bf3..8f0035ea2 100644
--- a/docs/spec/Element-Sequences.adoc
+++ b/docs/spec/Element-Sequences.adoc
@@ -11,7 +11,7 @@ depending on the kind of sequence.
 
 For each element _e_ in the sequence:
 
-* You can always terminate _e_ with a sequence of one or more newlines. In 
+* You can always terminate _e_ with a sequence of one or more newlines. In
 this case no terminating punctuation is required.
 
 * You can omit the newline. In this case the terminating punctuation
diff --git a/docs/spec/Evaluation.adoc b/docs/spec/Evaluation.adoc
index 6cd8d3495..bb77bf128 100644
--- a/docs/spec/Evaluation.adoc
+++ b/docs/spec/Evaluation.adoc
@@ -1,6 +1,6 @@
 == Evaluation
 
-*Evaluation* is the process of transforming an <<Expressions,expression>> into 
+*Evaluation* is the process of transforming an <<Expressions,expression>> into
 a <<Values,value>>.
 In FPP, all evaluation happens during
 <<Analysis-and-Translation_Analysis,analysis>>,
@@ -12,27 +12,27 @@ Evaluation of expressions occurs as stated in the
 <<Expressions,expression descriptions>>. Evaluation of integer
 expressions occurs at type <<Types_Internal-Types_Integer,_Integer_>>,
 using enough bits to represent the result without overflow.
-Evaluation of floating-point expressions occurs using 64-bit floating-point 
+Evaluation of floating-point expressions occurs using 64-bit floating-point
 arithmetic.
 
 === Type Conversion
 
-The following rules govern the conversion of a value stem:[v_1] of type 
+The following rules govern the conversion of a value stem:[v_1] of type
 stem:[T_1]
 to a value stem:[v_2] of type stem:[T_2].
 
 ==== Unsigned Primitive Integer Values
 
-. If stem:[T_1] and stem:[T_2] are both unsigned primitive integer types and 
+. If stem:[T_1] and stem:[T_2] are both unsigned primitive integer types and
 stem:[T_2] is
-narrower than stem:[T_1], then construct stem:[v_2] by truncating the 
+narrower than stem:[T_1], then construct stem:[v_2] by truncating the
 unsigned
-binary representation of stem:[v_1] to the width of stem:[v_2]. For 
+binary representation of stem:[v_1] to the width of stem:[v_2]. For
 example, converting `0x1234: U16` to `U8` yields `0x34: U8`.
 
-. Otherwise if stem:[T_1] and stem:[T_2] are both unsigned primitive integer 
+. Otherwise if stem:[T_1] and stem:[T_2] are both unsigned primitive integer
 types, then
-stem:[v_2] is the integer value of stem:[v_1] at the type of 
+stem:[v_2] is the integer value of stem:[v_1] at the type of
 stem:[v_2]. For example,
 converting `0x12: U8` to `U16` yields `0x12: U16`.
 
@@ -44,20 +44,20 @@ the two's complement binary representation of stem:[v_1] to the width of
 stem:[v_2]. For example, converting `-0x1234: I16` to `I8` yields `-0x34:
 I8`.
 
-. Otherwise if stem:[T_1] and stem:[T_2] are both signed primitive integer 
+. Otherwise if stem:[T_1] and stem:[T_2] are both signed primitive integer
 types, then stem:[v_2]
-is the integer value of stem:[v_1] at the type of stem:[v_2]. For 
+is the integer value of stem:[v_1] at the type of stem:[v_2]. For
 example, converting `-0x12: I8` to `I16` yields `-0x12: I16`.
 
 ==== Primitive Integer Values of Mixed Sign
 
-If stem:[T_1] and stem:[T_2] are primitive integer types with one signed and 
+If stem:[T_1] and stem:[T_2] are primitive integer types with one signed and
 one unsigned,
 then do the following:
 
-. Construct the value stem:[v] by converting stem:[v_1] to the type 
+. Construct the value stem:[v] by converting stem:[v_1] to the type
 stem:[T], where
-stem:[T] is signed if stem:[T_1] is signed and unsigned if 
+stem:[T] is signed if stem:[T_1] is signed and unsigned if
 stem:[T_1] is unsigned, and
 stem:[T] has the same width as stem:[T_2].
 
@@ -88,7 +88,7 @@ floating-point values to and from each other.
 If stem:[T_2] is an array type and stem:[T_1 = T_2], then
 let stem:[v_2 = v_1].
 
-Otherwise if stem:[T_1] is an anonymous array type and stem:[T_2] is an 
+Otherwise if stem:[T_1] is an anonymous array type and stem:[T_2] is an
 anonymous array type or array type, both with stem:[n] elements, then
 
 . Let stem:[T'_2] be the element type of stem:[T_2].
@@ -107,15 +107,15 @@ let stem:[v_2 = v_1].
 
 Otherwise if stem:[T_1] is an anonymous struct type and stem:[T_2] is
 an anonymous struct type or struct type
-such that for each member stem:[m] `:` stem:[v_m] of stem:[T_1] there is a member 
-stem:[m] `:` stem:[T_m] in stem:[T_2], then use the value of stem:[T_2] with 
+such that for each member stem:[m] `:` stem:[v_m] of stem:[T_1] there is a member
+stem:[m] `:` stem:[T_m] in stem:[T_2], then use the value of stem:[T_2] with
 the following members:
 
-. For each member stem:[m] `:` stem:[T_m] of stem:[T_2] such that there is a member 
+. For each member stem:[m] `:` stem:[T_m] of stem:[T_2] such that there is a member
 stem:[m] `:` stem:[v_m] in stem:[v_1], add the member stem:[m] `:` stem:[v'_m],
 where stem:[v'_m] is the result of converting stem:[v_m] to stem:[T_m].
 
-. For each member stem:[m] `:` stem:[T_m] of stem:[T_2] such that there is no member 
+. For each member stem:[m] `:` stem:[T_m] of stem:[T_2] such that there is no member
 stem:[m] `:` stem:[v_m] in stem:[v_1], add the member stem:[m] `:` stem:[v'_m],
 where stem:[v'_m] is the <<Types_Default-Values,default value>> at type stem:[T_m].
 
diff --git a/docs/spec/Expressions/Identifier-Expressions.adoc b/docs/spec/Expressions/Identifier-Expressions.adoc
index 09c20c22f..3ce016421 100644
--- a/docs/spec/Expressions/Identifier-Expressions.adoc
+++ b/docs/spec/Expressions/Identifier-Expressions.adoc
@@ -5,8 +5,8 @@ An *identifier expression* is an
 that refers to a
 <<Definitions_Constant-Definitions,constant definition>>
 or
-<<Definitions_Enumerated-Constant-Definitions,enumerated constant definition>>, 
-according to the 
+<<Definitions_Enumerated-Constant-Definitions,enumerated constant definition>>,
+according to the
 <<Scoping-of-Names_Resolution-of-Identifiers,rules for resolving identifiers>>.
 
 **Example:**
diff --git a/docs/spec/Expressions/Integer-Literals.adoc b/docs/spec/Expressions/Integer-Literals.adoc
index 18aaf9539..3a5865525 100644
--- a/docs/spec/Expressions/Integer-Literals.adoc
+++ b/docs/spec/Expressions/Integer-Literals.adoc
@@ -6,7 +6,7 @@ An *integer literal expression* is one of the following:
 representation of a nonnegative integer.
 
 * `0x` or `0X` followed by a sequence of hexadecimal digits
-`0` through `9`, `A` through `F`, or `a` through `f` denoting the hexadecimal 
+`0` through `9`, `A` through `F`, or `a` through `f` denoting the hexadecimal
 representation of a nonnegative
 integer.
 
diff --git a/docs/spec/Expressions/Parenthesis-Expressions.adoc b/docs/spec/Expressions/Parenthesis-Expressions.adoc
index 2c775b4c3..35bfbd85c 100644
--- a/docs/spec/Expressions/Parenthesis-Expressions.adoc
+++ b/docs/spec/Expressions/Parenthesis-Expressions.adoc
@@ -21,5 +21,5 @@ The type and value of the expression are the type and value of the subexpression
 constant a = (1 + 2) * 3
 ----
 
-The expression on the right-hand side of the constant definition evaluates to 
+The expression on the right-hand side of the constant definition evaluates to
 9.
diff --git a/docs/spec/Expressions/Precedence-and-Associativity.adoc b/docs/spec/Expressions/Precedence-and-Associativity.adoc
index dab5af8c1..09b67969f 100644
--- a/docs/spec/Expressions/Precedence-and-Associativity.adoc
+++ b/docs/spec/Expressions/Precedence-and-Associativity.adoc
@@ -3,7 +3,7 @@
 Ambiguity in parsing expressions is resolved with the following
 precedence table. Expressions appearing earlier in the table
 have higher precedence. For example, `-a.b` is parsed as `-(a.b)`
-and not `(-a).b`. Where necessary, each element in the ordering provides an 
+and not `(-a).b`. Where necessary, each element in the ordering provides an
 associativity for resolving expressions with equal precedence.
 
 [cols=",",options="header",]
diff --git a/docs/spec/Expressions/String-Literals.adoc b/docs/spec/Expressions/String-Literals.adoc
index beab88f71..e35232b9d 100644
--- a/docs/spec/Expressions/String-Literals.adoc
+++ b/docs/spec/Expressions/String-Literals.adoc
@@ -55,7 +55,7 @@ unmatched double quote character.
 
 ==== Multiline String Literals
 
-A *multiline string literal* is a sequence of *multiline literal characters* enclosed 
+A *multiline string literal* is a sequence of *multiline literal characters* enclosed
 in sequences `"""` of three double quote characters.
 A multiline literal character is one of the following:
 
@@ -72,7 +72,7 @@ of the interpreted string is _c_.
 
 Whitespace inside a multiline string literal is trimmed as follows:
 
-. The first extended newline character, if any, after the first `"""` is 
+. The first extended newline character, if any, after the first `"""` is
 deleted from the interpreted string.
 
 . Any whitespace occurring in columns to the left of the first `"""`
diff --git a/docs/spec/Expressions/Struct-Expressions.adoc b/docs/spec/Expressions/Struct-Expressions.adoc
index 9e4586249..b95733bd9 100644
--- a/docs/spec/Expressions/Struct-Expressions.adoc
+++ b/docs/spec/Expressions/Struct-Expressions.adoc
@@ -30,7 +30,7 @@ corresponding member names and values.
 [source,fpp]
 ----
 # s is a struct value with members x = 0, y = 1
-constant s = { 
+constant s = {
   x = 0
   y = 1
 }
diff --git a/docs/spec/Format-Strings.adoc b/docs/spec/Format-Strings.adoc
index 8d82cf08f..95721b7be 100644
--- a/docs/spec/Format-Strings.adoc
+++ b/docs/spec/Format-Strings.adoc
@@ -8,14 +8,14 @@ of a
 <<Specifiers_Telemetry-Channel-Specifiers,telemetry channel>>.
 
 An FPP format string is similar to a
-https://docs.python.org/3.0/library/string.html#formatstrings[Python format 
+https://docs.python.org/3.0/library/string.html#formatstrings[Python format
 string].
 As in python, a format string consists of text containing one or more
 *replacement fields* surrounded by curly braces `{` `}`.
-In the output, each replacement field is replaced by the value of an 
+In the output, each replacement field is replaced by the value of an
 *argument*.
 Characters outside of replacement fields are copied to the output unchanged,
-except that the escape sequences `{{` and `}}` are converted to single 
+except that the escape sequences `{{` and `}}` are converted to single
 braces.
 
 The number of arguments must match the number of replacement fields.
@@ -28,7 +28,7 @@ The following replacement fields are allowed:
 It causes the argument to be displayed in a standard way
 for F Prime according to its type.
 
-. If the type of an argument _a_ is an 
+. If the type of an argument _a_ is an
 <<Types_Internal-Types_Integer-Types,integer type>>,
 then you can use an *integer replacement field* to convert _a_.
 An integer replacement field is one of the following:
@@ -41,7 +41,7 @@ An integer replacement field is one of the following:
 
 .. `{o}`: Display _a_ as an octal integer value.
 
-. If the type of an argument _a_ is a 
+. If the type of an argument _a_ is a
 <<Types_Floating-Point-Types,floating-point type>>,
 then you can use a *rational replacement field* to convert _a_.
 A rational replacement field is one of the following:
@@ -50,16 +50,16 @@ A rational replacement field is one of the following:
 
 .. `{f}`: Display _a_ as a rational number using fixed-point notation, e.g., `123.4`.
 
-.. `{g}`: Display _a_ as a rational number using general format. This format 
+.. `{g}`: Display _a_ as a rational number using general format. This format
 uses fixed-point notation for
-numbers up to some size _s_ and uses exponent notation for numbers larger than 
+numbers up to some size _s_ and uses exponent notation for numbers larger than
 _s_.
 The value of _s_ is implementation-dependent.
 
 .. One of the replacement fields denoted above, but with a period and a literal
 decimal integer after the opening brace.
 The integer value _n_ specifies the *precision*, i.e., the number of digits after
-the decimal point for fixed-point notation, or before the `e` for exponent 
+the decimal point for fixed-point notation, or before the `e` for exponent
 notation.
 For example, the replacement field `{.3f}`, specifies fixed-point notation
 with a precision of 3.
diff --git a/docs/spec/Lexical-Elements.adoc b/docs/spec/Lexical-Elements.adoc
index 9e6097867..3a50edbcf 100644
--- a/docs/spec/Lexical-Elements.adoc
+++ b/docs/spec/Lexical-Elements.adoc
@@ -176,7 +176,7 @@ For example:
 
 * `identifier%` is not a valid identifier, because it contains the character `%`.
 
-*Escaped keywords:* Any identifier may be preceded by the character `$`, with 
+*Escaped keywords:* Any identifier may be preceded by the character `$`, with
 no intervening space.
 An identifier `$` _I_ has the same meaning as _I_, except that if _I_ is a
 <<Lexical-Elements_Reserved-Words,reserved word>>, then _I_ is scanned
@@ -195,8 +195,8 @@ treated as an identifier and not as a reserved word.
 
 An *end-of-line token* is a sequence of one or more *newlines*.
 A newline (or line break) is the NL character (ASCII code 0x0A),
-optionally preceded by a CR 
-character (ASCII code 0x0D). End-of-line tokens separate the elements of 
+optionally preceded by a CR
+character (ASCII code 0x0D). End-of-line tokens separate the elements of
 <<Element-Sequences,element sequences>>.
 
 === Comments
@@ -204,15 +204,15 @@ character (ASCII code 0x0D). End-of-line tokens separate the elements of
 The lexer ignores <<Comments-and-Annotations_Comments,comments>>.
 Specifically:
 
-* A comment followed by a <<Lexical-Elements_End-of-Line-Tokens,newline>> is treated as 
+* A comment followed by a <<Lexical-Elements_End-of-Line-Tokens,newline>> is treated as
 a newline.
 
-* A comment at the end of a file, not followed by a newline, is 
+* A comment at the end of a file, not followed by a newline, is
 treated as no text.
 
 === Whitespace and Non-Printable Characters
 
-Apart from <<Lexical-Elements_End-of-Line-Tokens,end-of-line tokens>>, the 
+Apart from <<Lexical-Elements_End-of-Line-Tokens,end-of-line tokens>>, the
 lexer treats whitespace as follows:
 
 * Space characters are ignored, except to separate tokens.
@@ -224,11 +224,11 @@ in an FPP model outside of a string, comment, or annotation.
 
 === Explicit Line Continuations
 
-The character `\`, when appearing before a 
-<<Lexical-Elements_End-of-Line-Tokens,newline>>, 
+The character `\`, when appearing before a
+<<Lexical-Elements_End-of-Line-Tokens,newline>>,
 suppresses the newline.
 Both the `\` and the following newline are ignored, and no
-<<Lexical-Elements_End-of-Line-Tokens,end-of-line token>>, 
+<<Lexical-Elements_End-of-Line-Tokens,end-of-line token>>,
 is created.
 For example, this
 
@@ -312,7 +312,7 @@ is consumed by the `+` symbol:
 
 [source,fpp]
 ----
-constant a = 1 + 
+constant a = 1 +
   2
 ----
 
@@ -342,7 +342,7 @@ as if it were this
 constant a = [
   1
   2
-  3 
+  3
 ]
 ----
 
diff --git a/docs/spec/Port-Instance-Identifiers.adoc b/docs/spec/Port-Instance-Identifiers.adoc
index d18f4a6e4..c67a3a32e 100644
--- a/docs/spec/Port-Instance-Identifiers.adoc
+++ b/docs/spec/Port-Instance-Identifiers.adoc
@@ -19,11 +19,11 @@ For each port instance identifier _Q_ `.` _P_:
 <<Scoping-of-Names_Resolution-of-Qualified-Identifiers,refer to>>
 a component instance _I_.
 
-. _I_ must refer to a <<Definitions_Component-Instance-Definitions,component 
+. _I_ must refer to a <<Definitions_Component-Instance-Definitions,component
 instance definition _I'_>>.
 
-. _I'_ must refer to a <<Definitions_Component-Definitions,component 
-definition _C_>>. 
+. _I'_ must refer to a <<Definitions_Component-Definitions,component
+definition _C_>>.
 
 . The identifier _P_
 must refer to a
@@ -38,7 +38,7 @@ a.b
 A.b.c
 ----
 
-In the first example, `a` names a component instance, and `b` names a port 
+In the first example, `a` names a component instance, and `b` names a port
 instance.
-In the second example, `A.b` names a component instance, and `c` names a 
+In the second example, `A.b` names a component instance, and `c` names a
 port instance.
diff --git a/docs/spec/Scoping-of-Names.adoc b/docs/spec/Scoping-of-Names.adoc
index 0626b9533..a3a6bc134 100644
--- a/docs/spec/Scoping-of-Names.adoc
+++ b/docs/spec/Scoping-of-Names.adoc
@@ -21,13 +21,13 @@ a.b.c
 
 === Names of Definitions
 
-Every 
+Every
 <<Definitions,definition>>
  _D_ appearing in an FPP model has a unique *qualified
 name*. The qualified name is a
 <<Scoping-of-Names_Qualified-Identifiers,qualified identifier>> formed as follows:
 
-* If _D_ appears outside any 
+* If _D_ appears outside any
 <<Definitions,definition>> with a brace-delimited body, then
 the qualified name is the identifier _I_ appearing in _D_.
 
@@ -256,7 +256,7 @@ module M {
 === Resolution of Qualified Identifiers
 
 The following rules govern the resolution of
-<<Scoping-of-Names_Qualified-Identifiers,qualified identifiers>>, i.e., 
+<<Scoping-of-Names_Qualified-Identifiers,qualified identifiers>>, i.e.,
 associating qualified identifiers with definitions:
 
 . If a qualified identifier is an identifier, then resolve it as
@@ -269,10 +269,10 @@ following:
 
 .. Recursively resolve _Q_.
 
-.. If _Q_ refers to a <<Definitions,definition>> 
+.. If _Q_ refers to a <<Definitions,definition>>
 with a brace-delimited body, then do the following:
 
-... Determine the <<Scoping-of-Names_Name-Groups,name group>> _S_ of _Q_ `.` 
+... Determine the <<Scoping-of-Names_Name-Groups,name group>> _S_ of _Q_ `.`
 _I_.
 
 ... Look in _D_ for a definition with identifier _I_ in name group _S_.
diff --git a/docs/spec/Specifiers/Command-Specifiers.adoc b/docs/spec/Specifiers/Command-Specifiers.adoc
index 3b6c84eab..ecccb0958 100644
--- a/docs/spec/Specifiers/Command-Specifiers.adoc
+++ b/docs/spec/Specifiers/Command-Specifiers.adoc
@@ -5,7 +5,7 @@ A *command specifier* specifies a command as part of a
 
 ==== Syntax
 
-_command-kind_ `command` <<Lexical-Elements_Identifiers,_identifier_>> 
+_command-kind_ `command` <<Lexical-Elements_Identifiers,_identifier_>>
 _[_
 `(` <<Formal-Parameter-Lists,_param-list_>> `)`
 _]_
@@ -41,19 +41,19 @@ on the same port can have different kinds.
 
 * The parameter list specifies the command parameters.
 If there are command parameters, each parameter must be
-a <<Types_Displayable-Types,displayable type>>. 
+a <<Types_Displayable-Types,displayable type>>.
 If there are no parameters, the list may be omitted.
 `ref` may not appear in any of the parameters.
 
 * The optional expression _e_ following `opcode` specifies the numeric
 opcode for the command.
-If _e_ is present, its type must be convertible to 
+If _e_ is present, its type must be convertible to
 <<Types_Internal-Types_Integer,_Integer_>>, and _e_ must evaluate
 to a nonnegative integer.
 If _e_ is not present, then the default opcode is either zero (for the first
 opcode appearing in a component) or the previous opcode plus one.
 
-* The optional expression _e_ appearing after the keyword `priority` specifies 
+* The optional expression _e_ appearing after the keyword `priority` specifies
 a priority for the command on the input queue.
 The type of _e_ must be <<Type-Checking_Type-Conversion,convertible to>>
 <<Types_Internal-Types_Integer,_Integer_>>.
diff --git a/docs/spec/Specifiers/Component-Instance-Specifiers.adoc b/docs/spec/Specifiers/Component-Instance-Specifiers.adoc
index 3fd598629..cf5a1c177 100644
--- a/docs/spec/Specifiers/Component-Instance-Specifiers.adoc
+++ b/docs/spec/Specifiers/Component-Instance-Specifiers.adoc
@@ -1,7 +1,7 @@
 === Component Instance Specifiers
 
-A *component instance specifier* 
-specifies that a 
+A *component instance specifier*
+specifies that a
 <<Definitions_Component-Instance-Definitions,component instance>>
 is part of a
 <<Definitions_Topology-Definitions,topology>>.
@@ -29,7 +29,7 @@ in any topology _T'_ into which _T_ is
 <<Specifiers_Topology-Import-Specifiers,imported>>.
 
 * If an instance is not declared private, then it is implicitly
-a *public instance*. This means the instance 
+a *public instance*. This means the instance
 appears in each topology _T'_ into which _T_ is
 <<Specifiers_Topology-Import-Specifiers,imported>>.
 
@@ -48,7 +48,7 @@ instance c: B base id 0x300 ...
 Topology T {
 
   # ----------------------------------------------------------------------
-  # Public instances 
+  # Public instances
   # ----------------------------------------------------------------------
 
   instance a
diff --git a/docs/spec/Specifiers/Connection-Graph-Specifiers.adoc b/docs/spec/Specifiers/Connection-Graph-Specifiers.adoc
index 77cc42eec..ac551a457 100644
--- a/docs/spec/Specifiers/Connection-Graph-Specifiers.adoc
+++ b/docs/spec/Specifiers/Connection-Graph-Specifiers.adoc
@@ -4,7 +4,7 @@ A *connection graph specifier* specifies one or more *connection graphs*
 as part of a
 <<Definitions_Topology-Definitions,topology definition>>.
 A connection graph is a named set of *connections*.
-A connection connects an <<Specifiers_Port-Instance-Specifiers,output port 
+A connection connects an <<Specifiers_Port-Instance-Specifiers,output port
 instance>> of one
 <<Specifiers_Component-Instance-Specifiers,component instance>>
 to an
@@ -16,20 +16,20 @@ another.
 A connection graph specifier is one of the following:
 
 * A *direct graph specifier:*
-`connections` 
+`connections`
 <<Lexical-Elements_Identifiers,_identifier_>>
 `{` _connection-sequence_ `}`
 
 * A *pattern graph specifier:*
 _pattern-kind_
-`connections` 
+`connections`
 `instance` <<Scoping-of-Names_Qualified-Identifiers,_qual-ident_>>
 _[_
 `{` _instance-sequence_ `}`
 _]_
 
 _connection-sequence_ is an
-<<Element-Sequences,element sequence>> in 
+<<Element-Sequences,element sequence>> in
 which each element is a *connection*,
 and the terminating punctuation is a comma.
 A connection is the following:
@@ -63,7 +63,7 @@ _pattern-kind_ is one of the following:
 . `time`
 
 _instance-sequence_ is an
-<<Element-Sequences,element sequence>> in 
+<<Element-Sequences,element sequence>> in
 which each element is a
 <<Scoping-of-Names_Qualified-Identifiers,qualified identifier>>,
 and the terminating punctuation is a comma.
@@ -88,14 +88,14 @@ either through
 or through
 <<Specifiers_Topology-Import-Specifiers,import>>.
 
-... The optional expression _e_ following the identifier, if it is present, 
+... The optional expression _e_ following the identifier, if it is present,
 represents a port number, i.e., an index into an
 array of port instances.
 The type of _e_ must be a
 <<Types_Internal-Types_Numeric-Types,numeric type>>, and
 _e_ must
 <<Evaluation,evaluate>> to a compile-time constant
-that becomes a non-negative integer _n_ when 
+that becomes a non-negative integer _n_ when
 <<Evaluation_Type-Conversion,converted to>> type _Integer_.
 _n_ must lie in the range [0,2^31^) and must be in bounds for the
 array size of the port instance specifier named in _I_.
@@ -117,7 +117,7 @@ instance _T_, then the <<Definitions_Port-Definitions,port type>>
 specified in _T_ may not have a return type.
 
 *Pattern graph specifiers.*
-A pattern graph specifier indirectly specifies one or more named connection 
+A pattern graph specifier indirectly specifies one or more named connection
 graphs
 by specifying a source component instance, a set of target component
 instances, and a pattern for connecting the source instance to each of the
@@ -152,11 +152,11 @@ from the output port of type `Fw::Cmd` of _I_ to the command input port
 of each target component.
 
 .. A connection graph named `CommandRegistration` consisting of all
-connections from the command registration output port of 
+connections from the command registration output port of
 each target component
 to the command registration input port of _I_.
 
-.. A connection graph named `CommandResponse` consisting of all connections 
+.. A connection graph named `CommandResponse` consisting of all connections
 from the command response output port of each target component
 to the command response input port of _I_.
 
@@ -174,7 +174,7 @@ ports of the target components of type `Svc.Ping`.
 . `param`: The source instance _I_ is a parameter database
 component.
 The generate connection graph has name `Parameters`
-and contains all connections for (a) getting 
+and contains all connections for (a) getting
 parameters from the database and (b) saving
 parameters to the database.
 
@@ -249,5 +249,5 @@ connections CommandResponse {
 }
 ----
 
-See also the <<Definitions_Topology-Definitions_Examples,examples for topology 
+See also the <<Definitions_Topology-Definitions_Examples,examples for topology
 definitions>>.
diff --git a/docs/spec/Specifiers/Event-Specifiers.adoc b/docs/spec/Specifiers/Event-Specifiers.adoc
index 28b5f8ff9..4b252c99c 100644
--- a/docs/spec/Specifiers/Event-Specifiers.adoc
+++ b/docs/spec/Specifiers/Event-Specifiers.adoc
@@ -5,12 +5,12 @@ An *event specifier* specifies an event report as part of a
 
 ==== Syntax
 
-`event` 
+`event`
 <<Lexical-Elements_Identifiers,_identifier_>>
 _[_
 `(` <<Formal-Parameter-Lists,_param-list_>> `)`
 _]_
-`severity` _severity_ 
+`severity` _severity_
 _[_
 `id` <<Expressions,_expression_>>
 _]_
@@ -43,10 +43,10 @@ If there are no parameters, the list may be omitted.
 
 * The optional expression _e_ following `id` specifies the numeric
 identifier for the event.
-If _e_ is present, then the type of _e_ must be convertible to 
+If _e_ is present, then the type of _e_ must be convertible to
 <<Types_Internal-Types_Integer,_Integer_>>, and _e_ must evaluate
 to a nonnegative integer.
-If _e_ is not present, then the default identifier is either zero (for the 
+If _e_ is not present, then the default identifier is either zero (for the
 first
 event appearing in a component) or the previous event identifier plus one.
 
@@ -58,7 +58,7 @@ argument whose type is a <<Types_Internal-Types_Numeric-Types,numeric type>>.
 
 * The optional expression _e_ following `throttle` specifies the maximum number
 of times to emit the event before throttling it.
-The type of _e_ must be convertible to 
+The type of _e_ must be convertible to
 <<Types_Internal-Types_Integer,_Integer_>> and must evaluate to an integer
 in the range [0,2^31^).
 
diff --git a/docs/spec/Specifiers/Init-Specifiers.adoc b/docs/spec/Specifiers/Init-Specifiers.adoc
index c42deed6d..56b846f01 100644
--- a/docs/spec/Specifiers/Init-Specifiers.adoc
+++ b/docs/spec/Specifiers/Init-Specifiers.adoc
@@ -1,6 +1,6 @@
 === Init Specifiers
 
-An *init specifier* associates some code with a 
+An *init specifier* associates some code with a
 <<Definitions_Component-Instance-Definitions,
 component instance>>.
 Usually this is initialization code, hence the name.
diff --git a/docs/spec/Specifiers/Internal-Port-Specifiers.adoc b/docs/spec/Specifiers/Internal-Port-Specifiers.adoc
index 18d6d9969..d1028e658 100644
--- a/docs/spec/Specifiers/Internal-Port-Specifiers.adoc
+++ b/docs/spec/Specifiers/Internal-Port-Specifiers.adoc
@@ -1,7 +1,7 @@
 === Internal Port Specifiers
 
-An *internal port specifier* specifies 
-a single-use port for use in handlers of the enclosing 
+An *internal port specifier* specifies
+a single-use port for use in handlers of the enclosing
 <<Definitions_Component-Definitions,component>>.
 A component can use an internal port to send a message
 to itself.
@@ -22,7 +22,7 @@ _[_
 _queue-full-behavior_
 _]_
 
-_queue-full-behavior_ has the same syntax as for 
+_queue-full-behavior_ has the same syntax as for
 <<Specifiers_Port-Instance-Specifiers_Syntax,port instance specifiers>>.
 
 ==== Semantics
@@ -34,8 +34,8 @@ Each formal parameter is a piece of data carried on the port.
 The names of the formal parameters must be distinct.
 No formal parameter may be a `ref` parameter.
 
-The optional priority and queue full behavior have the same semantics as in 
-<<Specifiers_Port-Instance-Specifiers_Semantics, async input port instance 
+The optional priority and queue full behavior have the same semantics as in
+<<Specifiers_Port-Instance-Specifiers_Semantics, async input port instance
 specifiers>>.
 
 ==== Examples
diff --git a/docs/spec/Specifiers/Location-Specifiers.adoc b/docs/spec/Specifiers/Location-Specifiers.adoc
index 81365e018..f36c7c8b9 100644
--- a/docs/spec/Specifiers/Location-Specifiers.adoc
+++ b/docs/spec/Specifiers/Location-Specifiers.adoc
@@ -1,6 +1,6 @@
 === Location Specifiers
 
-A *location specifier* specifies the 
+A *location specifier* specifies the
 <<Translation-Units-and-Models_Locations,location>>
 of a <<Definitions,definition>>.
 
@@ -8,59 +8,59 @@ of a <<Definitions,definition>>.
 
 A location specifier is one of the following:
 
-* A *component instance location specifier* `locate` `instance` 
-<<Scoping-of-Names_Qualified-Identifiers,_qual-ident_>> `at` 
+* A *component instance location specifier* `locate` `instance`
+<<Scoping-of-Names_Qualified-Identifiers,_qual-ident_>> `at`
 <<Expressions_String-Literals,_string-literal_>>
 
-* A *component location specifier* `locate` `component` 
-<<Scoping-of-Names_Qualified-Identifiers,_qual-ident_>> `at` 
+* A *component location specifier* `locate` `component`
+<<Scoping-of-Names_Qualified-Identifiers,_qual-ident_>> `at`
 <<Expressions_String-Literals,_string-literal_>>
 
-* A *constant location specifier* `locate` `constant` 
-<<Scoping-of-Names_Qualified-Identifiers,_qual-ident_>> `at` 
+* A *constant location specifier* `locate` `constant`
+<<Scoping-of-Names_Qualified-Identifiers,_qual-ident_>> `at`
 <<Expressions_String-Literals,_string-literal_>>
 
-* A *port location specifier* `locate` `port` 
-<<Scoping-of-Names_Qualified-Identifiers,_qual-ident_>> `at` 
+* A *port location specifier* `locate` `port`
+<<Scoping-of-Names_Qualified-Identifiers,_qual-ident_>> `at`
 <<Expressions_String-Literals,_string-literal_>>
 
 * A *state machine location specifier* `locate` `state` `machine`
-<<Scoping-of-Names_Qualified-Identifiers,_qual-ident_>> `at` 
+<<Scoping-of-Names_Qualified-Identifiers,_qual-ident_>> `at`
 <<Expressions_String-Literals,_string-literal_>>
 
-* A *topology location specifier* `locate` `topology` 
-<<Scoping-of-Names_Qualified-Identifiers,_qual-ident_>> `at` 
+* A *topology location specifier* `locate` `topology`
+<<Scoping-of-Names_Qualified-Identifiers,_qual-ident_>> `at`
 <<Expressions_String-Literals,_string-literal_>>
 
-* A *type location specifier* `locate` `type` 
-<<Scoping-of-Names_Qualified-Identifiers,_qual-ident_>> `at` 
+* A *type location specifier* `locate` `type`
+<<Scoping-of-Names_Qualified-Identifiers,_qual-ident_>> `at`
 <<Expressions_String-Literals,_string-literal_>>
 
 ==== Semantics
 
-. The qualified identifier _Q_ is resolved like a 
-<<Definitions-and-Uses_Uses,use>> that refers to a <<Definitions,definition>> 
+. The qualified identifier _Q_ is resolved like a
+<<Definitions-and-Uses_Uses,use>> that refers to a <<Definitions,definition>>
 as follows:
 
-.. A constant location specifier refers to a 
+.. A constant location specifier refers to a
 <<Definitions_Constant-Definitions,constant definition>>.
 
-.. A type location specifier refers to an 
-<<Definitions_Array-Definitions,array definition>>, 
+.. A type location specifier refers to an
+<<Definitions_Array-Definitions,array definition>>,
 <<Definitions_Enum-Definitions,enum definition>>,
 <<Definitions_Struct-Definitions,struct definition>>, or
 <<Definitions_Abstract-Type-Definitions,abstract type definition>>.
 
-.. A port location specifier refers to a 
+.. A port location specifier refers to a
 <<Definitions_Port-Definitions,port definition>>.
 
-.. A component location specifier refers to a 
+.. A component location specifier refers to a
 <<Definitions_Component-Definitions,component definition>>.
 
-.. A component instance location specifier refers to a 
+.. A component instance location specifier refers to a
 <<Definitions_Component-Instance-Definitions,component instance definition>>.
 
-.. A topology location specifier refers to a 
+.. A topology location specifier refers to a
 <<Definitions_Topology-Definitions,topology definition>>.
 
 .. A state machine location specifier refers to a
@@ -68,7 +68,7 @@ as follows:
 
 . When a location specifier appears inside a
 <<Definitions_Module-Definitions,module definition _M_>>,
-_Q_ is implicitly qualified by the 
+_Q_ is implicitly qualified by the
 <<Scoping-of-Names_Names-of-Definitions,qualified name>>
 of _M_.
 
@@ -81,13 +81,13 @@ or translation.
 <<Translation-Units-and-Models_Locations,location>>
 of the specifier.
 The file must exist.
-After resolving 
+After resolving
 <<Specifiers_Include-Specifiers,include specifiers>>,
 the file must contain the definition referred to in the
 location specifier.
 
 . Multiple location specifiers for the same definition are allowed in a single
-<<Translation-Units-and-Models_Models,model>>, so long as the locations are all 
+<<Translation-Units-and-Models_Models,model>>, so long as the locations are all
 consistent.
 
 ==== Examples
diff --git a/docs/spec/Specifiers/Parameter-Specifiers.adoc b/docs/spec/Specifiers/Parameter-Specifiers.adoc
index 7f8cf790a..1264d544b 100644
--- a/docs/spec/Specifiers/Parameter-Specifiers.adoc
+++ b/docs/spec/Specifiers/Parameter-Specifiers.adoc
@@ -29,17 +29,17 @@ _T_ must be a <<Types_Displayable-Types,displayable type>>.
 
 * The optional expression _e_ following the keyword `default`
 specifies a default value for the parameter.
-If _e_ is present, then the type of _e_ must be 
+If _e_ is present, then the type of _e_ must be
 <<Type-Checking_Type-Conversion,convertible to>> _T_.
 If _e_ is not present, then there is no default value for
-the parameter: 
+the parameter:
 When the parameter is used, then either (1) a value is
 available in the parameter database or (2) the use is
 invalid.
 
-* The optional expression _e_ after the keyword `id` specifies the 
+* The optional expression _e_ after the keyword `id` specifies the
 numeric identifier for the parameter.
-If _e_ is present, then the type of _e_ must be 
+If _e_ is present, then the type of _e_ must be
 <<Type-Checking_Type-Conversion,convertible to>>
 <<Types_Internal-Types_Integer,_Integer_>>, and _e_ must evaluate
 to a nonnegative integer.
@@ -49,16 +49,16 @@ component) or the previous parameter identifier plus one.
 
 * The optional expression _e_ after the keywords `set` `opcode` specifies the
 opcode of the command for setting the parameter.
-If _e_ is present, then the type of _e_ must be 
+If _e_ is present, then the type of _e_ must be
 <<Type-Checking_Type-Conversion,convertible to>>
 <<Types_Internal-Types_Integer,_Integer_>>.
 If _e_ is not present, then the default value is either zero (for
 the first command appearing in a component) or the previous opcode
 plus one.
 
-* The optional expression _e_ after the keywords `save` `opcode` specifies 
+* The optional expression _e_ after the keywords `save` `opcode` specifies
 the opcode of the command for saving the parameter.
-If _e_ is present, then the type of _e_ must be 
+If _e_ is present, then the type of _e_ must be
 <<Type-Checking_Type-Conversion,convertible to>>
 <<Types_Internal-Types_Integer,_Integer_>>.
 If _e_ is not present, then the default value is either zero (for
diff --git a/docs/spec/Specifiers/Port-Instance-Specifiers.adoc b/docs/spec/Specifiers/Port-Instance-Specifiers.adoc
index 7f211a0d0..36233e59f 100644
--- a/docs/spec/Specifiers/Port-Instance-Specifiers.adoc
+++ b/docs/spec/Specifiers/Port-Instance-Specifiers.adoc
@@ -1,6 +1,6 @@
 === Port Instance Specifiers
 
-A *port instance specifier* specifies an instantiated 
+A *port instance specifier* specifies an instantiated
 <<Definitions_Port-Definitions,port>> as part
 of a
 <<Definitions_Component-Definitions,component definition>>.
@@ -9,7 +9,7 @@ of a
 
 A port instance specifier is one of the following:
 
-* _general-port-kind_ `port` <<Lexical-Elements_Identifiers,_identifier_>> `:` 
+* _general-port-kind_ `port` <<Lexical-Elements_Identifiers,_identifier_>> `:`
 _[_
 `[` <<Expressions,_expression_>> `]`
 _]_
@@ -138,7 +138,7 @@ from a specific type at the other end of the connection.
 `priority` specifies a priority for the port instance.
 The type of _e_ must be <<Type-Checking_Type-Conversion,convertible to>>
 <<Types_Internal-Types_Integer,_Integer_>>.
-The priority applies to the component's message queue and may appear only for 
+The priority applies to the component's message queue and may appear only for
 `async input` ports.
 The meaning of the priority value is operating system-dependent.
 
diff --git a/docs/spec/Specifiers/Port-Matching-Specifiers.adoc b/docs/spec/Specifiers/Port-Matching-Specifiers.adoc
index c6c426f35..4437f0d32 100644
--- a/docs/spec/Specifiers/Port-Matching-Specifiers.adoc
+++ b/docs/spec/Specifiers/Port-Matching-Specifiers.adoc
@@ -12,7 +12,7 @@ to its ping input port at the same port number _n_.
 
 ==== Syntax
 
-`match` 
+`match`
 <<Lexical-Elements_Identifiers,_identifier_>>
 `with`
 <<Lexical-Elements_Identifiers,_identifier_>>
diff --git a/docs/spec/Specifiers/State-Machine-Instance-Specifiers.adoc b/docs/spec/Specifiers/State-Machine-Instance-Specifiers.adoc
index 3aebfcffe..75c3befb9 100644
--- a/docs/spec/Specifiers/State-Machine-Instance-Specifiers.adoc
+++ b/docs/spec/Specifiers/State-Machine-Instance-Specifiers.adoc
@@ -1,6 +1,6 @@
 === State Machine Instance Specifiers
 
-A *state machine instance specifier* specifies an instantiated 
+A *state machine instance specifier* specifies an instantiated
 <<Definitions_State-Machine-Definitions,state machine>> as part
 of a
 <<Definitions_Component-Definitions,component definition>>.
@@ -18,10 +18,10 @@ _[_
 _queue-full-behavior_
 _]_
 
-_queue-full-behavior_ has the same syntax as for 
+_queue-full-behavior_ has the same syntax as for
 <<Specifiers_Port-Instance-Specifiers_Syntax,port instance specifiers>>.
 
-==== Semantics
+==== Static Semantics
 
 . The identifier names the state machine instance.
 
@@ -30,10 +30,27 @@ _queue-full-behavior_ has the same syntax as for
 a
 <<Definitions_State-Machine-Definitions,state machine definition>>.
 
-. The optional priority and queue full behavior have the same semantics as in 
-<<Specifiers_Port-Instance-Specifiers_Semantics, async input port instance 
+. The optional priority and queue full behavior have the same semantics as in
+<<Specifiers_Port-Instance-Specifiers_Semantics, async input port instance
 specifiers>>.
 
+==== Dynamic Semantics
+
+. Specifying one or more instances of a state machine _M_ in a component _C_
+causes the following code to be generated as part of _C_:
+
+.. Pure virtual functions corresponding to the actions and guards of _M_.
+
+.. For each signal _s_ of _M_, a function for sending _s_ to _M_.
+The signal function may or may not have a typed argument, depending
+on the definition of _s_.
+The signal and the argument, if any, are serialized on the component
+queue and dispatched from the queue in the ordinary way for
+an F Prime active or queued component.
+Upon dispatching a signal, the signal and argument, if any,
+are used to call the <<Definitions_State-Machine-Definitions_Dynamic-Semantics,
+function for sending _s_ to _M_>>.
+
 ==== Examples
 
 [source,fpp]
diff --git a/docs/spec/Specifiers/Telemetry-Channel-Specifiers.adoc b/docs/spec/Specifiers/Telemetry-Channel-Specifiers.adoc
index 904c0f031..540fc09b6 100644
--- a/docs/spec/Specifiers/Telemetry-Channel-Specifiers.adoc
+++ b/docs/spec/Specifiers/Telemetry-Channel-Specifiers.adoc
@@ -7,21 +7,21 @@ A *telemetry channel definition* defines a telemetry channel as part of a
 
 `telemetry` <<Lexical-Elements_Identifiers,_identifier_>>
 `:` <<Type-Names,_type-name_>>
-_[_ 
+_[_
 `id` <<Expressions,_expression_>>
 _]_
-_[_ 
+_[_
 `update` _telemetry-update_
 _]_
-_[_ 
+_[_
 `format` <<Expressions_String-Literals,_string-literal_>>
 _]_
-_[_ 
+_[_
 `low` `{` _telemetry-limit-sequence_ `}`
-_]_ 
-_[_ 
+_]_
+_[_
 `high` `{` _telemetry-limit-sequence_ `}`
-_]_ 
+_]_
 
 _telemetry-update_ is one of the following:
 
@@ -66,7 +66,7 @@ If the specifier is not present, the default behavior is always.
 There is one argument to the format string, which is the channel value.
 
 . The optional high and low limit specifiers specify the high and low limits
-for the channel. 
+for the channel.
 The following rules apply:
 
 .. At most one of each kind of limit (red, orange, yellow) may appear
@@ -74,10 +74,10 @@ in each specifier.
 
 .. The type of the expression in each limit must be a
 <<Types_Internal-Types_Numeric-Types,numeric type>> and must be
-<<Type-Checking_Type-Conversion,convertible to>> 
+<<Type-Checking_Type-Conversion,convertible to>>
 the type of the channel.
 
-.. The limit is applied to each telemetry channel with type _T_ and value _v_ 
+.. The limit is applied to each telemetry channel with type _T_ and value _v_
 as follows:
 
 ... If _T_ is a
@@ -85,7 +85,7 @@ as follows:
 limit is applied directly to _v_.
 
 ...  If _T_ is not itself a numeric type
-(e.g., it is an array), then the limit is applied recursively to each member 
+(e.g., it is an array), then the limit is applied recursively to each member
 value of _v_.
 
 ==== Examples
diff --git a/docs/spec/Specifiers/Topology-Import-Specifiers.adoc b/docs/spec/Specifiers/Topology-Import-Specifiers.adoc
index c5b90ffe1..725520348 100644
--- a/docs/spec/Specifiers/Topology-Import-Specifiers.adoc
+++ b/docs/spec/Specifiers/Topology-Import-Specifiers.adoc
@@ -8,7 +8,7 @@ A *topology import specifier* imports one topology into another one.
 
 ==== Semantics
 
-The qualified identifier must 
+The qualified identifier must
 <<Scoping-of-Names_Resolution-of-Qualified-Identifiers,refer to>>
 a
 <<Definitions_Topology-Definitions,topology definition>>.
@@ -17,11 +17,11 @@ a
 FPP uses the following algorithm to import the instances
 of topology _T'_ into topology _T_:
 
-. Let _I_ be the set of 
+. Let _I_ be the set of
 <<Specifiers_Component-Instance-Specifiers,instances>>
 of _T_.
 
-. Let _I'_ be the set of 
+. Let _I'_ be the set of
 <<Specifiers_Component-Instance-Specifiers,public instances>>
 of _T'_.
 
@@ -47,7 +47,7 @@ with name stem:[N_i].
 If no such graph exists, then let stem:[G'_i] be the empty connection graph
 with name stem:[N_i].
 
-.. Let stem:[C_i] be the set of 
+.. Let stem:[C_i] be the set of
 <<Specifiers_Connection-Graph-Specifiers,connections>>
 of stem:[G_i] such that each of the two instances at
 the ends of the connection is in _I''_.
@@ -56,7 +56,7 @@ the ends of the connection is in _I''_.
 <<Specifiers_Connection-Graph-Specifiers,connections>>
 of stem:[G'_i] such that each of the two the instances at
 the ends of the connection is in _I''_, and the connection
-is defined by a direct or pattern specifier in _T'_ 
+is defined by a direct or pattern specifier in _T'_
 (i.e., not imported into _T'_ from another topology).
 
 .. Let stem:[C''_i] be the disjoint union of stem:[C_i] and stem:[C'_i].
@@ -123,7 +123,7 @@ topology B {
   instance c
   instance d
   instance e
-  instance f 
+  instance f
 
   connections C1 {
     a.p1 -> c.p
diff --git a/docs/spec/State-Machine-Behavior-Elements/Action-Definitions.adoc b/docs/spec/State-Machine-Behavior-Elements/Action-Definitions.adoc
index acd8d313a..e6ec70dd3 100644
--- a/docs/spec/State-Machine-Behavior-Elements/Action-Definitions.adoc
+++ b/docs/spec/State-Machine-Behavior-Elements/Action-Definitions.adoc
@@ -13,7 +13,7 @@ Actions may carry data.
 `action`
 <<Lexical-Elements_Identifiers,_identifier_>>
 _[_
-`:` 
+`:`
 <<Type-Names,_type-name_>>
 _]_
 
@@ -25,7 +25,7 @@ _]_
 with the action.
 A value of type _T_ will be passed into the function associated with
 the action when it is called.
-If _type-name_ is not present, then there is no data associated with the 
+If _type-name_ is not present, then there is no data associated with the
 action.
 
 ==== Examples
diff --git a/docs/spec/State-Machine-Behavior-Elements/Do-Expressions.adoc b/docs/spec/State-Machine-Behavior-Elements/Do-Expressions.adoc
new file mode 100644
index 000000000..922e721a8
--- /dev/null
+++ b/docs/spec/State-Machine-Behavior-Elements/Do-Expressions.adoc
@@ -0,0 +1,46 @@
+=== Do Expressions
+
+An *do expression* specifies a list of actions as part of an
+<<State-Machine-Behavior-Elements_Initial-Transition-Specifiers,initial transition specifier>>,
+a <<State-Machine-Behavior-Elements_State-Transition-Specifiers,state transition specifier>>,
+a <<State-Machine-Behavior-Elements_State-Entry-Specifiers,state entry specifier>>,
+a <<State-Machine-Behavior-Elements_State-Exit-Specifiers,state exit specifier>>,
+or
+a <<State-Machine-Behavior-Elements_Junction-Definitions,junction definition>>.
+
+==== Syntax
+
+`do` `{` _action-sequence_ `}`
+
+_action-sequence_ is an
+<<Element-Sequences,element sequence>> in
+which each element is an <<Lexical-Elements_Identifiers,_identifier_>>
+and the terminating punctuation is a comma.
+
+==== Semantics
+
+Each identifier in the action sequence must
+<<Definitions_State-Machine-Definitions_Static-Semantics_Scoping-of-Names,refer>>
+to an
+<<State-Machine-Behavior-Elements_Action-Definitions,action definition>>.
+
+==== Examples
+
+[source,fpp]
+----
+state machine Device {
+
+  action powerActuator
+  action powerGyro
+  action powerGimbal
+
+  state ON {
+    entry do {
+      powerActuator
+      powerGyro
+      powerGimbal
+    }
+  }
+
+}
+----
diff --git a/docs/spec/State-Machine-Behavior-Elements/Guard-Definitions.adoc b/docs/spec/State-Machine-Behavior-Elements/Guard-Definitions.adoc
index fc0ca3627..2dc8b472c 100644
--- a/docs/spec/State-Machine-Behavior-Elements/Guard-Definitions.adoc
+++ b/docs/spec/State-Machine-Behavior-Elements/Guard-Definitions.adoc
@@ -5,7 +5,7 @@ A *guard definition* is part of a
 It defines a guard, i.e., a function that returns a Boolean value.
 Guards are associated with
 <<State-Machine-Behavior-Elements_State-Transition-Specifiers,state transitions>>
-and 
+and
 <<State-Machine-Behavior-Elements_Junction-Definitions,junctions>>.
 If the guard evaluates to `true`, then the state transition occurs
 or the branch of the junction is taken.
@@ -14,7 +14,7 @@ or the branch of the junction is taken.
 `guard`
 <<Lexical-Elements_Identifiers,_identifier_>>
 _[_
-`:` 
+`:`
 <<Type-Names,_type-name_>>
 _]_
 
@@ -25,7 +25,7 @@ _]_
 . If present, the optional type name specifies the type _T_ associated
 with the guard.
 A value of type _T_ will be passed into the guard function when it is called.
-If _type-name_ is not present, then there is no data associated with the 
+If _type-name_ is not present, then there is no data associated with the
 guard.
 
 ==== Examples
diff --git a/docs/spec/State-Machine-Behavior-Elements/Initial-Transition-Specifiers.adoc b/docs/spec/State-Machine-Behavior-Elements/Initial-Transition-Specifiers.adoc
index 61db8d1fe..ef90c5bdb 100644
--- a/docs/spec/State-Machine-Behavior-Elements/Initial-Transition-Specifiers.adoc
+++ b/docs/spec/State-Machine-Behavior-Elements/Initial-Transition-Specifiers.adoc
@@ -10,23 +10,38 @@ substates.
 
 ==== Syntax
 
-`initial` 
-<<State-Machine-Behavior-Elements_Enter-Expressions,_enter-expression_>>
+`initial`
+<<State-Machine-Behavior-Elements_Transition-Expressions,_transition-expression_>>
 
-==== Semantics
+==== Static Semantics
 
 The state definition or junction definition referred to in the
-enter expression must be a member of the same 
+transition expression must *lead to a member* of the same
 state machine definition or state definition in which the initial
 transition specifier appears.
 
+. A state definition _D_ leads to a member of a state machine definition _M_
+(respectively a state _S_) if _D_ is a member of _M_ (respectively _S_).
+
+. A junction definition _D_ leads to a member of a state machine definition _M_
+(respectively as state _S_) if it is a member of _M_ (respectively _S_)
+and the state or junction definitions referred to in _D_ lead to members of
+_M_ (respectively _S_).
+
+==== Dynamic Semantics
+
+To run an initial transition specifier _I_ with transition expression _E_,
+we <<State-Machine-Behavior-Elements_Transition-Expressions_Dynamic-Semantics,
+run _E_ in the context of _I_>>.
+
 ==== Examples
 
 [source,fpp]
 ----
 state machine Device {
 
-  action initDevices
+  action initDev1
+  action initDev2
 
   # When the state machine starts up, enter the ON state
   initial enter ON
@@ -34,7 +49,11 @@ state machine Device {
   state ON {
 
     # When entering the ON state, enter the POWERING_UP substate
-    initial do initDevices enter POWERING_UP
+    initial do {
+      initDev1
+      initDev2
+    } \
+    enter POWERING_UP
 
     state POWERING_UP
 
diff --git a/docs/spec/State-Machine-Behavior-Elements/Junction-Definitions.adoc b/docs/spec/State-Machine-Behavior-Elements/Junction-Definitions.adoc
index f0fe6e8a4..2e9284043 100644
--- a/docs/spec/State-Machine-Behavior-Elements/Junction-Definitions.adoc
+++ b/docs/spec/State-Machine-Behavior-Elements/Junction-Definitions.adoc
@@ -11,23 +11,40 @@ A junction is a branch point controlled by a
 
 `junction` <<Lexical-Elements_Identifiers,_identifier_>>
 `{`
-`if` <<Lexical-Elements_Identifiers,_identifier_>> <<State-Machine-Behavior-Elements_Enter-Expressions,_enter-expression_>>
-`else` <<State-Machine-Behavior-Elements_Enter-Expressions,_enter-expression_>>
+`if` <<Lexical-Elements_Identifiers,_identifier_>> <<State-Machine-Behavior-Elements_Transition-Expressions,_transition-expression_>>
+`else` <<State-Machine-Behavior-Elements_Transition-Expressions,_transition-expression_>>
 `}`
 
-==== Semantics
+==== Static Semantics
 
-. The identifier after the keyword `junction` is the name of the junction. 
+. The identifier after the keyword `junction` is the name of the junction.
 
 . The identifier after the keyword `if` must
-<<Definitions_State-Machine-Definitions_Scoping-of-Names,refer>>
+<<Definitions_State-Machine-Definitions_Static-Semantics_Scoping-of-Names,refer>>
 to a
 <<State-Machine-Behavior-Elements_Guard-Definitions,guard definition>>.
 It specifies the guard that controls the branch.
 
-. Each of the enter expressions must be valid.
-The first enter expression is run if the guard evaluates to `true`;
-otherwise the second enter expression is run.
+. Each of the transition expressions must be valid.
+The first transition expression is run if the guard evaluates to `true`;
+otherwise the second transition expression is run.
+
+==== Dynamic Semantics
+
+Each junction _J_ has the following *entry behavior*:
+
+. Evaluate the guard of _J_.
+
+. If _J_ evaluates to `true`, then
+<<State-Machine-Behavior-Elements_Transition-Expressions_Dynamic-Semantics,
+run the `if` transition expression in the context of _J_>>.
+
+. Otherwise run the `else` transition expression in the context of _J_.
+
+If any of the guard or the transition expressions requires a typed argument
+_v_, then according to the static semantics, _v_ must be available,
+and it must have a compatible type.
+Use _v_ to evaluate the guard or run the transition expression.
 
 ==== Examples
 
@@ -42,7 +59,7 @@ state machine Device {
 
   junction J1 {
     if coldStart enter OFF \
-    else do initPower enter ON
+    else do { initPower } enter ON
   }
 
   state OFF
diff --git a/docs/spec/State-Machine-Behavior-Elements/Signal-Definitions.adoc b/docs/spec/State-Machine-Behavior-Elements/Signal-Definitions.adoc
index c942a72ed..700b9f16b 100644
--- a/docs/spec/State-Machine-Behavior-Elements/Signal-Definitions.adoc
+++ b/docs/spec/State-Machine-Behavior-Elements/Signal-Definitions.adoc
@@ -22,7 +22,7 @@ for that state.
 `signal`
 <<Lexical-Elements_Identifiers,_identifier_>>
 _[_
-`:` 
+`:`
 <<Type-Names,_type-name_>>
 _]_
 
diff --git a/docs/spec/State-Machine-Behavior-Elements/State-Definitions.adoc b/docs/spec/State-Machine-Behavior-Elements/State-Definitions.adoc
index 6a45e8d2e..1dcb82672 100644
--- a/docs/spec/State-Machine-Behavior-Elements/State-Definitions.adoc
+++ b/docs/spec/State-Machine-Behavior-Elements/State-Definitions.adoc
@@ -1,6 +1,6 @@
 === State Definitions
 
-A *state definition* is part of a 
+A *state definition* is part of a
 <<Definitions_State-Machine-Definitions,state machine definition>>
 or
 <<State-Machine-Behavior-Elements_State-Definitions,state definition>>.
@@ -13,7 +13,7 @@ of states: _S'_ is a substate of _S_.
 `state` <<Lexical-Elements_Identifiers,_identifier_>>
 _[_ `{` _state-definition-member-sequence_ `}` _]_
 
-_state-definition-member-sequence_ is an 
+_state-definition-member-sequence_ is an
 <<Element-Sequences,element sequence>> in
 which each element is a *state definition member*,
 and the terminating punctuation is a semicolon.
@@ -23,66 +23,116 @@ A state definition member is one of the following:
 * A <<State-Machine-Behavior-Elements_Junction-Definitions,junction definition>>
 * A <<State-Machine-Behavior-Elements_State-Definitions,state definition>>
 * A <<State-Machine-Behavior-Elements_State-Transition-Specifiers,state transition specifier>>
+* A <<State-Machine-Behavior-Elements_State-Entry-Specifiers,state entry specifier>>
+* A <<State-Machine-Behavior-Elements_State-Exit-Specifiers,state exit specifier>>
 
-==== Semantics
+==== Static Semantics
 
 . The identifier is the name of the state.
 
 . If the state definition member sequence _M_ is present,
 then it must obey the following rules:
 
-.. _M_ must contain exactly one initial transition specifier _I_.
+.. If _M_ contains at least one state definition, then _M_ must contain exactly
+one initial transition specifier _I_.
 _I_ specifies the sub-state to enter on entry to the outer state.
 
+.. _M_ may not contain more than one state entry specifier.
+If _M_ has a state entry specifier _S_, then the *entry actions* of
+_M_ are the actions specified in _S_, in the order specified.
+Otherwise _M_ has no entry actions.
+
+.. _M_ may not contain more than one state exit specifier.
+If _M_ has a state exit specifier _S_, then the *exit actions* of
+_M_ are the actions specified in _S_, in the order specified.
+Otherwise _M_ has no exit actions.
+
 .. No two <<State-Machine-Behavior-Elements_State-Transition-Specifiers,state
 transition specifiers>> that are members of _M_ may
-<<Definitions_State-Machine-Definitions_Scoping-of-Names,refer>> to the same
+<<Definitions_State-Machine-Definitions_Static-Semantics_Scoping-of-Names,refer>> to the same
 signal definition.
 
+. If the state definition member sequence _M_ is present and _M_
+contains at least one state definition, then the
+state definition is called an *inner state definition*.
+Otherwise it is called a *leaf state definition*.
+
+==== Dynamic Semantics
+
+Each state definition _S_ has the following *entry behavior*:
+
+. Run the entry actions, if any, of _S_.
+According to the static semantics, the entry actions must
+not require a typed argument.
+
+. If _S_ is an inner state, then run the
+<<State-Machine-Behavior-Elements_Initial-Transition-Specifiers_Dynamic-Semantics,
+behavior>> of the initial transition of _S_.
+
+. Otherwise set the current state of the state machine to _S_.
+
 ==== Examples
 
 [source,fpp]
 ----
 state machine MonitorSm {
 
-  signal Complete
-  signal Drive
-  signal Calibrate
-  signal RTI
-  signal Stop
-  signal Fault
-  
-  action init2
   action doCalibrate
+  action heaterOff
+  action heaterOn
+  action init1
+  action init2
+  action monitorOff
+  action monitorOn
   action motorControl
   action reportFault
+  action stopMotor
 
   guard calibrateReady
 
+  signal Calibrate
+  signal Complete
+  signal Drive
+  signal Fault
+  signal RTI
+  signal Stop
+
   initial enter DEVICE_ON
-  
+
   state DEVICE_ON {
 
-    initial do init2 enter INITIALIZING
+    initial do {
+      init1
+      init2
+     } \
+     enter INITIALIZING
 
     state INITIALIZING {
       on Complete enter IDLE
     }
 
     state IDLE {
+      entry do {
+        heaterOff
+        monitorOff
+      }
+      exit do {
+        heaterOn
+        monitorOn
+      }
       on Drive enter DRIVING
       on Calibrate if calibrateReady enter CALIBRATING
     }
 
     state CALIBRATING {
-      on RTI do doCalibrate
-      on Fault do reportFault enter Idle
+      on RTI do { doCalibrate }
+      on Fault do { reportFault } enter Idle
       on Complete enter IDLE
     }
 
     state DRIVING {
-      on RTI do motorControl
-      on Stop enter IDLE
+      on RTI do { motorControl }
+      on Stop do { stopMotor } enter IDLE
     }
 
   }
diff --git a/docs/spec/State-Machine-Behavior-Elements/State-Entry-Specifiers.adoc b/docs/spec/State-Machine-Behavior-Elements/State-Entry-Specifiers.adoc
new file mode 100644
index 000000000..66c62c7c1
--- /dev/null
+++ b/docs/spec/State-Machine-Behavior-Elements/State-Entry-Specifiers.adoc
@@ -0,0 +1,33 @@
+=== State Entry Specifiers
+
+A *state entry specifier* is part of a
+<<State-Machine-Behavior-Elements_State-Definitions,state definition>>.
+It specifies the actions to take when entering the state.
+
+==== Syntax
+
+`entry` <<State-Machine-Behavior-Elements_Do-Expressions,_do-expression_>>
+
+==== Semantics
+
+The do expression must be valid.
+
+==== Examples
+
+[source,fpp]
+----
+state machine Device {
+
+  action heaterOn
+  action monitorOn
+
+  state RUNNING {
+    entry do {
+      heaterOn
+      monitorOn
+    }
+
+  }
+
+}
+----
diff --git a/docs/spec/State-Machine-Behavior-Elements/State-Exit-Specifiers.adoc b/docs/spec/State-Machine-Behavior-Elements/State-Exit-Specifiers.adoc
new file mode 100644
index 000000000..434c20fac
--- /dev/null
+++ b/docs/spec/State-Machine-Behavior-Elements/State-Exit-Specifiers.adoc
@@ -0,0 +1,33 @@
+=== State Exit Specifiers
+
+A *state exit specifier* is part of a
+<<State-Machine-Behavior-Elements_State-Definitions,state definition>>.
+It specifies the actions to take when exiting the state.
+
+==== Syntax
+
+`exit` <<State-Machine-Behavior-Elements_Do-Expressions,_do-expression_>>
+
+==== Semantics
+
+The do expression must be valid.
+
+==== Examples
+
+[source,fpp]
+----
+state machine Device {
+
+  action heaterOff
+  action monitorOff
+
+  state RUNNING {
+    exit do {
+      heaterOff
+      monitorOff
+    }
+
+  }
+
+}
+----
diff --git a/docs/spec/State-Machine-Behavior-Elements/State-Transition-Specifiers.adoc b/docs/spec/State-Machine-Behavior-Elements/State-Transition-Specifiers.adoc
index 333ded90e..91540edb5 100644
--- a/docs/spec/State-Machine-Behavior-Elements/State-Transition-Specifiers.adoc
+++ b/docs/spec/State-Machine-Behavior-Elements/State-Transition-Specifiers.adoc
@@ -10,43 +10,86 @@ It specifies a transition from the state in which it appears.
 _[_
 `if` <<Lexical-Elements_Identifiers,_identifier_>>
 _]_
-_enter-or-do_
+_transition-or-do_
 
-_enter-or-do_ is one of the following:
+_transition-or-do_ is one of the following:
 
-.  <<State-Machine-Behavior-Elements_Enter-Expressions,_enter-expression_>>
+.  <<State-Machine-Behavior-Elements_Transition-Expressions,_transition-expression_>>
 
-.  `do` <<Lexical-Elements_Identifiers,_identifier_>>
+.  <<State-Machine-Behavior-Elements_Do-Expressions,_do-expression_>>
 
-==== Semantics
+==== Static Semantics
 
 . The identifier after the keyword `on` must
-<<Definitions_State-Machine-Definitions_Scoping-of-Names,refer>>
+<<Definitions_State-Machine-Definitions_Static-Semantics_Scoping-of-Names,refer>>
 to a
 <<State-Machine-Behavior-Elements_Signal-Definitions,signal definition>>.
 It names the signal that causes the transition to occur.
 
 . If present, the optional identifier after the keyword `if` must
-<<Definitions_State-Machine-Definitions_Scoping-of-Names,refer>>
+<<Definitions_State-Machine-Definitions_Static-Semantics_Scoping-of-Names,refer>>
 to a
 <<State-Machine-Behavior-Elements_Guard-Definitions,guard definition>>.
 It specifies a guard for the transition.
 
-. The first form of the syntax specifies a target state and an optional action.
-The enter expression must be valid.
-The target state in the enter expression may be the same as the
-enclosing state; in this case the transition is called a *self transition*.
-When making a self transition, the state machine runs the code associated with
-exiting and then re-entering the state.
+. The first form of the _transition-or-do_ syntax specifies an *external
+transition*, i.e., an optional list of actions and a target state or junction.
 
-. Second form of the syntax specifies an
-*internal transition*, i.e., an action to take while remaining
+. The second form of the _transition-or-do_ syntax specifies an
+*internal transition*, i.e., a list of actions to take while remaining
 in the same state.
-When making an internal transition, the exit and re-entry code is not run.
-The identifier after the keyword `do` must
-<<Definitions_State-Machine-Definitions_Scoping-of-Names,refer>>
-to an
-<<State-Machine-Behavior-Elements_Action-Definitions,action definition>>.
+The do expression must be valid.
+
+==== The State Transition Map
+
+The set of all state transition specifiers in a state machine
+induces a *state transition map* _m: Signal x State -> GuardedTransition_,
+where a guarded transition is a pair consisting of an optional guard
+and a transition or do expression.
+The map _m_ is constructed as follows.
+Let _T_ be a state transition specifier with signal _s_, optional guard _g_,
+and transition or do expression _t_, defined in state _S_.
+
+. If _S_ is a leaf state, then _m_ maps _(s, S)_ to _(g, t)_.
+
+. Otherwise, for each leaf state _S~i~_ that is transitively
+contained in _S_, _m_ maps _(s, S~i~)_ to _(g, t)_, unless
+the mapping is overridden.
+Overriding occurs when another state _S'_ that is transitively contained in _S_
+maps _(s, S~i~)_ to _(g',t')_ according to items (1) or (2).
+In that case, the mapping lower in the hierarchy takes precedence.
+This overriding behavior is called *behavioral polymorphism*.
+
+==== Dynamic Semantics
+
+Let _M_ be a state machine.
+Suppose _M_ is in state _S_.
+Let _m_ be the state transition map of _M_, defined in the previous section.
+Let _s_ be a signal of _M_.
+*Sending* signal _s_ to _M_ results in the following behavior:
+
+. If _(s,S)_ is not in the domain of _m_, then do nothing.
+
+. Otherwise
+
+.. Let _(g,t) =  m(s,S)_.
+
+.. Evaluate the guard _g_.
+If the result is `false`, then do nothing.
+Otherwise
+
+... If _t_ is a do expression _E_, then perform the actions
+listed in _E_, if any, in the order listed.
+
+... Otherwise _t_ is a transition expression _E_.
+<<State-Machine-Behavior-Elements_Transition-Expressions_Dynamic-Semantics,
+Run _E_ in the context of _S_>>.
+
+If any of the guard, do expression, or transition expression requires a
+typed argument _v_, then according to the static semantics, _v_ must
+be available, and it must have a compatible type.
+Use _v_ to evaluate the guard, run the do expression, or run
+the transition expression.
 
 ==== Examples
 
@@ -54,22 +97,27 @@ to an
 ----
 state machine Device {
 
-  signal RTI
-  signal PowerOn
-  
   action performStuff
-  action getReady
+  action powerHeater
+  action powerSensor
 
   guard initComplete
 
+  signal PowerOn
+  signal RTI
+
   initial enter OFF
 
   state OFF {
-    on PowerOn if initComplete do getReady enter ON
+    on PowerOn if initComplete do {
+      powerHeater
+      powerSensor
+    } \
+    enter ON
   }
 
   state ON {
-    on RTI do performStuff
+    on RTI do { performStuff }
   }
 
 }
diff --git a/docs/spec/State-Machine-Behavior-Elements/Transition-Expressions.adoc b/docs/spec/State-Machine-Behavior-Elements/Transition-Expressions.adoc
new file mode 100644
index 000000000..c1bfadb05
--- /dev/null
+++ b/docs/spec/State-Machine-Behavior-Elements/Transition-Expressions.adoc
@@ -0,0 +1,112 @@
+=== Transition Expressions
+
+An *transition expression* specifies a transition as part of an
+<<State-Machine-Behavior-Elements_Initial-Transition-Specifiers,initial transition>>,
+a <<State-Machine-Behavior-Elements_State-Transition-Specifiers,state transition>>,
+or
+a <<State-Machine-Behavior-Elements_Junction-Definitions,junction>>.
+The transition performs zero or more actions and then
+enters a state or junction.
+
+==== Syntax
+
+_[_
+<<State-Machine-Behavior-Elements_Do-Expressions,_do-expression_>>
+_]_
+`enter` <<Scoping-of-Names_Qualified-Identifiers,_qual-ident_>>
+
+
+==== Static Semantics
+
+. The do expression specifies the list of actions to be
+performed when making the transition.
+If there are no actions, the do expression may be omitted.
+
+. The qualified identifier after the keyword `enter` must
+<<Definitions_State-Machine-Definitions_Static-Semantics_Scoping-of-Names,refer>>
+to a
+<<State-Machine-Behavior-Elements_State-Definitions,state definition>>
+or a
+<<State-Machine-Behavior-Elements_Junction-Definitions,junction definition>>
+It is the state or junction that is entered in the transition.
+
+==== Dynamic Semantics
+
+A transition expression _E_ is run in the context of an
+initial transition specifier, a leaf state definition,
+or a junction definition.
+
+. To run _E_ in the context of an initial transition specifier
+_I_, do the following:
+
+.. Perform the actions, if any, specified in _E_, in the order specified.
+
+.. Run the entry behavior of the
+<<State-Machine-Behavior-Elements_State-Definitions_Dynamic-Semantics,state>>
+or
+<<State-Machine-Behavior-Elements_Junction-Definitions_Dynamic-Semantics,junction>>
+referred to in _E_.
+
++
+According to the static semantics, actions and the entry behavior must not require
+a typed argument.
+
+. To run _E_ in the context of a leaf state definition or junction definition _D_,
+do the following:
+
+.. Let _T_ be the state or junction which is the target of _E_.
+
+.. Let _P_ be the *lowest common ancestor* of _D_ and _T_.
+The lowest common ancestor is defined as follows:
+
+... A *point in the state hierarchy* is either the entire state machine
+or a state definition.
+
+... The lowest common ancestor of _D_ and _T_ is the lowest
+point in the state hierarchy such that (A)
+by descending from _P_ at least once it is possible to reach _D_ and (B)
+by descending from _P_ at least once it is possible to reach _T_.
+
+.. Ascend through the state hierarchy from _D_ to _P_.
+When passing out of a state _S_, perform the
+<<State-Machine-Behavior-Elements_State-Definitions_Static-Semantics,
+exit actions>> of _S_, in the order specified.
+
+.. Perform the actions, if any, specified in _E_, in the order specified.
+
+.. Descend through the state hierarchy from _P_ to the point just above _T_.
+When passing into a state _S_, perform the
+<<State-Machine-Behavior-Elements_State-Definitions_Static-Semantics,
+entry actions>> of _S_, in the order specified.
+
+.. Run the entry behavior of the
+<<State-Machine-Behavior-Elements_State-Definitions_Dynamic-Semantics,state>>
+or
+<<State-Machine-Behavior-Elements_Junction-Definitions_Dynamic-Semantics,junction>>
+_T_.
+
++
+According to the static semantics, if any of the actions or the
+entry behavior requires a typed argument _v_, then _v_ must
+be available, and it must have a compatible type.
+Use _v_ to call the action or run the behavior.
+
+==== Examples
+
+[source,fpp]
+----
+state machine Device {
+
+  action initDev1
+  action initDev2
+
+  initial do {
+    initDev1
+    initDev2
+  } \
+  enter OFF
+
+  state OFF
+
+}
+----
diff --git a/docs/spec/State-Machine-Behavior-Elements/defs.sh b/docs/spec/State-Machine-Behavior-Elements/defs.sh
index 80575b2d4..1f98e1543 100644
--- a/docs/spec/State-Machine-Behavior-Elements/defs.sh
+++ b/docs/spec/State-Machine-Behavior-Elements/defs.sh
@@ -9,11 +9,14 @@ redo-ifchange defs.sh
 export FILES="
 Introduction.adoc
 Action-Definitions.adoc
-Enter-Expressions.adoc
+Do-Expressions.adoc
 Guard-Definitions.adoc
 Initial-Transition-Specifiers.adoc
 Junction-Definitions.adoc
 Signal-Definitions.adoc
 State-Definitions.adoc
+State-Entry-Specifiers.adoc
+State-Exit-Specifiers.adoc
 State-Transition-Specifiers.adoc
+Transition-Expressions.adoc
 "
diff --git a/docs/spec/Translation-Units-and-Models.adoc b/docs/spec/Translation-Units-and-Models.adoc
index 5b05799e7..9f52258f6 100644
--- a/docs/spec/Translation-Units-and-Models.adoc
+++ b/docs/spec/Translation-Units-and-Models.adoc
@@ -11,7 +11,7 @@ e.g., on standard input.
 ==== Syntax
 
 A translation unit is an
-<<Element-Sequences,element sequence>> in which each 
+<<Element-Sequences,element sequence>> in which each
 element is a *translation unit member*,
 and the terminating punctuation is a semicolon.
 A translation unit member is syntactically identical to a
@@ -37,7 +37,7 @@ And here is a third one:
 
 [source,fpp]
 ----
-module M2 { 
+module M2 {
   constant a = M1.a
   constant b = M1.b
 }
@@ -68,14 +68,14 @@ unit:
 ----
 module M1 { constant a = 0 }
 module M1 { constant b = 1 }
-module M2 { 
+module M2 {
   constant a = M1.a
   constant b = M1.b
 }
 ----
 
 According to the
-<<Scoping-of-Names_Multiple-Definitions-with-the-Same-Qualified-Name_Module-Definitions,semantics 
+<<Scoping-of-Names_Multiple-Definitions-with-the-Same-Qualified-Name_Module-Definitions,semantics
 of module definitions>>,
 this is also equivalent:
 
@@ -85,7 +85,7 @@ module M1 {
   constant a = 0
   constant b = 1
 }
-module M2 { 
+module M2 {
   constant a = M1.a
   constant b = M1.b
 }
@@ -100,12 +100,12 @@ unit 2 is not a valid model.
 
 Every syntactic element _E_ in a source model has an associated
 *location* _L_.
-The location is used when resolving <<Specifiers_Location-Specifiers,location 
+The location is used when resolving <<Specifiers_Location-Specifiers,location
 specifiers>> and
 <<Specifiers_Include-Specifiers,include specifiers>>
 during <<Analysis-and-Translation,analysis>>.
 
-. If _E_ is read in from a file, then _L_ is the absolute path 
+. If _E_ is read in from a file, then _L_ is the absolute path
 of the file.
 
 . If _E_ is read from standard input, then _L_ is the absolute path of the current
diff --git a/docs/spec/Type-Checking.adoc b/docs/spec/Type-Checking.adoc
index a36093034..9f402338e 100644
--- a/docs/spec/Type-Checking.adoc
+++ b/docs/spec/Type-Checking.adoc
@@ -4,7 +4,7 @@ In this section, we explain the rules used to assign types to
 expressions. FPP is a statically typed language. That means the
 following:
 
-* Type checking of expressions occurs during 
+* Type checking of expressions occurs during
 <<Analysis-and-Translation_Analysis,analysis>>.
 
 * If the type checking phase detects a violation of any of these rules,
@@ -58,9 +58,9 @@ literal expression>> is `string`.
 
 === Identifier Expressions
 
-To type an <<Expressions_Identifier-Expressions,identifier 
-expression>> stem:[e], the semantic analyzer 
-<<Scoping-of-Names_Resolution-of-Identifiers,resolves the identifier to a 
+To type an <<Expressions_Identifier-Expressions,identifier
+expression>> stem:[e], the semantic analyzer
+<<Scoping-of-Names_Resolution-of-Identifiers,resolves the identifier to a
 definition>> and uses the type given in the definition.
 
 **Example:**
@@ -78,7 +78,7 @@ To type a
 expression>> stem:[e] `.x`, the semantic analyzer does the following:
 
 . If stem:[e]`.x` is a
-<<Scoping-of-Names_Qualified-Identifiers,qualified identifier>> that represents 
+<<Scoping-of-Names_Qualified-Identifiers,qualified identifier>> that represents
 the use of a definition according to the
 <<Scoping-of-Names_Resolution-of-Qualified-Identifiers,rules
 for resolving qualified identifiers>>, and the use is a valid
@@ -91,7 +91,7 @@ expression>>, then use the type given in the definition.
 
 [source,fpp]
 ----
-module M { 
+module M {
   constant a = 0 # The constant M.a has type Integer
 }
 constant b = M.a # Expression M.a represents a use of the definition M.a.
@@ -153,7 +153,7 @@ negation expression>> `-` stem:[e], the semantic analyzer does the following:
 
 . If stem:[T] is a <<Types_Internal-Types_Numeric-Types,numeric type>>, then use stem:[T].
 
-. Otherwise if stem:[T] <<Type-Checking_Type-Conversion,may be converted to>> 
+. Otherwise if stem:[T] <<Type-Checking_Type-Conversion,may be converted to>>
 _Integer_, then use _Integer_.
 
 . Otherwise throw an error.
@@ -175,14 +175,14 @@ constant f = -true # Error
 
 To type a
 <<Expressions_Arithmetic-Expressions,binary
-arithmetic expression>> stem:[e_1] _op_ stem:[e_2], the semantic analyzer does 
+arithmetic expression>> stem:[e_1] _op_ stem:[e_2], the semantic analyzer does
 the following:
 
 . Compute the common type stem:[T] of stem:[e_1] and stem:[e_2].
 
 . If stem:[T] is a <<Types_Internal-Types_Numeric-Types,numeric type>>, then use stem:[T].
 
-. Otherwise if stem:[T] <<Type-Checking_Type-Conversion,may be converted to>> 
+. Otherwise if stem:[T] <<Type-Checking_Type-Conversion,may be converted to>>
 _Integer_, then use _Integer_.
 
 . Otherwise throw an error.
@@ -225,10 +225,10 @@ constant e = ([ 1, 2, 3]) # Type is [3] Integer
 We say that types stem:[T_1] and stem:[T_2] are *identical* if one
 of the following holds:
 
-. stem:[T_1] and stem:[T_2] are 
+. stem:[T_1] and stem:[T_2] are
 <<Types_Internal-Types_Numeric-Types,numeric types>>
 with the same name, e.g., `U32` or _Integer_.
-In each case of a numeric type, the name of the type uniquely identifies 
+In each case of a numeric type, the name of the type uniquely identifies
 the type.
 
 . stem:[T_1] and stem:[T_2]
@@ -266,11 +266,11 @@ type>> may be converted to any other numeric type.
 . An <<Types_Enum-Types,enum type>> may be converted to a
 <<Types_Internal-Types_Numeric-Types,numeric type>>.
 
-. If stem:[T_1] or stem:[T_2] or both are 
+. If stem:[T_1] or stem:[T_2] or both are
 <<Types_Array-Types,array types>>, then
 stem:[T_1] may be converted to stem:[T_2] if the conversion
 is allowed after replacing the array type or types with
-structurally equivalent 
+structurally equivalent
 <<Types_Internal-Types_Anonymous-Array-Types,anonymous array types>>.
 
 . An anonymous array type stem:[T_1 =] _[_ stem:[n] _]_ stem:[T'_1]
@@ -278,17 +278,17 @@ may be converted to the anonymous array type
 stem:[T_2 =] _[_ stem:[m] _]_ stem:[T'_2]
 if stem:[n = m] and stem:[T'_1] may be converted to stem:[T'_2].
 
-. A <<Types_Internal-Types_Numeric-Types,numeric type>> type, <<Types_The-Boolean-Type,Boolean 
+. A <<Types_Internal-Types_Numeric-Types,numeric type>> type, <<Types_The-Boolean-Type,Boolean
 type>>,
-<<Types_Enum-Types,enum type>>, or <<Types_String-Types,string types>> stem:[T] 
+<<Types_Enum-Types,enum type>>, or <<Types_String-Types,string types>> stem:[T]
 may be converted to an anonymous array type
 stem:[T_1] may be converted to the member type of stem:[T_2].
 
-. If stem:[T_1] or stem:[T_2] or both are 
+. If stem:[T_1] or stem:[T_2] or both are
 <<Types_Struct-Types,struct types>>, then
 stem:[T_1] may be converted to stem:[T_2] if the conversion
 is allowed after replacing the struct type or types with
-structurally equivalent 
+structurally equivalent
 <<Types_Internal-Types_Anonymous-Struct-Types,anonymous struct types>>.
 For purposes of structural equivalence, the member sizes of
 struct types are ignored.
@@ -296,8 +296,8 @@ For example, the struct type `S` defined by `struct S { x: [3] U32 }`
 is structurally equivalent to the anonymous struct type
 `{ x: U32 }`.
 
-. An anonymous struct type 
-stem:[T =]_{_ stem:[m_1] _:_ stem:[T_1] _,_ 
+. An anonymous struct type
+stem:[T =]_{_ stem:[m_1] _:_ stem:[T_1] _,_
 stem:[...] _,_ stem:[m_1] _:_ stem:[T_n] _}_ may be converted to
 the anonymous struct type stem:[T'] if for each stem:[i in [1,n\]],
 
@@ -305,30 +305,30 @@ the anonymous struct type stem:[T'] if for each stem:[i in [1,n\]],
 
 .. stem:[T_i] may be converted to stem:[T'_i].
 
-. A <<Types_Internal-Types_Numeric-Types,numeric type>> type, <<Types_The-Boolean-Type,Boolean 
+. A <<Types_Internal-Types_Numeric-Types,numeric type>> type, <<Types_The-Boolean-Type,Boolean
 type>>,
-<<Types_Enum-Types,enum type>>, or <<Types_String-Types,string type>> stem:[T] 
+<<Types_Enum-Types,enum type>>, or <<Types_String-Types,string type>> stem:[T]
 may be converted to an
 <<Types_Internal-Types_Anonymous-Struct-Types,anonymous struct type>> stem:[T'] if
 for each member stem:[m_i] `:` stem:[T_i] of stem:[T'],
 stem:[T] may be converted to stem:[T_i].
 
-. Type convertibility is transitive: if stem:[T_1] may be converted to 
+. Type convertibility is transitive: if stem:[T_1] may be converted to
 stem:[T_2]
-and stem:[T_2] may be converted to stem:[T_3], then stem:[T_1] 
+and stem:[T_2] may be converted to stem:[T_3], then stem:[T_1]
 may be converted to stem:[T_3].
 
 === Computing a Common Type
 
 ==== Pairs of Types
 
-Here are the rules for resolving two types stem:[T_1] and stem:[T_2] 
+Here are the rules for resolving two types stem:[T_1] and stem:[T_2]
 (e.g., the
-types of two subexpressions) to a common type stem:[T] (e.g., the type of 
+types of two subexpressions) to a common type stem:[T] (e.g., the type of
 the whole expression):
 
 . If stem:[T_1] and stem:[T_2] are
-<<Type-Checking_Identical-Types,identical types>>, then let 
+<<Type-Checking_Identical-Types,identical types>>, then let
 stem:[T] be stem:[T_1].
 
 . Otherwise if stem:[T_1] and stem:[T_2] are both
@@ -341,7 +341,7 @@ stem:[T] be stem:[T_1].
 . Otherwise if stem:[T_1] and stem:[T_2] are both
 <<Types_String-Types,string types>>, then use `string`.
 
-. Otherwise if stem:[T_1] or stem:[T_2] or both are enum types, then replace 
+. Otherwise if stem:[T_1] or stem:[T_2] or both are enum types, then replace
 the enum type or types with the representation type specified in the enum definitions and
 and reapply these rules.
 
@@ -353,12 +353,12 @@ anonymous array types and reapply these rules.
 and with member types stem:[T'_1] and stem:[T'_2], then apply these rules to resolve
 stem:[T'_1] and stem:[T'_2] to stem:[T'] and let stem:[T] be _[_ stem:[n] _]_ stem:[T'].
 
-. Otherwise if one of stem:[T_1] and stem:[T_2] is a type stem:[T'] that is 
+. Otherwise if one of stem:[T_1] and stem:[T_2] is a type stem:[T'] that is
 convertible to an anonymous array type
 and the other
-one is an anonymous array type _[_ stem:[n] _]_ stem:[T''], then apply these 
+one is an anonymous array type _[_ stem:[n] _]_ stem:[T''], then apply these
 rules to resolve
-stem:[T'] and stem:[T''] to a common type stem:[T''']. Let stem:[T] be 
+stem:[T'] and stem:[T''] to a common type stem:[T''']. Let stem:[T] be
 the
 array type _[_ stem:[n] _]_ stem:[T'''].
 
@@ -378,11 +378,11 @@ use stem:[m_1] _:_ stem:[T']. Otherwise use stem:[m_1] _:_ stem:[T'_1].
 that stem:[T_1] has no member named stem:[m_2],
 use stem:[m_2] _:_ stem:[T'_2].
 
-. Otherwise if one of stem:[T_1] and stem:[T_2] is a type stem:[T'] that is 
+. Otherwise if one of stem:[T_1] and stem:[T_2] is a type stem:[T'] that is
 convertible to an anonymous struct type and the other
-one is an anonymous struct type stem:[S], then apply these rules to resolve 
+one is an anonymous struct type stem:[S], then apply these rules to resolve
 stem:[T'] and each of the struct member types to a common type.
-Let stem:[T] be the struct type whose member names are the member names of 
+Let stem:[T] be the struct type whose member names are the member names of
 stem:[S] and
 whose member types are the corresponding common types.
 
@@ -395,13 +395,10 @@ stem:[T_1, ... , T_n], do the following:
 
 .  Check that stem:[n > 0]. If not, then throw an error.
 
-.  Compute the type stem:[T_1] of stem:[e_1].
+. Let stem:[T'_1] be stem:[T_1].
 
-.  For each stem:[i in [2,n]]
+.  For each stem:[i in [2,n]], compute the
+<<Type-Options_Computing-a-Common-Type-Option,
+common type option>> stem:[T'_i] of stem:[T'_(i-1)] and stem:[T_i].
 
-   ..  Compute the type stem:[T] of stem:[e_i].
-
-   ..  Compute the <<Type-Checking_Computing-a-Common-Type,common type>>
-stem:[T_i] of stem:[T_(i-1)] and stem:[T].
-
-.  Use stem:[T_n] as the common type of the list.
+.  Use stem:[T'_n] as the common type option of the list.
diff --git a/docs/spec/Type-Options.adoc b/docs/spec/Type-Options.adoc
new file mode 100644
index 000000000..51b69950c
--- /dev/null
+++ b/docs/spec/Type-Options.adoc
@@ -0,0 +1,88 @@
+== Type Options
+
+A *type option* is one of the following:
+
+. _Some_ stem:[T], representing a value of type stem:[T].
+
+. _None_, representing no value.
+
+Type options are used to specify the optional types associated with
+signals, actions, and guards in <<Definitions_State-Machine-Definitions,state
+machine definitions>>.
+
+=== Conversion of Type Options
+
+We say that a type option stem:[O_1] *may be converted to* another type option
+stem:[O_2] in the following cases.
+
+. Any type option may be converted to _None_.
+
+. _Some_ stem:[T_1] may be converted to _Some_ stem:[T_2] in the following cases:
+
+.. stem:[T_1] and stem:[T_2] are <<Type-Checking_Identical-Types,identical types>>.
+
+.. stem:[T_1] and stem:[T_2] are both
+<<Types_Primitive-Integer-Types,signed primitive integer types>>,
+and stem:[T_2] is at least as wide as stem:[T_1].
+
+.. stem:[T_1] and stem:[T_2] are both
+<<Types_Primitive-Integer-Types,unsigned primitive integer types>>,
+and stem:[T_2] is at least as wide as stem:[T_1].
+
+.. stem:[T_1] and stem:[T_2] are both
+<<Types_Floating-Point-Types,floating-point types>>,
+and stem:[T_2] is at least as wide as stem:[T_1].
+
+.. stem:[T_1] and stem:[T_2] are both <<Types_String-Types,string types>>.
+
+=== Computing a Common Type Option
+
+==== Pairs of Type Options
+
+Here are the rules for resolving two type options stem:[O_1] and stem:[O_2] to
+a common type option stem:[O]:
+
+. If either or both of stem:[O_1] and stem:[O_2] is _None_, then
+let stem:[O] be _None_.
+
+. Otherwise let stem:[O_1] be _Some_ stem:[T_1], and let
+stem:[O_2] be _Some_ stem:[T_2].
+Let stem:[O] be _Some_ stem:[T], where stem:[T]
+is computed as follows:
+
+.. If stem:[T_1] and stem:[T_2] are <<Type-Checking_Identical-Types,identical types>>,
+then let stem:[T] be stem:[T_1].
+
+.. Otherwise if stem:[T_1] and stem:[T_2] are both
+<<Types_Primitive-Integer-Types,signed primitive integer types>>,
+then let stem:[T] be the wider of the two types.
+
+.. Otherwise if stem:[T_1] and stem:[T_2] are both
+<<Types_Primitive-Integer-Types,unsigned primitive integer types>>,
+then let stem:[T] be the wider of the two types.
+
+.. Otherwise if stem:[T_1] and stem:[T_2] are both
+<<Types_Floating-Point-Types,floating-point types>>,
+then let stem:[T] be the wider of the two types.
+
+.. Otherwise if stem:[T_1] and stem:[T_2] are both
+<<Types_String-Types,string types>>, then
+then let stem:[T] be `string`.
+
+.. Otherwise the attempted resolution is invalid.
+Throw an error.
+
+==== Lists of Type Options
+
+To compute a common type for a list of type options
+stem:[O_1, ... , O_n], do the following:
+
+.  Check that stem:[n > 0]. If not, then throw an error.
+
+. Let stem:[O'_1] be stem:[O_1].
+
+.  For each stem:[i in [2,n]], compute the
+<<Type-Checking_Computing-a-Common-Type,common type>> stem:[O'_i] of
+stem:[O'_(i-1)] and stem:[O_i].
+
+.  Use stem:[O'_n] as the common type of the list.
diff --git a/docs/spec/Types.adoc b/docs/spec/Types.adoc
index 8c57423d3..695d4ada8 100644
--- a/docs/spec/Types.adoc
+++ b/docs/spec/Types.adoc
@@ -2,9 +2,11 @@
 
 === Primitive Integer Types
 
-The *primitive integer types* correspond to the 
+The *primitive integer types* correspond to the
 <<Type-Names_Primitive-Integer-Type-Names,primitive integer type names>>
 and are written in the same way, e.g., `U32`.
+The primitive integer types whose names start with `I` are *signed*.
+The primitive integer types whose names start with `U` are *unsigned*.
 
 === Floating-Point Types
 
@@ -15,7 +17,7 @@ and are written in the same way, e.g., `F64`.
 === Primitive Numeric Types
 
 The <<Types_Primitive-Integer-Types,primitive integer types>>
-together with the <<Types_Floating-Point-Types,floating-point types>> are 
+together with the <<Types_Floating-Point-Types,floating-point types>> are
 called the *primitive numeric types*.
 
 === The Boolean Type
@@ -47,7 +49,7 @@ An *array type* is a type associated with an
 There is one array type per array definition.
 Each array type is computed after resolving constants,
 so an array type has a constant integer value for its size.
-An array type is written using its 
+An array type is written using its
 <<Scoping-of-Names_Names-of-Definitions,unique qualified
 name>>.
 
@@ -74,7 +76,7 @@ name>>.
 An *abstract type* is a type associated with an
 <<Definitions_Abstract-Type-Definitions,abstract type definition>>.
 There is is one abstract type per abstract type definition.
-An abstract type is written using its 
+An abstract type is written using its
 <<Scoping-of-Names_Names-of-Definitions,unique qualified
 name>>.
 
@@ -90,13 +92,13 @@ to bit width.
 
 ==== Integer Types
 
-<<Types_Internal-Types_Integer,_Integer_>> together with the 
+<<Types_Internal-Types_Integer,_Integer_>> together with the
 <<Types_Primitive-Integer-Types,primitive integer types>> are called
 the *integer types*.
 
 ==== Numeric Types
 
-<<Types_Internal-Types_Integer,_Integer_>> together with the 
+<<Types_Internal-Types_Integer,_Integer_>> together with the
 <<Types_Primitive-Numeric-Types,primitive numeric types>> are called
 the *numeric types*.
 
@@ -135,24 +137,24 @@ A type *has numeric members* if it is one of the following:
 * A <<Types_Internal-Types_Numeric-Types,numeric type>>.
 
 * An <<Types_Array-Types,array type>> or
-<<Types_Internal-Types_Anonymous-Array-Types,anonymous array type>> whose 
+<<Types_Internal-Types_Anonymous-Array-Types,anonymous array type>> whose
 member type has numeric members.
 
 * A <<Types_Struct-Types,struct type>> or
-<<Types_Internal-Types_Anonymous-Struct-Types,anonymous struct type>> whose 
+<<Types_Internal-Types_Anonymous-Struct-Types,anonymous struct type>> whose
 member types all have numeric members.
 
 === Default Values
 
-Every type _T_ with a syntactic name in FPP has an associated *default 
+Every type _T_ with a syntactic name in FPP has an associated *default
 value*.
-In generated C++ code, this is the value that is used to initialize a variable 
+In generated C++ code, this is the value that is used to initialize a variable
 of type _T_
 when no other initializer is specified.
 Default values are important, because they ensure that in generated code,
 every variable is initialized when it is created.
 
-* The default value associated with each 
+* The default value associated with each
 <<Types_Primitive-Numeric-Types,primitive numeric type>> is zero.
 
 * The default value associated with
@@ -172,7 +174,7 @@ array definitions>> for examples.
 
 * The default value associated with an
 <<Types_Enum-Types,enum type>> is (1) the default value
-specified in the enum definition, if one is given; 
+specified in the enum definition, if one is given;
 otherwise (2) the first
 enumerated constant appearing in the enum definition.
 
diff --git a/docs/spec/Values.adoc b/docs/spec/Values.adoc
index ab645bace..fefb79ebe 100644
--- a/docs/spec/Values.adoc
+++ b/docs/spec/Values.adoc
@@ -28,15 +28,15 @@ Every value belongs to exactly one type.
 
 === Primitive Integer Values
 
-A *primitive integer value* is an ordinary (mathematical) integer value 
+A *primitive integer value* is an ordinary (mathematical) integer value
 together with a
-<<Types_Primitive-Integer-Types,primitive integer type>>. Formally, the set of 
+<<Types_Primitive-Integer-Types,primitive integer type>>. Formally, the set of
 primitive integer values
 is the disjoint union over the integer types of the values
 represented by each type:
 
-* An unsigned integer type of width stem:[w] represents integers in the 
-range stem:[[0, 2^w-1\]]. For example, `U8` represents the integers 
+* An unsigned integer type of width stem:[w] represents integers in the
+range stem:[[0, 2^w-1\]]. For example, `U8` represents the integers
 stem:[[0, 255\]].
 
 * A signed integer type of width stem:[w] represents integers in the range
@@ -64,7 +64,7 @@ over the types `F32` and `F64` of the values represented by each type:
 
 * The type `F64` represents all IEEE 8-byte floating-point values.
 
-We write a floating-point values analogously to primitive integer values. For 
+We write a floating-point values analogously to primitive integer values. For
 example, we write the value 1.0 at type `F32` as `1.0: F32`.
 
 === Boolean Values
@@ -93,19 +93,19 @@ An *anonymous array value* is a value associated with an anonymous
 array type.
 We write an anonymous array value similarly to an
 <<Expressions_Array-Expressions,array expression>>:
-an anonymous array value has the form `[` stem:[v_1] `,` stem:[...] `,` 
-stem:[v_n] `]`, where for each stem:[i in [1,n]], stem:[v_i] is a value of type 
+an anonymous array value has the form `[` stem:[v_1] `,` stem:[...] `,`
+stem:[v_n] `]`, where for each stem:[i in [1,n]], stem:[v_i] is a value of type
 stem:[T] for some stem:[T].
 The type of the value is _[_ stem:[n] _]_ stem:[T].
 
 === Array Values
 
 An *array value* is a value associated with an array type.
-We write an array value like an <<Values_Anonymous-Array-Values,anonymous array 
+We write an array value like an <<Values_Anonymous-Array-Values,anonymous array
 value>>, except that the value is annotated with an
 <<Types_Array-Types,array type>>.
 
-An array value has the form `[` stem:[v_1] `,` stem:[...] `,` 
+An array value has the form `[` stem:[v_1] `,` stem:[...] `,`
 stem:[v_n] `]` `:` stem:[Q],
 where
 
@@ -136,7 +136,7 @@ An *anonymous struct value* is a value associated with an
 type>>.
 We write an anonymous struct value stem:[v] similarly to a
 <<Expressions_Struct-Expressions,struct expression>>:
-a struct value has the form `{` stem:[m_1] `=` stem:[v_1] `,` stem:[...] `,` 
+a struct value has the form `{` stem:[m_1] `=` stem:[v_1] `,` stem:[...] `,`
 stem:[m_n] `=` stem:[v_n] `}`,
 where for each stem:[i in [1,n]], stem:[v_i] is a value of type stem:[T_i].
 The type of stem:[v] is _{_ stem:[m_1] _:_ stem:[T_1] _,_ stem:[...] _,_
@@ -149,7 +149,7 @@ A *struct value* is a value associated with a
 We write a struct value similarly to an
 <<Values_Struct-Values,anonymous struct value>>,
 except that we annotate the value with a struct type:
-a struct value has the form `{` stem:[m_1] `:` stem:[v_1] `,` stem:[...] `,` 
+a struct value has the form `{` stem:[m_1] `:` stem:[v_1] `,` stem:[...] `,`
 stem:[m_n] `:` stem:[v_n] `}` `:` stem:[Q],
 where
 
diff --git a/docs/spec/defs.sh b/docs/spec/defs.sh
index 00ee3494b..3285c6fbf 100644
--- a/docs/spec/defs.sh
+++ b/docs/spec/defs.sh
@@ -28,6 +28,7 @@ Scoping-of-Names.adoc
 Definitions-and-Uses.adoc
 Types.adoc
 Type-Checking.adoc
+Type-Options.adoc
 Values.adoc
 Evaluation.adoc
 Analysis-and-Translation.adoc
diff --git a/version.sh b/version.sh
index 9b37679ce..545147265 100644
--- a/version.sh
+++ b/version.sh
@@ -2,4 +2,4 @@
 # The FPP version
 # ----------------------------------------------------------------------
 
-export VERSION="Unreleased, after v2.1.0"
+export VERSION="v2.2.0"
