$\newcommand{\unicode}[1]{U{+}\code{#1}}$
$\DeclareMathOperator{\lex}{lex}$
$\DeclareMathOperator{\pat}{pat}$
+ $\DeclareMathOperator{\spread}{spread}$
</div>
<h1>Reference Manual</h1>
<p>The reference manual provides a detailed account of the programming language. It supplements and amends the user manual (particularly the sections “Programming Language” and “Listener Buffers”) and the tutorial.</p>
<h2>Syntax</h2>
<h3>Introduction</h3>
<h4>Listener Buffers</h4>
- <p>Let's examine what happens when the form <code>(+ 123 456)</code> is evaluated in a listener buffer:</p>
+ <p>Let us examine what happens when the form <code>(+ 123 456)</code> is evaluated in a listener buffer:</p>
<pre class="repl">> (+ 123 456)<br>579</pre>
<p>The process can be broken down into the following five steps:</p>
<p><b>Step 1</b> The sequence of characters <span class="charseq"><span class="char">(</span><span class="char">+</span><span class="char"> </span><span class="char">1</span><span class="char">2</span><span class="char">3</span><span class="char"> </span><span class="char">4</span><span class="char">5</span><span class="char">6</span><span class="char">)</span></span> is read from the listener buffer.</p>
<td class="rhs"><code>hash-left-parenthesis {$\metavar{xml-markup}$* $\metavar{object}$}* $\metavar{xml-markup}$* right-parenthesis</code></td>
</tr>
</table>
- <p>Let us denote by $\mathcal{M}$ the function assigning a meaning to a derivation tree. The function $\mathcal{M}$ is defined by specifying, for each production rule, how the meaning of the nonterminal symbol on the left-hand side is computed from (1) the meanings of the nonterminal symbols on the right-hand side and (2) the terminal symbols on the right-hand side. Here is the definition of the function $\mathcal{M}$ (pairs of angle brackets denote sequence formation and $\|$ denotes sequence concatenation):</p>
+ <p>Let us denote by $\mathcal{M}$ the function assigning a meaning to a derivation tree. The function $\mathcal{M}$ is defined by specifying, for each production rule, how the meaning of the nonterminal symbol on the left-hand side is computed from (1) the meanings of the nonterminal symbols on the right-hand side and (2) the terminal symbols on the right-hand side. Here is the definition of the function $\mathcal{M}$, where a pair of square brackets denotes sequence formation and $\|$ denotes sequence concatenation):</p>
<dl>
<!-- input -->
<dt>$\metavar{input}\Coloneq$ <code>$\metavar{object}$</code></dt>
- <dd>$\mathcal{M}(\metavar{input})=\langle\mathcal{M}(\metavar{object})\rangle$</dd>
+ <dd>$\mathcal{M}(\metavar{input})=[\mathcal{M}(\metavar{object})]$</dd>
<dt>$\metavar{input}\Coloneq$ <code>$\metavarn{object}{1}\ldots\metavarn{object}{n\geq0}$</code></dt>
- <dd>$\mathcal{M}(\metavar{input})=\langle\mathcal{M}(\metavarn{object}{1}),\ldots,\mathcal{M}(\metavarn{object}{n})\rangle$</dd>
+ <dd>$\mathcal{M}(\metavar{input})=[\mathcal{M}(\metavarn{object}{1}),\ldots,\mathcal{M}(\metavarn{object}{n})]$</dd>
<dt>$\metavar{input}\Coloneq$ <code>$\metavar{xml-comment}$* $\metavar{xml-element}$ $\metavar{xml-comment}$*</code></dt>
<dd>$\mathcal{M}(\metavar{input})=\mathcal{M}(\metavar{xml-element})$</dd>
<!-- xml-markup -->
<dt>$\metavar{xml-element}\Coloneq$ <code>xml-start-tag $\metavarn{xml-element-content}{1}\ldots\metavarn{xml-element-content}{n\geq0}$ xml-end-tag</code></dt>
<dd>$\mathcal{M}(\metavar{xml-element})=\mathcal{M}(\metavarn{xml-element-content}{1})\|\cdots\|\mathcal{M}(\metavarn{xml-element-content}{n})$</dd>
<dt>$\metavar{xml-element}\Coloneq$ <code>xml-empty-element-tag</code></dt>
- <dd>$\mathcal{M}(\metavar{xml-element})=\langle\rangle$</dd>
+ <dd>$\mathcal{M}(\metavar{xml-element})=[]$</dd>
<!-- xml-element-content -->
<dt>$\metavar{xml-element-content}\Coloneq$ <code>$\metavar{xml-markup}$</code></dt>
<dd>$\mathcal{M}(\metavar{xml-element-content})=\mathcal{M}(\metavar{xml-markup})$</dd>
<dt>$\metavar{xml-element-content}\Coloneq$ <code>$\metavar{object}$</code></dt>
- <dd>$\mathcal{M}(\metavar{xml-element-content})=\langle\mathcal{M}(\metavar{object})\rangle$</dd>
+ <dd>$\mathcal{M}(\metavar{xml-element-content})=[\mathcal{M}(\metavar{object})]$</dd>
<!-- xml-comment -->
<dt>$\metavar{xml-comment}\Coloneq$ <code>xml-comment</code></dt>
- <dd>$\mathcal{M}(\metavar{xml-comment})=\langle\rangle$</dd>
+ <dd>$\mathcal{M}(\metavar{xml-comment})=[]$</dd>
<!-- object -->
<dt>$\metavar{object}\Coloneq$ <code>void</code></dt>
<dd>$\mathcal{M}(\metavar{object})=$ the value of the token of category <code>void</code></dd>
<td class="rhs"><code>$\metavar{plain-function-call}$ | $\metavar{apply-form}$ | $\metavar{multiple-value-call-form}$ | $\metavar{multiple-value-apply-form}$</code></td>
</tr>
</table>
+ <p>The parameters of a parameter list fall into two categories: the required parameters, of which there can be any number, and the rest parameters, of which there can be zero or one. Here are the required and rest parameters for the different forms of parameter lists:</p>
+ <table class="plain">
+ <tr><th>Parameter list</th><th>Required parameters</th><th>Rest parameters</th></tr>
+ <tr><td><code>$\var$</code></td><td>none</td><td>$\var$</td></tr>
+ <tr><td><code>($\var_1\ldots\var_{n\ge0}$)</code></td><td>$\var_1,\ldots,\var_n$</td><td>none</td></tr>
+ <tr><td><code>($\var_1\ldots\var_{n\ge1}$ . $\var_{n+1}$)</code></td><td>$\var_1,\ldots,\var_n$</td><td>$\var_{n+1}$</td></tr>
+ </table>
<p>The variables <code>quasiquote</code>, <code>unquote</code>, and <code>unquote-splicing</code> are not special operators. The variable <code>quasiquote</code> is the name of a global macro and the variables <code>unquote</code> and <code>unquote-splicing</code> are variables having special meanings in the context of a call to the global macro <code>quasiquote</code>.</p>
<p>A form consisting of a variable $\var$ is treated as an abbreviation. If it appears in operator position, then it is treated as an abbreviation for the special form <code>(fref $\var$)</code>. Otherwise, it is treated as an abbreviation for the special form <code>(vref $\var$)</code>.</p>
<p>Classifying a form is the first step in evaluating a form. If the classification fails, then the evaluation fails.</p>
<li>Arguments named $\variable$, with or without a subscript, must be of type <code>variable</code>.</li>
<li>Arguments named $\cons$, with or without a subscript, must be of type <code>cons</code>.</li>
</ul>
- <p>If any argument is not of its required type, then the invocation of the primitive function completes abnormally.</p>
+ <p>If any argument is not of its required type, then the invocation of the primitive function completes abruptly with a reason of type <code>error</code>.</p>
<h4>Primitive Data Types</h4>
<p>Here is a tree-view representation of the hierarchy of primitive data types:</p>
<pre>object<br> |-void<br> |-boolean<br> |-number<br> |-character<br> |-string<br> |-symbol<br> | |-keyword<br> | |-variable<br> |-list<br> | |-empty-list<br> | |-cons<br> |-vector<br> |-function<br> | |-primitive-function<br> | |-closure</pre>
<dd>The primitive function returns <code>#t</code> if $\object$ is of type <code>boolean</code> and <code>#f</code> otherwise.</dd>
</dl>
<h4>Primitive Data Type <code>number</code> and Related Primitive Functions</h4>
- <p>Objects of type <code>number</code> represent mathematical numbers using the floating-point format <a href="https://en.wikipedia.org/wiki/Double-precision_floating-point_format" target="_blank">IEEE 754 binary 64</a>.
+ <p>Objects of type <code>number</code> represent mathematical numbers using the floating-point format <a href="https://en.wikipedia.org/wiki/Double-precision_floating-point_format" target="_blank">IEEE 754 binary 64</a>. Some (but not all) of the integers that can be represented exactly by an object of type <code>number</code> are the integers between $-2^{53}=−9,007,199,254,740,992$ and $2^{53}=9,007,199,254,740,992$ (bounds included).</p>
<dl>
<dt><code>(number? $\object$)</code></dt>
<dd>The primitive function returns <code>#t</code> if $\object$ is of type <code>number</code> and <code>#f</code> otherwise.</dd>
<dt><code>(>= $\number_1$ $\number_2$)</code></dt>
<dd>The primitive function returns <code>#t</code> if $\number_1$ is numerically greater than or equal to $\number_2$ and <code>#f</code> otherwise.</dd>
</dl>
+ <p>The primitive functions <code>_+</code>, <code>_-</code>, <code>_*</code>, and <code>_/</code> have an underscore at the beginning of their names to distinguish them from the similarly named nonprimitive functions <code>+</code>, <code>-</code>, <code>*</code>, and <code>/</code>, which all accept a variable number of arguments.</p>
<h4>Primitive Data Type <code>character</code> and Related Primitive Functions</h4>
<p>Contrary to what was said in the user manual, an object of type <code>character</code> represents a UTF-$16$ code unit (instead of a Unicode character).</p>
<dl>
<dt><code>(values $\object_1\ldots\object_n$)</code></dt>
<dd>The primitive function converts its arguments into values: when invoked on the arguments $\object_1,\ldots,\object_n$, the primitive function returns the values $\object_1,\ldots,\object_n$.</dd>
<dt><code>(error $\string$)</code></dt>
- <dd>The invocation of the primitive function always completes abnormally.</dd>
+ <dd>The invocation of the primitive function completes abruptly with a reason of type <code>error</code> whose payload is $\string$.</dd>
<dt><code>(now)</code></dt>
<dd>The primitive function returns the number of milliseconds elapsed since 1970-01-01 00:00:00.000 UTC.</dd>
</dl>
+ <h3>Forms</h3>
+ <p>This section supplements and amends the evaluation rules stated in the user manual.</p>
+ <h4>Special Form <code>_for-each</code></h4>
+ <p>The special form <code>_for-each</code> is evaluated as follows:</p>
+ <dl>
+ <dt><code>(_for-each $\metavar{function-form}$ $\metavar{list-form}$)</code></dt>
+ <dd>The function-form and the list-form are evaluated, in that order. Let $\primval_1$ be the primary value of the function-form and $\primval_2$ be the primary value of the list-form. If $\primval_1$ is not a function or $\primval_2$ is not a proper list, then the evaluation of the _for-each-form completes abruptly with a reason of type <code>error</code>. Otherwise, the function $\primval_1$ is invoked on each element of the proper list $\primval_2$, from the first element to the last element. If any invocation completes abruptly for any reason, then the evaluation of the _for-each-form completes abruptly for the same reason. Otherwise, if any invocation does not complete, then the evaluation of the _for-each-form does not complete either. Otherwise, the _for-each-form evaluates to <code>#v</code>.</dd>
+ </dl>
+ <h4>Special Form <code>_catch-errors</code></h4>
+ <p>The special form <code>_catch-errors</code> is evaluated as follows:</p>
+ <dl>
+ <dt><code>(_catch-errors $\metavar{try-form}$)</code></dt>
+ <dd>The try-form is evaluated. If the evaluation of the try-form completes abruptly for a reason of type <code>error</code>, then the evaluation of the _catch-errors-form completes normally and the _catch-errors-form evaluates to <code>#v</code>. Otherwise, if the evaluation of the try-form completes abruptly for a reason of type <code>exit</code>, then the evaluation of the _catch-errors-form completes abruptly for the same reason. Otherwise, if the evaluation of the try-form does not complete, then the evaluation of the _catch-errors-form does not complete either. Otherwise, the _catch-errors-form evaluates to the values of the try-form.</dd>
+ </dl>
+ <h4>Function Calls</h4>
+ <p>A spreadable sequence of objects is a nonempty sequence of objects such that the last element of the sequence is a proper list of objects. Let $\mlvar{seq}=[\obj_1,\ldots,\obj_n,\code{(}\obj'_1\ldots\obj'_m\code{)}]$, where $n$ and $m$ are nonnegative integers, be a spreadable sequence of objects. We will denote by $\spread(\mlvar{seq})$ the sequence of objects $[\obj_1,\ldots,\obj_n,\obj'_1,\ldots,\obj'_m]$.</p>
+ <p>The function calls are evaluated as follows (the differences in behavior between the different types of function calls are highlighted with a gray background):</p>
+ <dl>
+ <dt><code>($\metavar{operator-form}$ $\metavar{operand-forms}$)</code></dt>
+ <dd>The operator-form and the operand-forms are evaluated in sequence from left to right. If the primary value of the operator-form is not a function, then the evaluation of the plain function call completes abruptly with a reason of type <code>error</code>. <span class="bg">Otherwise, the primary values of the operand-forms are collected into a sequence $\mlvar{seq}$ and the primary value of the operator-form is invoked on $\mlvar{seq}$.</span> If the invocation completes abruptly for any reason, then the evaluation of the plain function call also completes abruptly for the same reason. Otherwise, if the invocation does not complete, then the evaluation of the plain function call does not complete either. Otherwise, the plain function call evaluates to the values of the invocation. (The behavior described here is identical to the behavior described in the user manual.)</dd>
+ <dt><code>(apply $\metavar{operator-form}$ $\metavar{operand-forms}$)</code></dt>
+ <dd>The operator-form and the operand-forms are evaluated in sequence from left to right. If the primary value of the operator-form is not a function, then the evaluation of the apply-form completes abruptly with a reason of type <code>error</code>. <span class="bg">Otherwise, the primary values of the operand-forms are collected into a sequence $\mlvar{seq}$ and the primary value of the operator-form is invoked on $\spread(\mlvar{seq})$. (The evaluation of the apply-form completes abruptly with a reason of type <code>error</code> if $\mlvar{seq}$ is not a spreadable sequence of objects.)</span> If the invocation completes abruptly for any reason, then the evaluation of the apply-form also completes abruptly for the same reason. Otherwise, if the invocation does not complete, then the evaluation of the apply-form does not complete either. Otherwise, the apply-form evaluates to the values of the invocation.</dd>
+ <dt><code>(multiple-value-call $\metavar{operator-form}$ $\metavar{operand-forms}$)</code></dt>
+ <dd>The operator-form and the operand-forms are evaluated in sequence from left to right. If the primary value of the operator-form is not a function, then the evaluation of the multiple-value-call-form completes abruptly with a reason of type <code>error</code>. <span class="bg">Otherwise, all the values of the operand-forms are collected into a sequence $\mlvar{seq}$ and the primary value of the operator-form is invoked on the sequence $\mlvar{seq}$.</span> If the invocation completes abruptly for any reason, then the evaluation of the multiple-value-call-form also completes abruptly for the same reason. Otherwise, if the invocation does not complete, then the evaluation of the multiple-value-call-form does not complete either. Otherwise, the multiple-value-call-form evaluates to the values of the invocation.</dd>
+ <dt><code>(multiple-value-apply $\metavar{operator-form}$ $\metavar{operand-forms}$)</code></dt>
+ <dd>The operator-form and the operand-forms are evaluated in sequence from left to right. If the primary value of the operator-form is not a function, then the evaluation of the multiple-value-apply-form completes abruptly with a reason of type <code>error</code>. <span class="bg">Otherwise, all the values of the operand-forms are collected into a sequence $\mlvar{seq}$ and the primary value of the operator-form is invoked on $\spread(\mlvar{seq})$. (The evaluation of the multiple-value-apply-form completes abruptly with a reason of type <code>error</code> if $\mlvar{seq}$ is not a spreadable sequence of objects.)</span> If the invocation completes abruptly for any reason, then the evaluation of the multiple-value-apply-form also completes abruptly for the same reason. Otherwise, if the invocation does not complete, then the evaluation of the multiple-value-apply-form does not complete either. Otherwise, the multiple-value-apply-form evaluates to the values of the invocation.</dd>
+ </dl>
+ <p>A primitive function is invoked as described in the user manual. A closure is invoked as described in the user manual except for the way the parameters and the arguments are paired in order to extend the value namespace of the lexical environment captured by the closure (when the corresponding lambda abstraction is a _vlambda-form or an _mlambda-form), the function namespace of the lexical environment captured by the closure (when the corresponding lambda abstraction is an _flambda-form), or the value namespace of the current dynamic environment (when the corresponding lambda abstraction is a _dlambda-form). Let $\arg_1,\ldots,\arg_n$ be the arguments and $var_1,\ldots,\var_m$ be the required parameters. The way the parameters and the arguments are paired depends on the absence or presence of a rest parameter:</p>
+ <dl>
+ <dt>Case 1, there is no rest parameter:</dt>
+ <dd>If $n\neq m$, then the invocation completes abruptly with a reason of type <code>error</code>. Otherwise, the appropriate namespace of the appropriate environment is extended to bind $\var_i$ to $\arg_i$ for all $i$ from $1$ to $m$. (This is the behavior described in the user manual.)</dd>
+ <dt>Case 2, there is a rest parameter $\var_{m+1}$:</dt>
+ <dd>If $n\lt m$, then the invocation completes abruptly with a reason of type <code>error</code>. Otherwise, the appropriate namespace of the appropriate environment is extended to bind $\var_i$ to $\arg_i$ for all $i$ from $1$ to $m$ and $\var_{m+1}$ to a proper list whose elements are $\arg_{m+1},\ldots,arg_{n}$. The conses used to build the proper list are not necessarily new conses. When the function call is an apply-form or a multiple-value-apply-form, the proper list actually reuses some or all of the conses constituting the last element of the spreadable sequence of objects.</dd>
+ </dl>
+ <p>Here are some examples, where the bindings are assumed to belong to the value namespace:</p>
+ <table class="plain">
+ <tr><th>Parameter list</th><th>Arguments</th><th>Bindings</th></tr>
+ <tr><td><code>(a b)</code></td><td>$[\code{1},\code{2},\code{3}]$</td><td>N/A (error: too many arguments)</td></tr>
+ <tr><td><code>(a b c)</code></td><td>$[\code{1},\code{2},\code{3}]$</td><td>$[\vbinding{a}{1},\vbinding{b}{2},\vbinding{c}{3}]$</td></tr>
+ <tr><td><code>(a b c d)</code></td><td>$[\code{1},\code{2},\code{3}]$</td><td>N/A (error: too few arguments)</td></tr>
+ <tr><td><code>a</code></td><td>$[\code{1},\code{2},\code{3}]$</td><td>$[\vbinding{a}{(1 2 3)}]$</td></tr>
+ <tr><td><code>(a . b)</code></td><td>$[\code{1},\code{2},\code{3}]$</td><td>$[\vbinding{a}{1},\vbinding{b}{(2 3)}]$</td></tr>
+ <tr><td><code>(a b . c)</code></td><td>$[\code{1},\code{2},\code{3}]$</td><td>$[\vbinding{a}{1},\vbinding{b}{2},\vbinding{c}{(3)}]$</td></tr>
+ <tr><td><code>(a b c . d)</code></td><td>$[\code{1},\code{2},\code{3}]$</td><td>$[\vbinding{a}{1},\vbinding{b}{2},\vbinding{c}{3},\vbinding{d}{()}]$</td></tr>
+ <tr><td><code>(a b c d . e)</code></td><td>$[\code{1},\code{2},\code{3}]$</td><td>N/A (error: too few arguments)</td></tr>
+ </table>
+ <p>Here is one way to reproduce the preceding examples using plain function calls and _vlambda-forms:</p>
+ <pre class="repl">> ((_vlambda (a b) (list a b)) 1 2 3)<br>ERROR: Too many arguments.<br><br>> ((_vlambda (a b c) (list a b c)) 1 2 3)<br>(1 2 3)<br><br>> ((_vlambda (a b c d) (list a b c d)) 1 2 3)<br>ERROR: Too few arguments.<br><br>> ((_vlambda a (list a)) 1 2 3)<br>((1 2 3))<br><br>> ((_vlambda (a . b) (list a b)) 1 2 3)<br>(1 (2 3))<br><br>> ((_vlambda (a b . c) (list a b c)) 1 2 3)<br>(1 2 (3))<br><br>> ((_vlambda (a b c . d) (list a b c d)) 1 2 3)<br>(1 2 3 ())<br><br>> ((_vlambda (a b c d . e) (list a b c d e)) 1 2 3)<br>ERROR: Too few arguments.</pre>
</body>
</html>
<p>Objects treated as code are called forms. A form is executed by being submitted to a component of the programming language called the evaluator. (The form is said to be evaluated.) The evaluation of a form has three possible outcomes:</p>
<ul>
<li>The evaluation can complete normally and produce a result consisting of zero or more objects—object references actually—called the values of the form. (The form is said to evaluate to the values.)</li>
- <li>The evaluation can complete abnormally because of an error. An evaluation that completes abnormally does not produce any result.</li>
+ <li>The evaluation can complete abruptly because of an error or because of a nonlocal exit. An evaluation that completes abruptly does not produce any result.</li>
<li>The evaluation can get caught in an infinite loop and never complete.</li>
</ul>
<p>The primary value of a form whose evaluation completed normally is defined as follows: If the result consists of one or more objects, then the primary value of the form is the first object. Otherwise, the primary value of the form is <code>#v</code>.</p>
+ <p>The abrupt completion of an evaluation has an associated reason, which has a type and carries a payload. An abrupt completion caused by an error has an associated reason of type <code>error</code>, which carries a payload consisting of an object of type <code>string</code> describing the error. An abrupt completion caused by a nonlocal exit has an associated reason of type <code>exit</code>, which carries a payload described in the reference manual.</p>
<p>Forms submitted to the evaluator through a <a href="#listener-buffers">listener buffer</a>, through the <a href="#evaluate-form">Evaluate Form</a> command, or through the <a href="#load-buffer">Load Buffer</a> command are called top-level forms. A consequence of the evaluation rules stated later in this section is that the evaluation of a top-level form usually entails the evaluation of other non-top-level forms.</p>
<p>Execution of EVLambda code is achieved through interpretation or compilation.</p>
<p>An interpreter for a language $X$ is a program capable of directly executing code written in language $X$. Language $X$ is called the source language of the interpreter. A compiler for a language $X$ is a program capable of translating code written in language $X$ into code written in a language $Y$. Language $X$ is called the source language of the compiler and language $Y$ is called the target language of the compiler. Code handed to an interpreter or compiler is called source code. A file containing source code is called a source file. Code produced by a compiler is called compiled code. A file containing compiled code is called a compiled file.</p>
<p>A consequence of the lookup rules is that a binding in the value/function namespace of the current lexical/dynamic environment will effectively shadow a binding for the same variable in the value/function namespace of the global environment.</p>
<p>A global variable is a binding between a variable and an object (of any type) in the value namespace of the global environment, or the name or value of such binding. A global function is a binding between a variable and a function other than a macro in the function namespace of the global environment, or the name or value of such binding. A global macro is a binding between a variable and a macro in the function namespace of the global environment, or the name or value of such binding. Global variables, global functions, and global macros are created and altered using language constructs called global definitions.</p>
<p>A local variable is a binding between a variable and an object (of any type) in the value namespace of a lexical environment, or the name or value of such binding. A local function is a binding between a variable and a function other than a macro in the function namespace of a lexical environment, or the name or value of such binding. A local macro is a binding between a variable and a macro in the function namespace of a lexical environment, or the name or value of such binding. A dynamic variable is a binding between a variable and an object (of any type) in the value namespace of a dynamic environment, or the name or value of such binding. Local variables, local functions, local macros, and dynamic variables are created (but not altered) using language constructs called binding constructs.</p>
- <p>When a form is submitted to the evaluator, the evaluator analyzes the form to determine how to evaluate it. If the form is the empty list, then the evaluation completes abnormally. Otherwise, if the form is neither a variable nor a cons, then the result of the evaluation is the form itself. (Objects that are neither the empty list, nor a variable, nor a cons are said to be self-evaluating.) Otherwise, if the form is a variable $\var$, then the variable is treated as an abbreviation for either <code>(vref $\var$)</code> or <code>(fref $\var$)</code>, depending on the context of its occurrence. Otherwise, the form is necessarily a cons and the evaluation completes abnormally unless the form matches one of the following patterns:</p>
+ <p>When a form is submitted to the evaluator, the evaluator analyzes the form to determine how to evaluate it. If the form is the empty list, then the evaluation completes abruptly with a reason of type <code>error</code>. Otherwise, if the form is neither a variable nor a cons, then the result of the evaluation is the form itself. (Objects that are neither the empty list, nor a variable, nor a cons are said to be self-evaluating.) Otherwise, if the form is a variable $\var$, then the variable is treated as an abbreviation for either <code>(vref $\var$)</code> or <code>(fref $\var$)</code>, depending on the context of its occurrence. Otherwise, the form is necessarily a cons and the evaluation completes abruptly with a reason of type <code>error</code> unless the form matches one of the following patterns:</p>
<ol>
<li><code>(quote $\metavar{literal}$)</code></li>
<li><code>(progn $\metavar{serial-forms}$)</code></li>
<p>As we will see below, the evaluation of a form containing subforms entails the evaluation of some or all of the subforms. When a subform is evaluated, the following rules apply:</p>
<ul>
<li>The subform is evaluated with respect to the same lexical and dynamic environments as the containing form. (But see below how closures are invoked.)</li>
- <li>If the evaluation of the subform completes abnormally, then the evaluation of the containing form also completes abnormally.</li>
+ <li>Generally, if the evaluation of the subform completes abruptly for any reason, then the evaluation of the containing form also completes abruptly for the same reason. The only form that can behave differently is the special form <code>_catch-errors</code>.</li>
<li>If the evaluation of the subform does not complete, then the evaluation of the containing form does not complete either.</li>
</ul>
<p>Special forms, macro calls, and plain function calls are evaluated as follows:</p>
<dt><code>(progn $\metavar{serial-forms}$)</code></dt>
<dd>The serial-forms are evaluated in sequence from left to right. If there is at least one serial-form, then the progn-form evaluates to the values of the last serial-form. Otherwise, the progn-form evaluates to <code>#v</code>.</dd>
<dt><code>(if $\metavar{test-form}$ $\metavar{then-form}$ $\metavar{else-form}$)</code></dt>
- <dd>The test-form is evaluated. Let $\primval$ be the primary value of the test-form. If $\primval$ is not a boolean, then the evaluation of the if-form completes abnormally. If $\primval$ is the boolean <code>#t</code>, then the then-form is evaluated and the if-form evaluates to the values of the then-form. If $\primval$ is the boolean <code>#f</code>, then the else-form is evaluated and the if-form evaluates to the values of the else-form.</dd>
+ <dd>The test-form is evaluated. Let $\primval$ be the primary value of the test-form. If $\primval$ is not a boolean, then the evaluation of the if-form completes abruptly with a reason of type <code>error</code>. If $\primval$ is the boolean <code>#t</code>, then the then-form is evaluated and the if-form evaluates to the values of the then-form. If $\primval$ is the boolean <code>#f</code>, then the else-form is evaluated and the if-form evaluates to the values of the else-form.</dd>
<dt><code>(_vlambda $\metavar{parameter-list}$ $\metavar{body}$)</code></dt>
<dt><code>(_mlambda $\metavar{parameter-list}$ $\metavar{body}$)</code></dt>
<dt><code>(_flambda $\metavar{parameter-list}$ $\metavar{body}$)</code></dt>
<dt><code>(_dlambda $\metavar{parameter-list}$ $\metavar{body}$)</code></dt>
<dd>A lambda abstraction evaluates to a closure recording the following two pieces of information: the lambda abstraction and the current lexical environment (which is said to be captured by the closure). A closure resulting from the evaluation of an _mlambda-form is tagged as being a macro.</dd>
<dt><code>(vref $\metavar{variable}$)</code></dt>
- <dd>If there exists a binding for the variable in the value namespace of the current lexical environment, then the vref-form evaluates to the value of that binding. Otherwise, if there exists a binding for the variable in the value namespace of the global environment, then the vref-form evaluates to the value of that binding. Otherwise, the evaluation of the vref-form completes abnormally.</dd>
+ <dd>If there exists a binding for the variable in the value namespace of the current lexical environment, then the vref-form evaluates to the value of that binding. Otherwise, if there exists a binding for the variable in the value namespace of the global environment, then the vref-form evaluates to the value of that binding. Otherwise, the evaluation of the vref-form completes abruptly with a reason of type <code>error</code>.</dd>
<dt><code>(vset! $\metavar{variable}$ $\metavar{value-form}$)</code></dt>
<dd>The value-form is evaluated. Let $\primval$ be the primary value of the value-form. If there exists a binding for the variable in the value namespace of the current lexical environment, then the value of that binding is replaced by $\primval$. Otherwise, if there exists a binding for the variable in the value namespace of the global environment, then the value of that binding is replaced by $\primval$. Otherwise, a new binding between the variable and $\primval$ is added to the value namespace of the global environment. In all three cases, the vset-form evaluates to $\primval$.</dd>
<dt><code>(fref $\metavar{variable}$)</code></dt>
- <dd>If there exists a binding for the variable in the function namespace of the current lexical environment, then the fref-form evaluates to the value of that binding. Otherwise, if there exists a binding for the variable in the function namespace of the global environment, then the fref-form evaluates to the value of that binding. Otherwise, the evaluation of the fref-form completes abnormally.</dd>
+ <dd>If there exists a binding for the variable in the function namespace of the current lexical environment, then the fref-form evaluates to the value of that binding. Otherwise, if there exists a binding for the variable in the function namespace of the global environment, then the fref-form evaluates to the value of that binding. Otherwise, the evaluation of the fref-form completes abruptly with a reason of type <code>error</code>.</dd>
<dt><code>(fset! $\metavar{variable}$ $\metavar{value-form}$)</code></dt>
<dd>The value-form is evaluated. Let $\primval$ be the primary value of the value-form. If there exists a binding for the variable in the function namespace of the current lexical environment, then the value of that binding is replaced by $\primval$. Otherwise, if there exists a binding for the variable in the function namespace of the global environment, then the value of that binding is replaced by $\primval$. Otherwise, a new binding between the variable and $\primval$ is added to the function namespace of the global environment. In all three cases, the fset-form evaluates to $\primval$.</dd>
<dt><code>(dref $\metavar{variable}$)</code></dt>
- <dd>If there exists a binding for the variable in the value namespace of the current dynamic environment, then the dref-form evaluates to the value of that binding. Otherwise, if there exists a binding for the variable in the value namespace of the global environment, then the dref-form evaluates to the value of that binding. Otherwise, the evaluation of the dref-form completes abnormally.</dd>
+ <dd>If there exists a binding for the variable in the value namespace of the current dynamic environment, then the dref-form evaluates to the value of that binding. Otherwise, if there exists a binding for the variable in the value namespace of the global environment, then the dref-form evaluates to the value of that binding. Otherwise, the evaluation of the dref-form completes abruptly with a reason of type <code>error</code>.</dd>
<dt><code>(dset! $\metavar{variable}$ $\metavar{value-form}$)</code></dt>
<dd>The value-form is evaluated. Let $\primval$ be the primary value of the value-form. If there exists a binding for the variable in the value namespace of the current dynamic environment, then the value of that binding is replaced by $\primval$. Otherwise, if there exists a binding for the variable in the value namespace of the global environment, then the value of that binding is replaced by $\primval$. Otherwise, a new binding between the variable and $\primval$ is added to the value namespace of the global environment. In all three cases, the dset-form evaluates to $\primval$.</dd>
<dt><code>(_for-each $\metavar{function-form}$ $\metavar{list-form}$)</code></dt>
<dt><code>(multiple-value-apply $\metavar{operator-form}$ $\metavar{operand-forms}$)</code></dt>
<dd>These special forms are variants of the plain function call described below. They are described in the reference manual.</dd>
<dt><code>($\metavar{macro-operator}$ $\metavar{macro-operands}$)</code></dt>
- <dd>Following the definition of a macro call, the macro-operator matches a variable naming a macro according to the lookup rule used by <code>fref</code>. That macro is invoked on the unevaluated macro-operands. If the invocation completes abnormally, then the evaluation of the macro call also completes abnormally. Otherwise, if the invocation does not complete, then the evaluation of the macro call does not complete either. Otherwise, the primary value of the invocation, which is called the expansion of the macro call, is evaluated with respect to the current lexical and dynamic environments. If the evaluation of the expansion completes abnormally, then the evaluation of the macro call also completes abnormally. Otherwise, if the evaluation of the expansion does not complete, then the evaluation of the macro call does not complete either. Otherwise, the macro call evaluates to the values of the expansion.</dd>
+ <dd>Following the definition of a macro call, the macro-operator matches a variable naming a macro according to the lookup rule used by <code>fref</code>. That macro is invoked on the unevaluated macro-operands. If the invocation completes abruptly for any reason, then the evaluation of the macro call also completes abruptly for the same reason. Otherwise, if the invocation does not complete, then the evaluation of the macro call does not complete either. Otherwise, the primary value of the invocation, which is called the expansion of the macro call, is evaluated with respect to the current lexical and dynamic environments. If the evaluation of the expansion completes abruptly for any reason, then the evaluation of the macro call also completes abruptly for the same reason. Otherwise, if the evaluation of the expansion does not complete, then the evaluation of the macro call does not complete either. Otherwise, the macro call evaluates to the values of the expansion.</dd>
<dt><code>($\metavar{operator-form}$ $\metavar{operand-forms}$)</code></dt>
- <dd>The operator-form and the operand-forms are evaluated in sequence from left to right. If the primary value of the operator-form is not a function, then the evaluation of the plain function call completes abnormally. Otherwise, the primary value of the operator-form is invoked on the primary values of the operand-forms. If the invocation completes abnormally, then the evaluation of the plain function call also completes abnormally. Otherwise, if the invocation does not complete, then the evaluation of the plain function call does not complete either. Otherwise, the plain function call evaluates to the values of the invocation.</dd>
+ <dd>The operator-form and the operand-forms are evaluated in sequence from left to right. If the primary value of the operator-form is not a function, then the evaluation of the plain function call completes abruptly with a reason of type <code>error</code>. Otherwise, the primary value of the operator-form is invoked on the primary values of the operand-forms. If the invocation completes abruptly for any reason, then the evaluation of the plain function call also completes abruptly for the same reason. Otherwise, if the invocation does not complete, then the evaluation of the plain function call does not complete either. Otherwise, the plain function call evaluates to the values of the invocation.</dd>
</dl>
<p>Invoking a function is what causes the function to compute the output corresponding to an input. The input of an invocation consists of zero or more objects—object references actually—called the arguments of the invocation. (The function is said to be invoked on the arguments and the arguments are said to be passed to the function.) The invocation of a function has three possible outcomes:</p>
<ul>
<li>The invocation can complete normally and produce an output consisting of zero or more objects—object references actually—called the values of the invocation. (The function is said to return the values.)</li>
- <li>The invocation can complete abnormally because of an error. An invocation that completes abnormally does not produce any output.</li>
+ <li>The invocation can complete abruptly because of an error or because of a nonlocal exit. An invocation that completes abruptly does not produce any output.</li>
<li>The invocation can get caught in an infinite loop and never complete.</li>
</ul>
<p>The primary value of an invocation that completed normally is defined as follows: If the output consists of one or more objects, then the primary value of the invocation is the first object. Otherwise, the primary value of the invocation is <code>#v</code>.</p>
+ <p>The abrupt completion of an invocation has an associated reason, which has a type and carries a payload. The types and payloads for invocations are the same as for evaluations.</p>
<p>The verbs “accept” and “return” are often used to describe the input/output mapping implemented by a function. For example, we could describe a function by saying that the function accepts two numbers and returns the sum of their squares.</p>
<p>A primitive function is invoked as follows:</p>
- <blockquote>Let's assume that, as is the case with all the evaluators currently available, the primitive function is implemented by a JavaScript function accepting (an encoding of) the arguments of the invocation of the primitive function and returning (an encoding of) the values of the invocation of the primitive function. The JavaScript function is invoked on the arguments. If the invocation of the JavaScript function completes abnormally, then the invocation of the primitive function also completes abnormally. Otherwise, if the invocation of the JavaScript function does not complete, then the invocation of the primitive function does not complete either. Otherwise, the primitive function returns the values returned by the JavaScript function.</blockquote>
+ <blockquote>Let us assume that, as is the case with all the evaluators currently available, the primitive function is implemented by a JavaScript function accepting (an encoding of) the arguments of the invocation of the primitive function and returning (an encoding of) the values of the invocation of the primitive function. The JavaScript function is invoked on the arguments. If the invocation of the JavaScript function completes abruptly for any reason, then the invocation of the primitive function also completes abruptly for the same reason. Otherwise, if the invocation of the JavaScript function does not complete, then the invocation of the primitive function does not complete either. Otherwise, the primitive function returns the values returned by the JavaScript function.</blockquote>
<p>A closure is invoked as follows:</p>
<blockquote>
- <p>If the number of variables in the parameter list of the lambda abstraction recorded by the closure and the number of arguments are different, then the invocation completes abnormally. (As we will see in the reference manual, it is actually possible to create closures accepting a variable number of arguments.) Otherwise, let $\var_1,\ldots,\var_n$ be the variables composing the parameter list of the lambda abstraction recorded by the closure, $\arg_1,\ldots,\arg_n$ be the arguments, and $\lexenv$ and $\dynenv$ be the following environments:</p>
+ <p>If the number of variables in the parameter list of the lambda abstraction recorded by the closure and the number of arguments are different, then the invocation completes abruptly with a reason of type <code>error</code>. (As we will see in the reference manual, it is actually possible to create closures accepting a variable number of arguments.) Otherwise, let $\var_1,\ldots,\var_n$ be the variables composing the parameter list of the lambda abstraction recorded by the closure, $\arg_1,\ldots,\arg_n$ be the arguments, and $\lexenv$ and $\dynenv$ be the following environments:</p>
<ul>
<li>If the closure results from the evaluation of a _vlambda-form or an _mlambda-form, then $\lexenv$ is the environment extending the lexical environment recorded by the closure to bind, in the value namespace, the variable $\var_i$ to the argument $\arg_i$ (for all $i$ from $1$ to $n$) and $\dynenv$ is the current dynamic environment.</li>
<li>If the closure results from the evaluation of an _flambda-form, then $\lexenv$ is the environment extending the lexical environment recorded by the closure to bind, in the function namespace, the variable $\var_i$ to the argument $\arg_i$ (for all $i$ from $1$ to $n$) and $\dynenv$ is the current dynamic environment.</li>
<li>If the closure results from the evaluation of a _dlambda-form, then $\lexenv$ is the lexical environment recorded by the closure and $\dynenv$ is the environment extending the current dynamic environment to bind, in the value namespace, the variable $\var_i$ to the argument $\arg_i$ (for all $i$ from $1$ to $n$).</li>
</ul>
- <p>The objects composing the body of the lambda abstraction recorded by the closure are evaluated with respect to $\lexenv$ and $\dynenv$ as if they were the serial-forms of a progn-form. If the evaluation of the progn-form completes abnormally, then the invocation also completes abnormally. Otherwise, if the evaluation of the progn-form does not complete, then the invocation does not complete either. Otherwise, the closure returns the values of the progn-form.</p>
+ <p>The objects composing the body of the lambda abstraction recorded by the closure are evaluated with respect to $\lexenv$ and $\dynenv$ as if they were the serial-forms of a progn-form. If the evaluation of the progn-form completes abruptly for any reason, then the invocation also completes abruptly for the same reason. Otherwise, if the evaluation of the progn-form does not complete, then the invocation does not complete either. Otherwise, the closure returns the values of the progn-form.</p>
</blockquote>
- <p>The special operators <code>_vlambda</code>, <code>_mlambda</code>, <code>_flambda</code>, and <code>_dlambda</code> have an underscore at the beginning of their names to distinguish them from the similarly named macros <code>vlambda</code>, <code>mlambda</code>, <code>flambda</code>, and <code>dlambda</code>. The purpose of those macros is to facilitate the creation of closures accepting a variable number of arguments.</p>
+ <p>When the evaluation of a top-level form completes abruptly for a reason of type <code>exit</code>, that reason is immediately converted into a reason of type <code>error</code>. The three possible outcomes of the evaluation of a top-level form are thus the following:</p>
+ <ul>
+ <li>The evaluation of the top-level form completes normally.</li>
+ <li>The evaluation of the top-level form completes abruptly for a reason of type <code>error</code>.</li>
+ <li>The evaluation of the top-level form does not complete.</li>
+ </ul>
+ <p>The special operators <code>_vlambda</code>, <code>_mlambda</code>, <code>_flambda</code>, and <code>_dlambda</code> have an underscore at the beginning of their names to distinguish them from the similarly named macros <code>vlambda</code>, <code>mlambda</code>, <code>flambda</code>, and <code>dlambda</code>. The purpose of those macros is to facilitate the creation of closures accepting a variable number of arguments. The special operator <code>_for-each</code> has an underscore at the beginning of its name because it is a hack only needed and implemented by some of the interpreters. The special operator <code>_catch-errors</code> has an underscore at the beginning of its name because it will eventually be replaced by another special operator.</p>
<p>The evaluator uses a data structure called the control stack to coordinate its activities. Each time a top-level form is submitted to the evaluator, a new control stack is created that will be used throughout the evaluation of the form. The same control stack is used to evaluate the top-level form and all non-top-level forms whose evaluations are entailed by the evaluation of the top-level form.</p>
<p>An evaluation/invocation that completes normally produces a result/output consisting of zero or more objects. The production of that result/output, which only occurs if the evaluation/invocation completes normally, is the primary effect of the evaluation/invocation. In addition to or in place of its primary effect, an evaluation/invocation can also have secondary effects called side effects. Examples of side effects are:</p>
<ul>
- <li>The abnormal completion of the evaluation/invocation.</li>
+ <li>The abrupt completion of the evaluation/invocation.</li>
<li>The noncompletion of the evaluation/invocation.</li>
<li>The consumption of time.</li>
<li>The consumption of memory.</li>
<ul>
<li>The prompt is the greater-than sign printed at the beginning of a line to inform you that the listener buffer is waiting for a form to be typed in.</li>
<li>If you press the Return or Enter key when (1) the cursor is not at the very end of the buffer or (2) the form is missing or incomplete, then a newline is simply inserted into the buffer and no evaluation takes place.</li>
- <li>If the evaluation completes abnormally, then a message describing the error is printed in place of the printable representations of the (nonexisting) resulting values.</li>
+ <li>If the evaluation completes abruptly, then the reason is necessarily of type <code>error</code> and its payload (a message describing the error) is printed in place of the printable representations of the (nonexisting) resulting values.</li>
<li>If the evaluation does not complete, then you must abort the evaluation or restart the evaluator in order to get a new prompt.</li>
</ul>
<p>We will now illustrate some of the concepts introduced in the section <a href="#programming-language">Programming Language</a> by providing a commented transcript of a sequence of evaluations conducted in a listener buffer. If you want to reproduce the evaluations, be sure to start with a fresh Trampoline++ evaluator. To get a fresh Trampoline++ evaluator, restart the evaluator (using the Restart Evaluator… command from the Eval menu) with Trampoline++ selected as the evaluator type.</p>
<pre class="repl">> (car '(1 2 3))⏎<br>1</pre>
<p>The evaluation produces a result consisting of the first element of the list <code>(1 2 3)</code>. Because lists are not self-evaluating, quoting the list is necessary.</p>
<pre class="repl">> (car (1 2 3))⏎<br>ERROR: The operator-form does not evaluate to a function.</pre>
- <p>The evaluation completes abnormally if the list is not quoted. The reason is as follows: The evaluator treats the list <code>(1 2 3)</code> as a plain function call and the operator-form, the number <code>1</code>, does not evaluate to a function.</p>
+ <p>The evaluation completes abruptly with a reason of type <code>error</code> if the list is not quoted. The explanation for this behavior is as follows: The evaluator treats the list <code>(1 2 3)</code> as a plain function call and the operator-form, the number <code>1</code>, does not evaluate to a function.</p>
<pre class="repl">> (cdr '(1 2 3))⏎<br>(2 3)</pre>
<p>The evaluation produces a result consisting of the sublist of the list <code>(1 2 3)</code> obtained by omitting its first element.</p>
<pre class="repl">> (car (cdr '(1 2 3)))⏎<br>2</pre>
<pre class="repl">> (cdr (cdr (cdr '(1 2 3))))⏎<br>()</pre>
<p>The evaluation produces a result consisting of the sublist of the list <code>(1 2 3)</code> obtained by omitting its first three elements.</p>
<pre class="repl">> (car (cdr (cdr (cdr '(1 2 3)))))⏎<br>ERROR: The 1st argument is not of type EVLCons.</pre>
- <p>The evaluation completes abnormally because the empty list is not a cons.</p>
+ <p>The evaluation completes abruptly with a reason of type <code>error</code> because the empty list is not a cons.</p>
<pre class="repl">> (disk-area 2)⏎<br>ERROR: The variable 'disk-area' is unbound in the FUNCTION namespace.</pre>
- <p>The evaluation completes abnormally because the global function <code>disk-area</code> is undefined.</p>
+ <p>The evaluation completes abruptly with a reason of type <code>error</code> because the global function <code>disk-area</code> is undefined.</p>
<pre class="repl">> (fdef disk-area (r) (* 3.14 r r))⏎<br>disk-area</pre>
<p>The evaluation produces a result consisting of the variable <code>disk-area</code>. More importantly, the evaluation has the side effect of defining the global function <code>disk-area</code>. In its intended usage, the function accepts the radius of a disk and returns the area of the disk computed using <code>3.14</code> as the value of pi. When the function is invoked, its body is evaluated with respect to a lexical environment binding, in the value namespace, the variable <code>r</code> to the argument of the invocation (that is, the radius of the disk).</p>
<pre class="repl">> (disk-area 2)⏎<br>12.56</pre>
<pre class="repl">> (fdef disk-area (r) (* *pi* r r))⏎<br>disk-area</pre>
<p>The evaluation has the side effect of redefining the global function <code>disk-area</code> to compute the area of the disk using the value of the global variable <code>*pi*</code> as the value of pi. It is customary for a global or dynamic variable to have a name starting and ending with an asterisk.</p>
<pre class="repl">> (disk-area 2)⏎<br>ERROR: The variable '*pi*' is unbound in the VALUE namespace.</pre>
- <p>The evaluation completes abnormally because the global variable <code>*pi*</code> is undefined.</p>
+ <p>The evaluation completes abruptly with a reason of type <code>error</code> because the global variable <code>*pi*</code> is undefined.</p>
<pre class="repl">> (vdef *pi* 3.141593)⏎<br>*pi*</pre>
<p>The evaluation produces a result consisting of the variable <code>*pi*</code>. More importantly, the evaluation has the side effect of defining the global variable <code>*pi*</code>.</p>
<pre class="repl">> *pi*⏎<br>3.141593</pre>
<li>Otherwise, if the first nonblank character before the cursor position is the last character of a top-level form, then that form is selected for evaluation.</li>
<li>Otherwise, no form is selected for evaluation and no evaluation takes place.</li>
</ul>
- <p>If the evaluation of the top-level form completes normally, then the printable representations of the resulting values are printed in the minibuffer, separated by a comma. If the evaluation of the top-level form completes abnormally, then a message describing the error is printed in the minibuffer. If the evaluation of the top-level form does not complete, then no new evaluation is possible until the evaluation is aborted or the evaluator is restarted.</p>
+ <p>If the evaluation of the top-level form completes normally, then the printable representations of the resulting values are printed in the minibuffer, separated by a comma. If the evaluation of the top-level form completes abruptly, then the reason is necessarily of type <code>error</code> and its payload is printed in the minibuffer. If the evaluation of the top-level form does not complete, then no new evaluation is possible until the evaluation is aborted or the evaluator is restarted.</p>
<h4 id="load-buffer">Load Buffer</h4>
<p>Evaluates the top-level forms contained inside the selected file buffer.</p>
<p>This command is only available when the selected window displays the contents of an EVLambda source file.</p>
<p>The top-level forms contained inside the selected file buffer are evaluated as if they were part of a progn-form.</p>
- <p>If the evaluation of the progn-form completes normally, then the printable representations of the resulting values are printed in the minibuffer, separated by a comma. If the evaluation of the progn-form completes abnormally, then a message describing the error is printed in the minibuffer. If the evaluation of the progn-form does not complete, then no new evaluation is possible until the evaluation is aborted or the evaluator is restarted.</p>
+ <p>If the evaluation of the progn-form completes normally, then the printable representations of the resulting values are printed in the minibuffer, separated by a comma. If the evaluation of the progn-form completes abruptly, then the reason is necessarily of type <code>error</code> and its payload is printed in the minibuffer. If the evaluation of the progn-form does not complete, then no new evaluation is possible until the evaluation is aborted or the evaluator is restarted.</p>
<h4>Abort Evaluation</h4>
<p>Aborts the current evaluation.</p>
<h4>Restart Evaluator…</h4>
home / projects / evlambda.git / commitdiff