#41 Unsafe rule support does not use ground terms from query.

[Thomas Triplet]

Hello

I just found a weird bug using the online demo:

if I run

country('nowhere', 6).
country('usa', ?x) :- ?x > 4.
country('europe', ?x) :- ?x = 4.
country('japan', ?x) :- ?x < 4.
?-country(?origin, 6).

I get

Init time: 33ms
----------------------------------
Query: ?- country(?origin, 6). ==>> 2 rows in 0ms
Variables: ?origin
('nowhere')
('usa')

which is what one would expect. however, if I run (just removing the first line):

country('usa', ?x) :- ?x > 4.
country('europe', ?x) :- ?x = 4.
country('japan', ?x) :- ?x < 4.
?-country(?origin, 6).

I get:

Init time: 35ms
----------------------------------
Query: ?- country(?origin, 6). ==>> 0 rows in 0ms
Variables: ?origin

which is obviously not what we should get...

Do you know if this bug is specific to the online version or will I get the same error if I write my own program using the jar files? Maybe my syntax is not appropriate too...
Thanks

[baz bishop]

This is a known 'feature' caused by the two stage initialisation of IRIS.
For simple cases (no program optimisations, such as magic sets) IRIS will initialise its knowledge base by materialising all possible true facts (bottom-up evaluation).
After this, a query is executed against this 'model'. This is fine for most situations and is actually preferred in many applications where a long initialisation is acceptable in order that subsequent query execution be fast.
However, your example program contains unsafe rules and the technique to handle such rules involves adding extra predicates to each rule for each unbound variable, e.g.
country('japan', ?x) :- ?x < 4.
=>
country('japan', ?x) :- UNIVERSE(?x), ?x < 4.

This special (herbrand) universe predicate is populated with every ground term value found in the program before the bottom-up model is computed.
This means (unfortunately) that ground terms from the query are not included, since the query is evaluated afterwards.

By removing country('nowhere', 6) from the program, you effectively remove '6' from the universe of term values when the model is computed and it is not added back in when the query is evaluated (because then we would get the strange situation where query evaluation is affected by previous queries).

So yes, the behaviour you see is strange and not intuitive. It exists because of some requirements of other software that we integrate the reasoner with.

The only solution is to force the model to be recomputed with every query evaluation and this may be something we have to do in the future.
However, we are also working on several resolution-based evaluation strategies (top-down) where this problem won't occur by definition.

I hope this helps. I will leave this bug report open so that we don't forget to address this issue. Many thanks for reporting it!