Subtle bug in ASP Parser

[gfrances]

I've found quite a subtle bug in the ASP parser. It can be triggered e.g. with on the following instance, with the following configuration:

./run.py --debug  --asp --instance $DOWNWARD_BENCHMARKS/parcprinter-sat11-strips/p09.pddl    --driver sbfws --options="successor_generation=adaptive,evaluator_t=adaptive,bfws.rs=sim,sim.r_g_prime=true,width.simulation=2,sim.act_cutoff=40000"

(most of the command-line arguments are not essential to trigger the bug, only the --asp flag).
The problem is that some state variables are detected as "static" when they are not, i.e. when they are indeed state variables. An example are all variables location(sheetX, some_feeder_tray).

I have been able more or less to trace down the problem to a particular place. Namely, in the method asp.problem.detect_statics(). This method, which should detect which of the set of initial atoms are never changed, fails to detect that there are actions that remove the atoms location(sheetX, some_feeder_tray) (for instance, action fe1-Feed-Letter). The reason for this failure is subtle, again, and can be traced to this few lines of the code.
The predicate location has arity two; but because the second of the arguments is fixed to some constant (some_feeder_tray), i.e. is not an argument of the action schema, it is not considered as part of the grounding. Therefore, when the code attempts to remove e.g. the tuple (sheet1) from those points in the extension of predicate location that are considered static, it finds no such tuple. It should be attempting instead to remove the tuple (sheet1, some_feeder_tray). @miquelramirez, perhaps you could confirm that my reading of this is correct?

This bug likely affects all code since the introduction of the ASP parser, including the experiments in the IJCAI17 paper, although it is possible that no domain in those ones triggers this bug, can't tell for sure at the moment.

[miquelramirez]

Hello @gfrances ,

Yes, I can confirm the reading... we fixed many similar issues with quantified formulas, but we didn't think of constants, which are not very common in the IPC benchmarks due to very limited planner support.

[gfrances]

Ok, I will give this a try and ask for some feedback - don't want to break anything...

[gfrances]

Could you have a look at commit df4fc73 whenever you have time, @miquelramirez ?
Solving this ... allowed me to realize a different bug in the C++ component, in #114, that arises in the same conditions.

[miquelramirez]

Reviewed -- see inline comments on commit df4fc73

[gfrances]

Merged into v2 branch then.