Scryer-prolog: Not really equal

[notoria]

The following happens:

?- E =.. [+, 1, 2], F = (+(1,2)), E = F.
   E = (+(1,2)), F = (1+2).
?- E =.. [+, 1, 2], F = (+(1,2)), E = F, write(E), nl, write(F), nl.
+(1,2)
1+2
   E = (+(1,2)), F = (1+2).
?- 

I assumed that when expression E is equal to expression F then print E and F is the same result.

Is this behavior expected?

[mthom]

It looks like operator data doesn't propagate down to the atom, sometimes. Can you offer any examples that don't involve (=..)/2?

[notoria]

I only know this way to do composition. I was using it more like this:

expr(E, [], E).
expr(E0, [M|Ms], E) :-
    member(O, [+, *]),
    E1 =.. [O, E0, M],
    expr(E1, Ms, E).

Without (=..)/2, I will have to make the code _less general_, _less easy to maintain_ specially if I add/remove operators.

With expr(E0+M, Ms, E), the code works fine.

[notoria]

I found an example that doesn't use (=..)/2 directly:

?- functor(F, +, 2).
   F = (+(_A,_B)).
?- functor(F, *, 2).
   F = (_A*_B).
?- 

The issue seems to be in the way functor/3 work.

[triska]

Personally, I think if such an issue arises then this may indicate a conceptual flaw in the way atoms and operators are handled internally: The handling and detection of operators should not depend on what is "propagated" to atoms.

Instead, when terms are parsed or printed, the operator table should be consulted to see whether using operator notation is admissible. The reason is that an operator definition that was in place when a term is parsed may no longer be in place when a term is printed. So, having the information of what is an operator or not stored together with atoms seems not a correct way to handle this issue.

And indeed, the following also works (almost) as expected:

?- T = a+b, op(0, xfx, +).
   T = (+(a,b)).

Here, an operator that was present when the term was parsed is no longer an operator when the term is printed, and this is handled correctly, save for the superfluous round brackets (...).

[mthom]

The reason is that an operator definition that was in place when a term is parsed may no longer be in place when a term is printed. So, having the information of what is an operator or not stored together with atoms seems not a correct way to handle this issue.

Yes, that's what happens.

[notoria]

The issue has been solved but the following happens:

?- F = (/).
   F = / .
?- F = / .
caught: error(syntax_error(incomplete_reduction),read_term/3:1)
?- 

The parenthesis is required for some operators.

[notoria]

The issue has been solved, closing.