# Problem with xf operator

**URL:** <https://swi-prolog.discourse.group/t/problem-with-xf-operator/6452>\
**Category:** General\
**Created:** [April 11, 2023, 12:50pm UTC](https://swi-prolog.discourse.group/t/problem-with-xf-operator/6452 "2023-04-11T12:50:46Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![ridgeworks](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/ridgeworks/32/886_2.png) [@ridgeworks](https://swi-prolog.discourse.group/u/ridgeworks)\
**Post date:** [April 13, 2023, 5:21pm UTC](https://swi-prolog.discourse.group/t/problem-with-xf-operator/6452/4 "2023-04-13T17:21:01Z")

</div>

Your argument makes sense but it does require a lookahead of two tokens in the parser which may not be commonly implemented in Prolog parsers. I guess SWIP is one of those that doesn’t:

> [@Parsing text using a formal grammar: SWIPL Example](https://swi-prolog.discourse.group/t/parsing-text-using-a-formal-grammar-swipl-example/5088/58):
>
> The code handling operators is a bit of a mess ☹ That is typically what happens if you write such a beast without a standard around and a variety of implementations. As just implementing the standard and nothing more will break a lot of existing code this is not really an option either.

And I might be wrong but I think the ISO standard states that Prolog syntax be parseable with an LL1 parser.

Another data point from Eclipse documentation:

> A.3.3 Operator Ambiguities  
> Unlike the canonical syntax, operator syntax can lead to ambiguities.
> 
> For instance, when a prefix operator is followed by an infix or postfix operator, the prefix is often not meant to be a prefix operator, but simply the left hand side argument of the following infix or postfix. In order to decide whether that is the case, ECLiPSe uses the operator’s relative precedences and their associativities, and, if necessary, a two-token lookahead. If this rules out the prefix-interpretation, then the prefix is treated as a simple atom. In the rare case where this limited lookahead is not enough to disambigute, the prefix must be explicitly enclosed in parentheses.
> 
> Another source of ambiguity are operators which have been declared both infix and postfix. In this case, ECLiPSe uses a one-token lookahead to check whether the infix-interpretation can be ruled out. If yes, the operator is interpreted as postfix, otherwise as infix. Again, in rare cases parentheses may be necessary to enforce the interpretation as postfix.
> 
> When a binary prefix operator is followed by an infix operator, then either of them could be the main functor. Faced with the ambiguity, the system will prefer the infix interpretation. To force the binary prefix to be recognised, the infix must be enclosed in parentheses.

Just a few indications of the state of parsing user defined operators in Prolog. So you shouldn’t be surprised by a few anomalies, particularly in the area of postfix operators which don’t seem to be used a lot.

If you’d like to help sort it out, SWIP is an open-source community 🙂 .

---

_[View the full topic](https://swi-prolog.discourse.group/t/problem-with-xf-operator/6452)._