# Upgrade to Grew 1.4 (October 2020)

This page describes the breaking changes in Grew and provides the information needed to update a Graph Rewriting System and the CLI commands. For older upgrading info, see upgrade_old.

## CLI (Command Line Interface)

### the -config argument

With the new code for CoNLL-U handling, Grew must be informed of the “kind” of CoNLL-U that are used.

The config value can be: ud, sud, sequoia or basic. The default value is ud.

The config value changes the way edge labels are parsed (for instance, taking @ extension into account in SUD) and also how features are stored in CoNLL-U (columns FEATS or columns MISC).

## GRS (Graph Rewriting System)

### Add a new edge with a label taken in the pattern

In the previous version, the syntax add_edge e: N -> M was used for adding a new edge between N and M with a label identical to the edge named e in the pattern.

In the 1.4 version, the semantic of the same syntax has changed. Now, the syntax add_edge e: N -> M means: add a new edge between N and M and give it the fresh name e.

In order to have the same semantic as the previous version, the command:

add_edge e: N -> M;      # e being an edge declared in the pattern


must be replaced by:

add_edge f: N -> M;      # f is a fresh name
f.label = e.label;       # the label of f is set to be equal to the one of e.


Hopefully, this should not produce unexpected behaviour:

• If the old syntax is used with the new Grew version (≥ 1.4), the error ADD_EDGE_EXPL: the edge name 'e' already used is reported.
• If the new syntax is used with the old Grew version (< 1.4), the error Unknown identifier "f" is reported.

Constraint Old syntax New syntax
equality of two edge labels label(e1) = label(e2) e1.label = e2.label
inequality of two edge labels label(e1) <> label(e2) e1.label <> e2.label

### Avoid duplicate matching solutions

When several nodes are equivalent in a pattern, each occurrence is reported several times (up to permutation on the set of equivalent nodes). For instance, to search for two relations det with the same governor, the pattern below will return twice each solution.

pattern {
G -[det]-> D1;
G -[det]-> D2;
}


To avoid this, it is possible to give an ordering constraint on some internal identifier:

• old_syntax: id(D1) < id (D2)
• new_syntax: D1.__id__ < D2.__id__

The complete pattern in new syntax:

pattern {
G -[det]-> D1;
G -[det]-> D2;
D1.__id__ < D2.__id__;
}