The ChoiceLink is a kind of Link used during pattern matching, to indicate that any one of several different terms need to be grounded. The ChoiceLink presents a menu of choices or possibilities. For specifying a choice of types, use the TypeChoice link.
The ChoiceLink was originally invented to support the concept of a menu in the pattern matcher. That is, the goal was to match this pattern, or to match that pattern, but not both (it might be impossible to match both, simultaneously). This is discussed further, below.
In the AtomSpace, pattern matching is an inherently procedural device: when triggered, it runs and returns results. However, the ChoiceLink can also be used in declarative contexts, to declare a menu of items.
Menus are generically important for describing various real-world problems, logic problems, and computer science problems. In the real world, e.g. vending machines, you only get to choose exactly one item, after depositing your money. Abstractly, this is described by linear logic. In computer science, choice is required to discuss mutex locks and semaphores: only one, and exactly one thread can execute a section protected by a mutex or semaphore.
In type theory, the ChoiceLink corresponds to the sum type, and thus is a form of disjoint union; it is the coproduct in the category of sets. The product, of course, is the product type. The AtomSpace allows both of these, when working with types: use the TypeChoice link for sum types, and the SignatureLink for product types (see also the proposed TypeProduct).
The ChoiceLink will accept a pattern match if any of the choices can be found in the AtomSpace. Thus, for example,
ChoiceLink Atom A Atom B Atom C
means the same thing as
OrLink PresentLink Atom A PresentLink Atom B PresentLink Atom C
Caution: At this time, PresentLink is incompletely implemented, and the above combination of PresentLink and OrLink does not work. If this is what you want to do, use ChoiceLink instead! (If this seems too burdensome for some reason, open a github issue or complain loudly on the mailing list if you need this to work.)
It is treated as a menu of items from which a selection can be made. Thus for example, the following pattern
AndLink ChoiceLink InheritanceLink VariableNode $x ConceptNode "monkey" InheritanceLink VariableNode $x ConceptNode "mushroom" ChoiceLink InheritanceLink VariableNode $x ConceptNode "six toes" InheritanceLink VariableNode $x ConceptNode "mycelium"
states that $x, whatever it is, is either a monkey or a mushroom, and that it also has either six toes or a mycelium. ChoiceLinks may be nested with AndLinks to form arbitrarily complex pattern-matching expressions.
Note that ChoiceLinks do NOT bind their variables: the four notations $x in the example above all refer to the same variable. That is, the variable declaration "leaks out" of the ChoiceLink; the variable $x is free.
A ChoiceLink with just a single subterm effectively tests whether that term is present or absent in the atomspace. Thus, ChoiceLinks are related to PresentLink: when these have only one argument, they are identical. For multiple arguments they are related in the same way that or is related to and: only one term in a ChoiceLink needs to be grounded, whereas all of the terms in a PresentLink must be grounded.
Thus, for example,
AndLink ChoiceLink Atom A ChoiceLink Atom B
is the same as
PresentLink Atom A Atom B
At this time, it is not advisable to combine ChoiceLink with NotLink, probably because it does not work in the current atomspace implementation (open a github issue or complain loudly on the mailing list if you need this to work.). That is, in principle, the expression
NotLink ChoiceLink Atom A
should be identical to the expression
AbsentLink Atom A
but in practice, I think this fails.
ChoiceLinks were implemented in early 2015, and they work well; they are tested by ChoiceLinkUTest.