Maybe first and foremostly: Both (:)/2
and (>)/2
are already infix operators defined in the standard like so:
:- op(600, xfy, :). % ISO/IEC 13211-2 5.2.1, table 1
:- op(700, xfx, >). % ISO/IEC 13211-1 6.3.4.4, table 7
Changing their priority means that you change their common meaning. This is very often not a good idea. Think of it: It's like you would (be able to) change the priority of operators in Java, C#, C++, Perl or PHP. They all did not dare to change the priority they inherited from C.
But, strictly speaking, you are able to do this.
To minimize the detrimental effect of such a change, try to keep the declaration in a module of your own. And, in a system without module-local operators, make sure you will recover to the original declarations safely.
You wrote user:(>)
which affects the special user-module. Instead, write your own module.
... or maybe reconsider the operator to be changed.
Terms are read up to the next period in one fell swoop. So if you have a rule like you have shown, the operator declaration will become effective only when prepare
will be executed. Therefore, it has no effect on the argument of the goals display/1
. You probably had prepare
loaded, executed and ; and reloaded it.
To make an operator declaration effective, either execute it directly on the top level (that is a quick hack); or write it as a directive into a file or module.
Then the >
-like operator, I will use :>
it its place, needs to be right-associative like the :
and a priority below :
. You declared xfx
which means no associativity.
?- op(500,xfy,:>).
true.
?- write_canonical(a:b:>c:>d).
:(a,:>(b,:>(c,d)))
true.