Three steps to syntax harmony

Ulrich Neumerkel, 2010-06-09 (Version history)


Feliks Kluzniak (United States). Manuel Hermenegildo (Spain).


Currently, most Prolog processors support implementation specific extensions to allow | 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.

Step 1 New Operator

Add op(1105,xfy,'|') to the standard operator table (, Table 7).

This makes terms like ( a '|' b ). portable.


Currently, this is a valid extension as defined by 5.5.2 Predefined operators.


GNU, SWI, YAP. This is possible in all standard compliant systems.


[JS1] suggest to use 1150 or 1110 as precedence. The use of 1150 conflicts with the usage of implementation specific but frequently used operators for directives. B, CIAO, Cx, SICStus, SWI, XSB, YAP have 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.

Step 2 Unquoted | as infix

Allow | to be used unquoted as infix operator. It represents either ('|')/2 or (;)/2.


There are several ways to incorporate this extension into the existing grammar. All cases of ambiguity such as [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 infix '|'.


Currently, this is a valid extension as defined in 5.5.1 Syntax.


SICStus, XSB 3.2 and the systems mentioned in step 3.

Step 3 Concrete mapping

Map infix | to ('|')/2. This step fully supports CHR on the syntax level.


B, CIAO, ECLiPSe (via a flag), GNU, IF, Qu, SWI, YAP already support this step.


[JS1] 2010-06-26 Joachim Schimpf
Validated HTML