GroIMP wiki

a part of grogra.de

User Tools

Site Tools

Trace:
You are here: GroIMP documentation » User tutorials » RGG coding » RGG Code structure introduction
02_user_tutorials:13_rgg:02_rgg-code-structure

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
02_user_tutorials:13_rgg:02_rgg-code-structure [2025/12/10 13:14] – ↷ Page moved from 02_new_tutorials:13_rgg:02_rgg-code-structure to 02_user_tutorials:13_rgg:02_rgg-code-structure gaetan02_user_tutorials:13_rgg:02_rgg-code-structure [2025/12/12 13:21] (current) – [Queries] groimp
Line 1: Line 1:
 +~~NOTOC~~
 ====== RGG Code structure introduction ====== ====== RGG Code structure introduction ======
  
-The RGG programming language repents the core of almost all GroIMP models. It is used to describe the simulation and analysis of the models and can be quite overwhelming at first. This tutorial describes the basic concept and the structure of a simple simulation.  +The RGG programming language repents the core of almost all GroIMP models.  
- +This language extends java and implements the XL-language specification (https://manual.grogra.de/XL/index.html), to enable rule based graph manipulation.
- +
-===== RGG ===== +
- +
-The language extends java and implements the XL-language specification (https://manual.grogra.de/XL/index.html), to enable rule based graph manipulation.+
  
 This leads to a programming language based on two paradigms, the object orientation of java and the rule based structure of XL. In order to separate these two rgg is using different brackets to define code blocks.  This leads to a programming language based on two paradigms, the object orientation of java and the rule based structure of XL. In order to separate these two rgg is using different brackets to define code blocks. 
 The java blocks are framed by curly brackets ''{...}'' and the xl blocks by square brackets ''[...]''. These blocks can be embedded into each other recursively and share declared variables.  The java blocks are framed by curly brackets ''{...}'' and the xl blocks by square brackets ''[...]''. These blocks can be embedded into each other recursively and share declared variables. 
  
-===== functions =====+===== Functions =====
  
 Even so the function declaration follows the syntax of java, the body of the function can be of both code blocks. In difference to java rgg code allows to start directly with the declaration of functions without creating a class before. (Internally the rgg file is handled as one java class).  Even so the function declaration follows the syntax of java, the body of the function can be of both code blocks. In difference to java rgg code allows to start directly with the declaration of functions without creating a class before. (Internally the rgg file is handled as one java class). 
Line 32: Line 29:
 ===== Java blocks ===== ===== Java blocks =====
  
-The java block allow java syntax up to java 1.6.( this is independent from the java version that is used to run GroIMP). Therefore it is possible to use features such as file reading and writing, mathematical calculations, abstraction/inheritance or library functions. If you are not experienced with java it might be useful for you to look into available online tutorials.(For example https://www.w3schools.com/java/default.asp)+The java block allow java syntax up to java 1.6. (this is independent from the java version that is used to run GroIMP). Therefore it is possible to use features such as file reading and writing, mathematical calculations, abstraction/inheritance or library functions. If you are not experienced with java it might be useful for you to look into available online tutorials.(For example https://www.w3schools.com/java/default.asp)
  
 Every new rgg file also imports by default a set of library functions that are used to interact with the graph or the GroIMP platform. This functions can be explored in the function explorer in the software. You can find it on the main menu under 'Help/Function Browser'.  Every new rgg file also imports by default a set of library functions that are used to interact with the graph or the GroIMP platform. This functions can be explored in the function explorer in the software. You can find it on the main menu under 'Help/Function Browser'. 
Line 44: Line 41:
 The parameters are unlink in a java class directly defined in the head of the module (see below 'float len') and the code executed on the initialization of a module is defined by just a second par of curly brackets (see below {setShader(GREEN);}). The parameters are unlink in a java class directly defined in the head of the module (see below 'float len') and the code executed on the initialization of a module is defined by just a second par of curly brackets (see below {setShader(GREEN);}).
  
-Besides that the main difference is the use case. A module is always a GroIMP Node, meaning it can be added to the GroIMP simulation graph (ProjectGraph) similar to [[01_user_documentation:groimp-platform:turtle_commands|turtle commands]] or the base 3d Objects. +Besides that the main difference is the use case. A module is always a GroIMP Node, meaning it can be added to the GroIMP simulation graph (ProjectGraph) similar to [[15_cheatsheet:turtle_commands|turtle commands]] or the base 3d Objects. 
  
 <code java> <code java>
Line 57: Line 54:
 </code> </code>
  
 +Its syntax is simple and provisional, changes or extensions are likely to occur.
 +
 +The simplest form of a module declaration is
 +
 +<code java>
 +module SimpleModule;
 +</code>
 +
 +which declares a module of name SimpleModule with no fields. These simple modules can be useful for aggregations, multi scaling or just as place holders. 
 +
 +
 +The addition of fields is done as in
 +
 +<code java>
 +module ModuleWithFields (int type, String name);
 +</code>
 +
 +If o is an instance of ModuleWithFields, the usual Java syntax o.type can be used to access a field. This form of a module declaration provides a constructor with parameters corresponding to the specified module parameters.
 +
 +A module is a part of the Java class hierarchy. It is possible for a module to be a subclass of another class or module, this is indicated by an extends-clause:
 +
 +<code java>
 +module Sub (super.type, super.name, int extra) extends ModuleWithFields;
 +</code>
 +
 +The module Sub is a subclass (submodule) of ModuleWithFields. The fields type and name are inherited from ModuleWithFields, extra is a new field. A constructor having three parameters (type, name, extra) is provided. It looks for a superclass constructor applicable to the inherited arguments type, name of type int, String (which is found in ModuleWithFields).
 +
 +Sometimes, not all module parameters are to be inherited. In these cases, one has to specify the superclass constructor to be used by explicitly providing its arguments as in
 +
 +<code java>
 +module Sub2 (super.name) extends ModuleWithFields (1, name);
 +</code>
  
-It is also possible to have modules that do not extend any other object and have no direct effect on the graph. These nodes can be useful for aggregations, multi scaling or just as place holders.  
  
 ==== Instantiation ==== ==== Instantiation ====
Line 80: Line 108:
 ==== Queries ==== ==== Queries ====
  
-In GroIMP the project graph is considered to hold almost all information on the simulation. Therefore it can also be seen as a knowledge graph. To retrieve this knowledge rgg uses the [[02_old_tutorials:tutorials:common_graph_queries|XL query system]]. To use this queries in a java block they have to be framed by ''(*...*)'' as shown in the examples below. In that way they return a collection object, which then can be like other java objects. Moreover GroIMP comes with a set of predefined  [[01_user_documentation:groimp-platform:xl-builtin-methods|Analytical methods]] to analyze this collections.+In GroIMP the project graph is considered to hold almost all information on the simulation. Therefore it can also be seen as a knowledge graph. To retrieve this knowledge rgg uses the [[01_user_documentation:07_rgg_xl:02_xl:03_query|XL query system]]. To use this queries in a java block they have to be framed by ''(*...*)'' as shown in the examples below. In that way they return a collection object, which then can be like other java objects. Moreover GroIMP comes with a set of predefined  [[:15_cheatsheet:operators|Analytical methods]] to analyze this collections.
  
 As shown in the example below in ''%%count((*M*))%%'' this queries work with the concept of java objects. Therefore ''(*M*)'' is selecting all instances of Branch because Branch extends M. This also works with interfaces.  As shown in the example below in ''%%count((*M*))%%'' this queries work with the concept of java objects. Therefore ''(*M*)'' is selecting all instances of Branch because Branch extends M. This also works with interfaces. 
Line 109: Line 137:
  
 Since java 1.6 did not include lamda expression, an own implementation was added to rgg.  Since java 1.6 did not include lamda expression, an own implementation was added to rgg. 
-The syntax an the explanation can be found [[01_user_documentation:groimp-platform:xl-lambda|here]]  +The syntax an the explanation can be found [[01_user_documentation:07_rgg_xl:02_xl:09_java_addition:xl_lambda|here]] 
-===== XL Blocks =====+
  
-While using XL queries mainly two rules are used: replacement rules(''%%==>%%'') and execution rule (''%%::>%%''). + 
 +===== XL Blocks - Rules ===== 
 + 
 +While using XL queries mainly three rules are used: 
    
 +  * Graph rules (''%%==>>%%'')
 +  * String replacement rules (''%%==>%%'')
 +  * Update or Execution rules (''%%::>%%'')
 +
 +All rules have in common that we have a left and a right hand side, both are separated by one of the arrows.
 +
 +
 +=== Graph rules ===
 +
 +Graph rules are indicated by the rule arrow ''%%==>>%%''. 
 +
 +The right hand side is a semicolon-terminated list of graph statements building the replacing graph for the matched graph. While the left hand side represents a fixed graph pattern, the graph statements can build the replacing graph dynamically, including loops and conditional execution. Thus it is not always possible to find a graphical representation of the right hand side.
 +
 +The graph statements use a stack s of nodes and two state variables n – the last created node – and e – the next edge to create – during execution. 
 +
 +After the execution of all graph statements, a final step is executed (if the execution has not been terminated using break): A matching non-context node instance of the left hand side, which has not been the value of an evaluated node expression of the right hand side, is deleted. Similarly, an edge matching a non-context edge pattern of the left hand side is deleted if it is not specified on the right hand side.
 +
  
-==== Replacement rules ====+=== String rules ===
  
-The concept of an replacement rule is basically that all part of the project graph that are similar to the left part (before ''%%==>%%'') are replaced by the right part( behind ''%%==>%%'').  +The concept of an replacement rule in XL follows the 'Lindenmayer-form' where basically all parts of the project string that are similar to the left part (before ''%%==>%%'') are replaced by the right part ( behind ''%%==>%%'').  
-The left part can thereby be any [[02_old_tutorials:tutorials:common_graph_queries|xl-query]].+The left part can thereby be any [[tutorials:common_graph_queries|xl-query]].
 The right part (the production) is a collection of Nodes ( instances of either turtle commands, 3d objects or modules) which are linked by different edges. In the example below only successor- and branch-edges are used. A node that is separated to its predecessor by only a white space is added as a sucessor to the predecessor. A Node or a set of nodes framed by square brackets in that is added to the predecessor with a branch-edge.  The right part (the production) is a collection of Nodes ( instances of either turtle commands, 3d objects or modules) which are linked by different edges. In the example below only successor- and branch-edges are used. A node that is separated to its predecessor by only a white space is added as a sucessor to the predecessor. A Node or a set of nodes framed by square brackets in that is added to the predecessor with a branch-edge. 
  
Line 134: Line 181:
 As shown above it is also possible to forward parameters from the left side to the right (similar to a parametric rewriting rule in formal systems). Moreover it is possible to use ''a:A''  instead of ''A(x)'' and then on the right side ''a.len'' instead of ''x''.  As shown above it is also possible to forward parameters from the left side to the right (similar to a parametric rewriting rule in formal systems). Moreover it is possible to use ''a:A''  instead of ''A(x)'' and then on the right side ''a.len'' instead of ''x''. 
  
-==== Execution rule ====+=== Execution rule ===
  
-The left side of an execution rule is similar to the left side of the production rule. Yet the main difference is that the nodes (or pattern of nodes) found by the query are not replaced. Instead the code on the right side is applied on them. +The left side of an execution rule is similar to the left side of the production rule. Yet the main difference is that the nodes (or pattern of nodes) found by the query are not replaced. Instead the (Java) code on the right side is applied on them.
  
 <code java> <code java>
Line 156: Line 203:
 ] ]
 </code> </code>
 +
 +There are no additional actions executed, so update rules don’t change the topological properties of the
 +host graph per se.
  
  
02_user_tutorials/13_rgg/02_rgg-code-structure.1765368851.txt.gz · Last modified: 2025/12/10 13:14 by gaetan