Browse Source

Most documentation on internal workings is there, but very high-level

Yentl Van Tendeloo 8 years ago
parent
commit
81d9c1ec74

BIN
doc/_build/doctrees/internal.doctree


+ 42 - 0
doc/_build/html/_sources/internal.txt

@@ -104,21 +104,63 @@ Additionally, precompiled functions cannot be changed, as they are Python code i
 Modelverse Interface
 --------------------
 
+Finally, we come to the Modelverse Interface.
+For the moment, this is only a simple compiler that takes action language or model language files and translates them to something the Modelverse can understand.
+There are basically two kinds of operations the Modelverse can understand: direct graphs, or a list of constructors.
+The use of direct graphs is deprecated, as constructors are much more elegant (but slower).
+Future changes should make constructors as fast as the use of graphs.
+Nonetheless, which approach is used does not matter for the action language or model language files.
+
+The parser used for this simple front-end is the HUTN parser.
+It creates an abstract syntax tree, which is then traversed by a series of visitors.
+The visitors that are used, depends on the selected mode of compilation.
+We briefly present the most important visitors.
+
 Semantics visitor
 ^^^^^^^^^^^^^^^^^
 
+The visitor most oftenly used is the Semantics visitor.
+It traverses the abstract syntax tree and constructs symbol tables and finds all declarations of functions.
+Additionally, it also translates the use of operators to their Modelverse functions.
+
+This visitor in itself does not output anything, but it modifies the existing abstract syntax tree.
+It is used as a first step for most other visitors.
+
 Constructors visitor
 ^^^^^^^^^^^^^^^^^^^^
 
+The most important visitor is the constructors visitor.
+It traverses the abstract syntax tree and outputs a list of strings that make it possible for the MvK to construct the required code in the Modelverse.
+The use of constructors has several advantages, but the primary advantage is that the interface does not have to know about the internal representation of action language in the Modelverse.
+However, the order of constructors and accepted keywords needs to be defined (in action language), and made available to the users.
+As this interface is explicitly modelled as well, it is possible for users to modify it without affecting the interface.
+This is bad if the interface suddenly accepts new keywords or removes support for old keywords.
+
+During the execution of the visitor, it would already be possible to start transmitting the list to the Modelverse, such that the Modelverse can create the code in parallel with the actual parsing.
+While this is possible, we currently split this up in different phases: first the list is generated completely, and then it is transferred to the Modelverse in a single request.
+
 Primitives visitor
 ^^^^^^^^^^^^^^^^^^
 
+The primitives visitor generates a Modelverse graph directly.
+Its use is deprecated, as the constructors are much more elegant.
+While direct use of this visitor is not recommended, except for performance reasons, the bootstrap visitor (discussed next) is based on this visitor.
+
+This visitor creates a serialized version of the graph and transmits it to the Modelverse.
+The Modelverse has a built-in primitive to decode this graph and store it.
+
 Bootstrap visitor
 ^^^^^^^^^^^^^^^^^
 
+Despite the primitives visitor being deprecated, the bootstrap visitor still needs access to this kind of output, since it cannot use constructors: during bootstrapping, the Modelverse is not yet available.
+The actual output format slightly differs from the primitives visitor, but the core concepts are identical.
+
 Model visitor
 ^^^^^^^^^^^^^
 
+Finally, the model visitor is similar to the constructor visitor, but goes to a different constructor interface, which supports modelling operations instead of action language operations.
+This is a very preliminary visitor.
+
 Bootstrapping
 -------------
 

+ 32 - 0
doc/_build/html/internal.html

@@ -164,20 +164,52 @@ Additionally, precompiled functions cannot be changed, as they are Python code i
 </div>
 <div class="section" id="modelverse-interface">
 <h2>Modelverse Interface<a class="headerlink" href="#modelverse-interface" title="Permalink to this headline">¶</a></h2>
+<p>Finally, we come to the Modelverse Interface.
+For the moment, this is only a simple compiler that takes action language or model language files and translates them to something the Modelverse can understand.
+There are basically two kinds of operations the Modelverse can understand: direct graphs, or a list of constructors.
+The use of direct graphs is deprecated, as constructors are much more elegant (but slower).
+Future changes should make constructors as fast as the use of graphs.
+Nonetheless, which approach is used does not matter for the action language or model language files.</p>
+<p>The parser used for this simple front-end is the HUTN parser.
+It creates an abstract syntax tree, which is then traversed by a series of visitors.
+The visitors that are used, depends on the selected mode of compilation.
+We briefly present the most important visitors.</p>
 <div class="section" id="semantics-visitor">
 <h3>Semantics visitor<a class="headerlink" href="#semantics-visitor" title="Permalink to this headline">¶</a></h3>
+<p>The visitor most oftenly used is the Semantics visitor.
+It traverses the abstract syntax tree and constructs symbol tables and finds all declarations of functions.
+Additionally, it also translates the use of operators to their Modelverse functions.</p>
+<p>This visitor in itself does not output anything, but it modifies the existing abstract syntax tree.
+It is used as a first step for most other visitors.</p>
 </div>
 <div class="section" id="constructors-visitor">
 <h3>Constructors visitor<a class="headerlink" href="#constructors-visitor" title="Permalink to this headline">¶</a></h3>
+<p>The most important visitor is the constructors visitor.
+It traverses the abstract syntax tree and outputs a list of strings that make it possible for the MvK to construct the required code in the Modelverse.
+The use of constructors has several advantages, but the primary advantage is that the interface does not have to know about the internal representation of action language in the Modelverse.
+However, the order of constructors and accepted keywords needs to be defined (in action language), and made available to the users.
+As this interface is explicitly modelled as well, it is possible for users to modify it without affecting the interface.
+This is bad if the interface suddenly accepts new keywords or removes support for old keywords.</p>
+<p>During the execution of the visitor, it would already be possible to start transmitting the list to the Modelverse, such that the Modelverse can create the code in parallel with the actual parsing.
+While this is possible, we currently split this up in different phases: first the list is generated completely, and then it is transferred to the Modelverse in a single request.</p>
 </div>
 <div class="section" id="primitives-visitor">
 <h3>Primitives visitor<a class="headerlink" href="#primitives-visitor" title="Permalink to this headline">¶</a></h3>
+<p>The primitives visitor generates a Modelverse graph directly.
+Its use is deprecated, as the constructors are much more elegant.
+While direct use of this visitor is not recommended, except for performance reasons, the bootstrap visitor (discussed next) is based on this visitor.</p>
+<p>This visitor creates a serialized version of the graph and transmits it to the Modelverse.
+The Modelverse has a built-in primitive to decode this graph and store it.</p>
 </div>
 <div class="section" id="bootstrap-visitor">
 <h3>Bootstrap visitor<a class="headerlink" href="#bootstrap-visitor" title="Permalink to this headline">¶</a></h3>
+<p>Despite the primitives visitor being deprecated, the bootstrap visitor still needs access to this kind of output, since it cannot use constructors: during bootstrapping, the Modelverse is not yet available.
+The actual output format slightly differs from the primitives visitor, but the core concepts are identical.</p>
 </div>
 <div class="section" id="model-visitor">
 <h3>Model visitor<a class="headerlink" href="#model-visitor" title="Permalink to this headline">¶</a></h3>
+<p>Finally, the model visitor is similar to the constructor visitor, but goes to a different constructor interface, which supports modelling operations instead of action language operations.
+This is a very preliminary visitor.</p>
 </div>
 </div>
 <div class="section" id="bootstrapping">

File diff suppressed because it is too large
+ 1 - 1
doc/_build/html/searchindex.js


+ 42 - 0
doc/internal.rst

@@ -104,21 +104,63 @@ Additionally, precompiled functions cannot be changed, as they are Python code i
 Modelverse Interface
 --------------------
 
+Finally, we come to the Modelverse Interface.
+For the moment, this is only a simple compiler that takes action language or model language files and translates them to something the Modelverse can understand.
+There are basically two kinds of operations the Modelverse can understand: direct graphs, or a list of constructors.
+The use of direct graphs is deprecated, as constructors are much more elegant (but slower).
+Future changes should make constructors as fast as the use of graphs.
+Nonetheless, which approach is used does not matter for the action language or model language files.
+
+The parser used for this simple front-end is the HUTN parser.
+It creates an abstract syntax tree, which is then traversed by a series of visitors.
+The visitors that are used, depends on the selected mode of compilation.
+We briefly present the most important visitors.
+
 Semantics visitor
 ^^^^^^^^^^^^^^^^^
 
+The visitor most oftenly used is the Semantics visitor.
+It traverses the abstract syntax tree and constructs symbol tables and finds all declarations of functions.
+Additionally, it also translates the use of operators to their Modelverse functions.
+
+This visitor in itself does not output anything, but it modifies the existing abstract syntax tree.
+It is used as a first step for most other visitors.
+
 Constructors visitor
 ^^^^^^^^^^^^^^^^^^^^
 
+The most important visitor is the constructors visitor.
+It traverses the abstract syntax tree and outputs a list of strings that make it possible for the MvK to construct the required code in the Modelverse.
+The use of constructors has several advantages, but the primary advantage is that the interface does not have to know about the internal representation of action language in the Modelverse.
+However, the order of constructors and accepted keywords needs to be defined (in action language), and made available to the users.
+As this interface is explicitly modelled as well, it is possible for users to modify it without affecting the interface.
+This is bad if the interface suddenly accepts new keywords or removes support for old keywords.
+
+During the execution of the visitor, it would already be possible to start transmitting the list to the Modelverse, such that the Modelverse can create the code in parallel with the actual parsing.
+While this is possible, we currently split this up in different phases: first the list is generated completely, and then it is transferred to the Modelverse in a single request.
+
 Primitives visitor
 ^^^^^^^^^^^^^^^^^^
 
+The primitives visitor generates a Modelverse graph directly.
+Its use is deprecated, as the constructors are much more elegant.
+While direct use of this visitor is not recommended, except for performance reasons, the bootstrap visitor (discussed next) is based on this visitor.
+
+This visitor creates a serialized version of the graph and transmits it to the Modelverse.
+The Modelverse has a built-in primitive to decode this graph and store it.
+
 Bootstrap visitor
 ^^^^^^^^^^^^^^^^^
 
+Despite the primitives visitor being deprecated, the bootstrap visitor still needs access to this kind of output, since it cannot use constructors: during bootstrapping, the Modelverse is not yet available.
+The actual output format slightly differs from the primitives visitor, but the core concepts are identical.
+
 Model visitor
 ^^^^^^^^^^^^^
 
+Finally, the model visitor is similar to the constructor visitor, but goes to a different constructor interface, which supports modelling operations instead of action language operations.
+This is a very preliminary visitor.
+
 Bootstrapping
 -------------