Nodes from the rule test which have to be deleted are specified after
the keyword DELETE. The deletion can be done in four modes,
which can be combined, e.g. it is possible to specify MARK REMOVE
with some nodes.
The mark mode just markes the nodes, which are in a successfully
matched redex, by setting the field deleted. This is a field
which the user has to add to all types of objects which have to be
deleted.
Once the nodes are marked like this, they can be recognized as being
invalid. Marking is necessary when a node belongs to a lot of graphs,
not only those that were tested in the rule. Then subsequent passes
over these graphs can remove all incident edges, and in the last pass
also the node can be deallocated.
The redex-remove mode does not deallocate the nodes but removes the node from all the containing graphs which are mentioned in the rule test. Thus it deletes all incident edges of graphs of the rule test. There still might be other graphs the node belongs to.
The delayed-remove mode is special. It generates a second, artificial GRS. This GRS walks the graphs of the rule test a second time, tests on deleted (marked) nodes and then performs removal of incident edges.3.5 In CoSy-fSDL-mode, the walking is done via ITERLIST-LOOPs, not with LIST-LOOPs. This is due to a restriction of the fSDL-LIST functor which could not delete nodes from lists when walking the lists themselvs via LIST-LOOP.3.6
The free mode really deallocates the nodes. In AST-mode a
function Tree_delete is called.3.7
An appropriate macro or function has to be provided by the user.
In CoSy-fSDL-mode <domain>_delete. is called. This function is always
part of the DMCP interface.