rules with equality in body (sometimes) not processed?

[alanruttenberg]

I'm trying to track down why I'm getting fewer facts with graal than with my previous solution. I think I've narrowed it down to rules like the below.

precedes(O1,O2) :- precedes(Sk2,Sk1),Sk1 = O2 ,temporallyProjectsOnto(O1,Sk2).

It's a stupid use of =. While a person wouldn't write these rules, the process that generates them is more stupid and currently does.

I could fix the rules by doing the = substitution as pre-process

precedes(O1,O2) :- precedes(Sk2,O2),temporallyProjectsOnto(O1,Sk2).

I may land up doing that to detect (effectively) duplicate rules. But still, it would be good to know if this is a known issue/expected behavior or bug.

Thanks

[sipi]

Hi Alan,
Although DLGP allows to express equality, we don't manage it in Graal, neither in the body nor in the head.
So, equality atoms are treated like others. They will be true iff there are in the store.

We will update the Graal documentation to be explicit with this behavior.

Thanks

[alanruttenberg]

Ok. You might consider throwing an unsupported feature exception in the parser if equality is used - it's an easy thing to miss, even if documented, and using = as a regular predicate isn't typical behavior.

Thanks!

[sipi]

We can't just throw an exception in the parser because we want to let users the possibility to handle them. However, I agree with you, it's an easy thing to miss even if documented.

I take note of your comment.