FilterLink
The FilterLink is a proposed (unimplemented) atom type that performs filtering of a set, to reject set elements that do not match a pattern. In many ways, it behaves like GetLink, except that it does not search the entire atomspace; instead, it only searches it's input set.
A minor variation of this idea is presented at the bottom of the PutLink article. In that case, filtering and substitution is performed in one step, with the result behaving like a BindLink (instead of a GetLink, as described here).
Another variation of the FilterLink can be found in the MapLink, which acts as a dual to PutLink: the MapLink un-beta-reduces expressions, extracting values from them. It performs type checking as it does so, and so also implements a kind-of filtering.
It seems like it might be possible to implement FilterLink entirely with MapLink ... in which case, FilterLink is not really needed?
Definition
Filters could be specified as shown below, or by using a SignatureLink.
The FilterLink would have the form
FilterLink <filter definition> SetLink <set of items to be filtered>
Execution of the FilterLink would return a SetLink of everything that passed through the filter.
Thus, for example:
FilterLink EvaluationLink # This defines the filter PredicateNode "foo" ListLink Variable $x Variable $y SetLink # This is the set to be filtered EvaluationLink PredicateNode "foo" ListLink Atom A Atom B EvaluationLink PredicateNode "bar" ListLink Atom C Atom D
would extract the values of A and B from the "foo" clause, but ignore the "bar" clause, because it does not match the input filter.
Signatures as filters
Note that the variable declarations in the filter above play no significant role. Thus, it might be better to define filters with SignatureLinks. Thus, the above example can be written as:
FilterLink SignatureLink EvaluationLink # This defines the filter PredicateNode "foo" ListLink TypeNode "ConceptNode" TypeNode "ConceptNode" SetLink # This is the set to be filtered EvaluationLink PredicateNode "foo" ListLink ConceptNode A ConceptNode B EvaluationLink PredicateNode "bar" ListLink ConceptNode C ConceptNode D EvaluationLink PredicateNode "foo" ListLink WordNode E WordNode F
Notice that the variable parts in the above expression are now type-constrained to be ConceptNodes. Thus, as a result, the third input, "foo E F" would be rejected because E and F are WordNodes, not ConceptNodes.