This is an old revision of the document!
Table of Contents
In RGG
Custom patterns can be created in RGG with the simple syntax:
class patternName(@In Node a, @Out Node b) ( // some patterns )
Declaring In/Out
Custom patterns requires to declare variable with both annotations @In and @Out. It can be two different variables, or the same one. E.g.
class patternName(@In Node a, @Out Node b) ( ) // different variables for @In and @Out class patternName(@In @Out Node a) ( ) // same variable for both @In and @Out
The @In variable is mapped to the incoming pattern, the @Out variable to the outgoing pattern. If @In and @Out is the same variable, the variable is mapped to both the incoming and outgoing patterns.
Using In/Out
When declaring custom patterns, it is required to declare the variables @In and @Out because they declare how the pattern is integrated in the query (among the other patterns). However, it is not required to include them when defining the custom pattern. Even when they are not used by the custom pattern, they still are used by the query to map the pattern. Thus, as long as the variable @In@Out is/are used in the pattern, it is quite simple to understand how the pattern is interpreted. It get a bit more tricky when these variables are not used. Indeed, it might “close” or “open” the patterns to the other patterns in the query.
For instance:
class p(@In Node a, @Out Node b) ( a > Node ) // the @Out (b) is not used. class p(@In Node a, @Out Node b) ( Node > b ) // the @In (a) is not used. class p(@In Node a, @Out Node b) ( a > b ) // both @In and @Out are used. class p(@In @Out Node a) ( Node ) // the @In @Out is not used
These patterns are different and will match different results.
Additional variables
Custom patterns can have additional variables. These variables works like query variables.
class p(@In @Out Node a, int var1, Object var2) ( a > Node(var1, var2) )
Open ends
Custom patterns do not require to define a “closed” pattern. It means that the pattern can start/ end with an “open” predicate (e.g. an edge pattern). The pattern will match the existence of such open predicate using implicitly a default Node object to close the pattern. The Node used implicitly is then considered as “bound” and cannot be matched again by the same pattern. For instance:
class p(@In @Out Node n) ( n > ) // Test if the variable @In@Out has a successor edge toward anything
Context
The notion of context in the rule-based paradigm refers to some structure which has to exist within the current host structure and which is related in some way with the match, but which is not replaced on rule application. Thus, in a query, marking context on some predicate enable to use these patterns to match and ensure that the Nodes bounded by these patterns will not be removed or replaced.
Context is marked by asterisked parenthesis: (* and *). These are the same symbols used for declaring query expressions, but the two concepts are different.
In the case of custom patterns it defines if the Node matched by this pattern are “kept” after the matching. The custom patterns simply forward the context of their caller query to their own pattern. For instance:
void rule()[ Node -p-> Node ==>; // p is not a context Node -p-> Node ::>; // p is a context Node (* -p-> Node *) ==>; // p is a context ]
A custom pattern p that is not a context makes all Nodes bound by its matching transient. Even the Node implicitly bounded.
- context
- node pattern / edge pattern.
Examples
// declaration class xyzPath(@In Node a, @Out Node b) ( a -x-> -y-> -z-> b ) //usage void rule() [ Node -xyzPath-> Node ==>; ]