Rule executes twice

[tpluscode]

Hello. While working on rules for API testing, at some point I found that a single rule executes twice. I capture the current state in a gist: https://gist.github.com/tpluscode/69e3af86056188a2b18f6643c27d601c

I first noticed that files are written double. Then I added a e:trace statement in the tuner:response. See that it logs twice, even though there is only a single usage of that backwards chaining rule.

[josd]

Yes that is correct, forward rules can be executed many times, see https://eyereasoner.github.io/eye/#architecture-and-design
more specically step 5 can start again at step 1:

1. Select rule P => C
2. Prove P & ˜C (backward chaining) and if it fails backtrack to 1.
3. If P & ˜C assert C (forward chaining) and remove brake
4. If C = answer(A) and tactic limited-answer stop, else backtrack to 2.
5. If brake or tactic linear-select stop, else start again at 1.

[tpluscode]

Oh no, that is a bummer for what I want to do  Any way to prevent this behaviour? Like, "cache" the previous evaluation?  Sent from Nine

…

________________________________ From: Jos De Roo ***@***.***> Sent: Friday, 24 January 2025 22:36 To: eyereasoner/eye Cc: Tomasz Pluskiewicz; Author Subject: Re: [eyereasoner/eye] Rule executes twice (Discussion #125) Yes that is correct, forward rules can be executed many times, see https://eyereasoner.github.io/eye/#architecture-and-design more specically step 5 can start again at step 1: Select rule P => C Prove P & ˜C (backward chaining) and if it fails backtrack to 1. If P & ˜C assert C (forward chaining) and remove brake If C = answer(A) and tactic limited-answer stop, else backtrack to 2. If brake or tactic linear-select stop, else start again at 1. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[josd]

We do caching, that is the conclusion of a forward rule is not asserted when it was already asserted.
We also cache the result of log:semantics and we cache the result of log:uuid.
Do you see other things that should be cached?

[tpluscode]

I think it's up to me to prevent double requests when my backward rule executes twice, right? Not something that can be done by eye itself?  That said, I still don't understand why in this particular case it is happening...  Sent from Nine

…

________________________________ From: Jos De Roo ***@***.***> Sent: Friday, 24 January 2025 23:39 To: eyereasoner/eye Cc: Tomasz Pluskiewicz; Author Subject: Re: [eyereasoner/eye] Rule executes twice (Discussion #125) We do caching, that is the conclusion of a forward rule is not asserted when it was already asserted. We also cache the result of log:semantics and we cache the result of log:uuid. Do you see other things that should be cached? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[giacomociti]

I'm also curious about this behaviour, so my minimal repro is:

@prefix earl: <http://www.w3.org/ns/earl#> .
@prefix e: <http://eulersharp.sourceforge.net/2003/03swap/log-rules#> .
@prefix string: <http://www.w3.org/2000/10/swap/string#> .
@prefix tuner: <https://api-tuner.described.at/> .

{
  ?method tuner:response "an Example" .
} <= {
  () e:trace ?method .
  ?method string:length 3 .
} .

{
  "GET" tuner:response ?res .
  ?res string:contains "Example" .
} => {
  [] earl:passed true
} .

I understand that the forward rule is evaluated, triggering the backward rule and producing the earl:passed triple. Then it is re-evaluated, triggering the backward rule again, but this time no new triples are created so the evaluation process finally stops. So the question is how to prevent the backward rule to fire twice, since it has side-effects.

[josd]

The following should work fine:

@prefix earl: <http://www.w3.org/ns/earl#> .
@prefix log: <http://www.w3.org/2000/10/swap/log#> .
@prefix string: <http://www.w3.org/2000/10/swap/string#> .
@prefix tuner: <https://api-tuner.described.at/> .
@prefix : <urn:example:>.

{
    ?method tuner:response "an Example" .
} <= {
    ({ :test :is :ok } false true) log:ifThenElseIn ?SCOPE .
    1 log:trace ?method .
    ?method string:length 3 .
    true log:becomes { :test :is :ok } .
} .

{
    "GET" tuner:response ?res .
    ?res string:contains "Example" .
} => {
    [] earl:passed true
} .

and give

$ eye --quiet once.n3
1 TRACE "GET"

[tpluscode]

This will only work if there is a single usage of tuner:response?

[tpluscode]

If I understand correctly, it takes a unique statement to "become" true at the end of the rule?

Given my actual built-in used like ( ?method ?endpointUri ?header ?body ) tuner:response ?res . these seem to work:

{
 ( ?method ?endpointUri ?header ?body ) tuner:response ?res .
} <= {
  ({ ( ?method ?endpointUri ?header ?body ) tuner:done true } false true) log:ifThenElseIn ?SCOPE .

  # the rule body

  true log:becomes { ( ?method ?endpointUri ?header ?body ) tuner:done true } .
} .

This will still be a problem if two usages with exact parameters exist but could be rare...