|as an infix operator. These extensions are used to represent alternation within DCGs and the commit-operator for CHRs. Without such an extension, support for DCGs and CHRs is incomplete. For example, the following DCG rule cannot be written without an appropriate extension.
a --> b | c.Unfortunately, Prolog processors support
|in subtly different ways. This document proposes to remove differences with three steps of harmonization. It is the sequel to a document surveying current syntax extensions.
In 13211-1:1995, the unquoted
| can be used in a
single situation: within list notation (6.3.5) as a head tail
separator (6.5.3). All other uses are thus syntax extensions and
predefined operator extensions in the sense of 5.5.1 and 5.5.2.
op(1105,xfy,'|')to the standard operator table (184.108.40.206, Table 7).
This makes terms like
( a '|' b ). portable.
op(1150,fx,dynamic)defined. Most users search a new operator precedence by taking the middle of the free interval in question, the free space is thus 1101..1149. 1105 was chosen by CHR developers to minimize the impact this might have on DCGs.
|to be used unquoted as infix operator. It represents either
[a|b|c]shall remain invalid syntax. Open to discussion is the question whether or not the operator declaration of
'|'should be changeable — similarly to
In this manner uses of
| within DCGs become portable
already. However, uses within CHR must still resort to the quoted
('|')/2. This step fully supports CHR on the syntax level.