Wonderful! Merged and closed.

Ok, I changed this.

It looks like the new code allows having multiple :constants, :predicate etc.
entries, with the semantics that the last one overrides the previous ones,
except for :types, where they are combined? I think we should not allow
repetition of the same field.

The "no longer allowed" field also seems to contain a bit of duplication across
the cases since it's prefixes of the same list?

Here's one possible implementation strategy that could reduce the duplication:

- have a constant list "correct_order = [":requirements", ...]
- have a list "seen_fields = ..."
- first test each encountered field if it's in correct_order at all -- if not,
then we should break out of the loop (the same way we currently do)
- test each encountered field to seen_fields to see if it's a duplicate => error
- if seen_fields is not empty, test if correct_order.index(seen_fields[-1]) >
correct_order.index(current_field) => warning
- append current field to seen_fields

The nice thing about this is that the handling of the field order only has to be
done once, rather than once for each possible field.

I think we should close this issue at some point. The current state is the
following:

1. We allow requirements :existential-preconditions and :universal-preconditions
(implemented in branch issue163)

2. We allow an arbitrary order of the specification of certain components in the
PDDL domain specification (more precisely, the order of types, constants,
predicates, and functions). If the order is different from the one of the BNF
specification, we print a warning but continue (implemented in branch issue 163)

3. I opened a new issue for the "Negated axiom impossible" issue (issue280)

4. Daniel did not answer Silvia's email and we cannot reproduce the dictionary
key error, so I would suggest to close this issue part.

So I think we can close this issue as soon as the changes are integrated into
default.

> I agree that this should trigger the bug in the way I interpret the description.
> Silvia, can you ask the original bug reporter to clarify/give an example?

I've sent an email to Daniel.

> In my opinion, this behavior is in accordance with the PDDL specification (resp.
> with the prophecy) and it is easy to adapt a domain description accordingly.
> Should we nevertheless support an arbitrary order?

If the PDDL spec doesn't allow it, no, then I wouldn't change it. We might want
to improve the error message though; I would guess it is currently rather poor.

> I could not reproduce this but maybe I misinterpret the bug description. 
> I attach a task that in my understanding should trigger the dictionary key
> error. 

I agree that this should trigger the bug in the way I interpret the description.
Silvia, can you ask the original bug reporter to clarify/give an example?

> The task is also interesting because changing the goal description from
> (:goal (forall (?x) (and (not (pred ?x)) (ok ?x))))
> to
> (:goal (forall (?x) (and (pred ?x) (ok ?x))))
> throws an AssertionError ("Negated axiom impossible; cannot deal with that")
> which should easily be avoidable for constant predicates.

What is the point of that assertion anyway? What does it check, why is is
necessary? This looks like it should be fixed (maybe opening a separate issue
for that is best).

- Im Domain-file müssen für LAMA die Konstanten vor den Predikaten deklariert
  werden.
In my opinion, this behavior is in accordance with the PDDL specification (resp.
with the prophecy) and it is easy to adapt a domain description accordingly.
Should we nevertheless support an arbitrary order?

- Das PDDL requirement :universal-preconditions wird von LAMA nicht erkannt, 
  :quantified-preconditions (das ist ja eine Übermenge) jedoch schon.
I changed this.

- Jedes Prädikat dass im Ziel (vermutlich auch in preconditions) unter einem
  Allquantor vorkommt muss für LAMA entweder im Init state oder in einem
  Aktionseffekt in einem positiven Literal verwendet werden, ansonsten gibt es
  im translate Teil einen dictionary key error.   Praktisch tritt der Bug mit
  handgeschriebenen Problemen sogut wie nie auf,
  bei unseren automatisch generierten Problemen aber schon (allerdings negiert,
  sonst wären ja die betreffenden Literale trivial falsch).
  Hier mussten wir einigen Aufwand betreiben um unsere generierten Probleme
  anzupassen. Im Planer selbst ist des vermutlich relativ einfach den Bug
  zu beheben.
I could not reproduce this but maybe I misinterpret the bug description. 
I attach a task that in my understanding should trigger the dictionary key error. 

The task is also interesting because changing the goal description from 
(:goal (forall (?x) (and (not (pred ?x)) (ok ?x)))) 
to
(:goal (forall (?x) (and (pred ?x) (ok ?x)))) 
throws an AssertionError ("Negated axiom impossible; cannot deal with that")
which should easily be avoidable for constant predicates.

This is from an old bug report (March 2009) from Daniel Bauer to Silvia. I'll
leave this in German for convenience; we can translate it as necessary.

We should check which bugs are still current, and for the ones that are, either
fix them directly if they are small issues, or open separate issues if they look
like more work.

Once this is closed, we should get back to Daniel Bauer to notify him (see
Silvia's email from March 26, 2009).


Dabei sind uns ein paar kleine "Bugs" aufgefallen (in dem Sinn, dass unsere PDDL
Probleme zunächst von LAMA nicht akzeptiert wurden obwohl sie zur PDDL
Spezifikation konform sind). Du weist natürlich in der Readme auf solche Fehler
hin, aber ich dachte du bist vielleicht trotzdem an unseren Erfahrungen
interessiert :-)

- Im Domain-file müssen für LAMA die Konstanten vor den Predikaten deklariert
  werden.
- Das PDDL requirement :universal-preconditions wird von LAMA nicht erkannt,  
:quantified-preconditions (das ist ja eine Übermenge) jedoch schon.

- Jedes Prädikat dass im Ziel (vermutlich auch in preconditions) unter einem
  Allquantor vorkommt muss für LAMA entweder im Init state oder in einem
  Aktionseffekt in einem positiven Literal verwendet werden, ansonsten gibt es
  im translate Teil einen dictionary key error.   Praktisch tritt der Bug mit
handgeschriebenen Problemen sogut wie nie auf,
  bei unseren automatisch generierten Problemen aber schon (allerdings negiert,
  sonst wären ja die betreffenden Literale trivial falsch).
  Hier mussten wir einigen Aufwand betreiben um unsere generierten Probleme
  anzupassen. Im Planer selbst ist des vermutlich relativ einfach den Bug
  zu beheben.