|
|
@@ -74,8 +74,92 @@ When debugging the MvS, however, these status codes can come in handy.</p>
|
|
|
</div>
|
|
|
<div class="section" id="modelverse-kernel">
|
|
|
<h2>Modelverse Kernel<a class="headerlink" href="#modelverse-kernel" title="Permalink to this headline">¶</a></h2>
|
|
|
+<p>The Modelverse Kernel is basically a graph transformation kernel.
|
|
|
+It consists of two parts: a small transformation engine (only a few lines in Python), and a copy of all rules it knows.
|
|
|
+Most code is an encoding of these transformation rules, and can (theoretically) be automatically generated by the Modelverse itself.
|
|
|
+This is currently not top priority, but will probably be implemented in the future.</p>
|
|
|
+<p>The transformation rules are an encoding of the rules presented in the specification mentioned at the top of this page.
|
|
|
+In each rule, the MvK needs to have tight communication with the MvS.
|
|
|
+For this, the rules are encoded using <em>yield</em> operations in Python.
|
|
|
+Rules therefore act as generators, outputting commands to the MvS, and immediately getting a reply.
|
|
|
+Each individual yield contains a list of operations to send to the MvS simultaneously.
|
|
|
+The result will therefore also be a list of results for each operation.</p>
|
|
|
+<p>As you can see in these rules, each entry in the list has a specific form.
|
|
|
+An entry is a tuple containing two elements: the code of the operation to execute, followed by a list of all parameters to pass.
|
|
|
+The code is a shortened name for the operation, such as <em>CN</em> for <em>create_node</em>.
|
|
|
+A full mapping can be found in the MvS, the most important ones are shown below.</p>
|
|
|
+<table border="1" class="docutils">
|
|
|
+<colgroup>
|
|
|
+<col width="20%" />
|
|
|
+<col width="80%" />
|
|
|
+</colgroup>
|
|
|
+<thead valign="bottom">
|
|
|
+<tr class="row-odd"><th class="head">Code</th>
|
|
|
+<th class="head">Function</th>
|
|
|
+</tr>
|
|
|
+</thead>
|
|
|
+<tbody valign="top">
|
|
|
+<tr class="row-even"><td>CN</td>
|
|
|
+<td>create_node</td>
|
|
|
+</tr>
|
|
|
+<tr class="row-odd"><td>CNV</td>
|
|
|
+<td>create_nodevalue</td>
|
|
|
+</tr>
|
|
|
+<tr class="row-even"><td>CE</td>
|
|
|
+<td>create_edge</td>
|
|
|
+</tr>
|
|
|
+<tr class="row-odd"><td>CD</td>
|
|
|
+<td>create_dict</td>
|
|
|
+</tr>
|
|
|
+<tr class="row-even"><td>RV</td>
|
|
|
+<td>read_value</td>
|
|
|
+</tr>
|
|
|
+<tr class="row-odd"><td>RE</td>
|
|
|
+<td>read_edge</td>
|
|
|
+</tr>
|
|
|
+<tr class="row-even"><td>RD</td>
|
|
|
+<td>read_dict</td>
|
|
|
+</tr>
|
|
|
+<tr class="row-odd"><td>RDN</td>
|
|
|
+<td>read_dict_node</td>
|
|
|
+</tr>
|
|
|
+<tr class="row-even"><td>DN</td>
|
|
|
+<td>delete_node</td>
|
|
|
+</tr>
|
|
|
+<tr class="row-odd"><td>DE</td>
|
|
|
+<td>delete_edge</td>
|
|
|
+</tr>
|
|
|
+</tbody>
|
|
|
+</table>
|
|
|
+<div class="admonition note">
|
|
|
+<p class="first admonition-title">Note</p>
|
|
|
+<p>Since each yield operation works on lists even a single operation needs to be wrapped in a list.
|
|
|
+Worse, however, is that the return value will also be a list.
|
|
|
+Instead of having to take the first element each time, Python allows you to write a comma after the variable, to make it expand it automatically.
|
|
|
+Your syntax thus becomes:</p>
|
|
|
+<div class="highlight-default"><div class="highlight"><pre><span class="n">a</span><span class="p">,</span> <span class="o">=</span> <span class="k">yield</span> <span class="p">[(</span><span class="s">"CN"</span><span class="p">,</span> <span class="p">[])]</span>
|
|
|
+</pre></div>
|
|
|
+</div>
|
|
|
+<p class="last">Where a will now already contain the created node, and not a list with as first (and only) element the created node.</p>
|
|
|
+</div>
|
|
|
+<div class="section" id="primitives">
|
|
|
+<h3>Primitives<a class="headerlink" href="#primitives" title="Permalink to this headline">¶</a></h3>
|
|
|
+<p>The Modelverse Kernel also defines the primitives users can use.
|
|
|
+Primitives are necessary since we can’t go deeper at some point.
|
|
|
+It is the MvK’s responsibility to implement each and every primitive defined in the bootstrap file.</p>
|
|
|
+<p>Primitives are implemented in the bootstrap file as having a body with an empty node.
|
|
|
+When execution goes to this node, the MvK must execute the associated primitive instead.
|
|
|
+To do this, the MvK must map all these nodes to their corresponding primitive implementation during startup.</p>
|
|
|
+</div>
|
|
|
<div class="section" id="precompiled-functions">
|
|
|
<h3>Precompiled functions<a class="headerlink" href="#precompiled-functions" title="Permalink to this headline">¶</a></h3>
|
|
|
+<p>Similar to primitives, the MvK also supports precompiled functions.
|
|
|
+A precompiled function is similar to a primitive in terms of implementation, but they do also have an implementation inside of the Modelverse itself.
|
|
|
+This means that there are two implementations: one hardcoded, and one in action language.
|
|
|
+Both should obviously be consistent.</p>
|
|
|
+<p>Whereas primitives are required for a functional Modelverse, precompiled functions are only a performance optimization, and can be disabled by the user for debugging purposes.
|
|
|
+This is interesting, since with precompiled functions, no intermediate values will be visible.
|
|
|
+Additionally, precompiled functions cannot be changed, as they are Python code instead of being explicitly modelled.</p>
|
|
|
</div>
|
|
|
</div>
|
|
|
<div class="section" id="modelverse-interface">
|
|
|
@@ -175,6 +259,7 @@ A restart of the MvK is needed for Python to pick up the new functions.</p>
|
|
|
</ul>
|
|
|
</li>
|
|
|
<li><a class="reference internal" href="#modelverse-kernel">Modelverse Kernel</a><ul>
|
|
|
+<li><a class="reference internal" href="#primitives">Primitives</a></li>
|
|
|
<li><a class="reference internal" href="#precompiled-functions">Precompiled functions</a></li>
|
|
|
</ul>
|
|
|
</li>
|
