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.

When used as a path pattern, the @In and @Out variable represent the incoming and outgoing Node patterns. Both are required in the query. If the custom pattern use both in its definition, the pattern can simply by resolved by “replacing” its content after @In and before @Out. For instance:

class p(@In Node a, @Out Node b) (a > b)
void rule()[
 -p-> Node ::>; // compiler error. path patterns need an In
 Node -p-> ::>; // compiler error. path patterns need an Out
 Node -p-> Node ::>; // equivalent to
 Node > Node ::>;
]

It is the same for custom pattern with more predicates:

 class p(@In Node a, @Out Node b) (D > a > b /> C) // @In and @Out do NOT have to be at the "start" and "end" of the pattern definition.
void rule()[
 A -p-> B ::>; // is equivalent to 
 A [<D] > B /> C ::>;
]

If at least one of the @In @Out is not used, the associated variable(s) is(are) mapped to null. Patterns connected by null are independent. Indeed, there are not mapping between them. Thus, an incoming pattern connected to a custom pattern which do not use the @In variable (or @Out for outgoing patterns) is independent from the pattern that follows (or that precede for outgoing patterns). For instance:

class p(@In Node a, @Out Node b) ( a > C) // the @Out (b) is not used
void rule()[
 A -p-> B A ::>; // is equivalent to 
 A > C, B A ::>; // notice the ','
 A -p-> /> B A ::> // is equivalent to (notice the edge pattern after the custom pattern)
 A > C, ^ /> B A ::>; // if an edge pattern is inserted after a pattern with an null out, it is connected to the root.
]

When @In and @Out is the same variable the principle is the same.

class p(@In @Out Node a) ( a > B)
void rule()[
 A -p-> ::>; // is equivalent to
 A > B ::>;
 A -p-> C ::>; // is equivalent to
 A [> B] C ::>; // the out of the custom pattern is A. Thus, it links the next pattern to A
]

When the @In@Out is not used, the whole custom pattern is considered independent from the current chain of patterns. For instance:

class p(@In @Out Node a) ( A > B)
void rule()[
 A -p-> C ::>; // is equivalent to
 A C , A > B ::>;
]

The declared @In@Out variable can used as a type pattern. But it is not required to use it in the pattern.

class p(@In @Out A a) ( a ) 
class p2(@In @Out A a) ( a > F) 
void rule()[
 p ::>; // Match all A 
 p2 ::>; // Match all A that have a successor F
 A p B ::>; // Match all pattern: A [> A > F] > B. Implicit creation of edges.
]