Domain with nested conditional rejected with error "Problem in domain definition!"

[FlorianPommerening]

The following domain uses nested conditional effects to model a simple problem: there are two rooms and an agent in room1. If the light in room1 is switched off, the agent moves to room 2. The goal is to have the agent in room 2. VAL does not accept the plan consisting of just one action (switching off the light in room 1).

The error still occurs if the effect (not (light-on ?room)) is removed but the (and ...) remains as a trivial conjunction. The error disappears if the trivial conjunction is removed as well.

The error message is "Problem in domain definition!" but this looks like valid PDDL to me. Did I overlook something?

Domain

(define (domain lights)
    (:requirements :conditional-effects)
    (:predicates
        (light-on ?r)
        (in ?r)
        (CONNECTED ?r ?rn)
    )

    (:action toggle-light
        :parameters (?room ?rightroom)
        :precondition (and
            (CONNECTED ?room ?rightroom)
        )
        :effect
        (when (light-on ?room) (and
            (not (light-on ?room))
            (when (in ?room) (and
                (not (in ?room))
                (in ?rightroom)
            ))
        ))
    )
)

Problem

(define (problem p01)
(:domain lights)
(:objects
    room1
    room2
)
(:init
    (light-on room1)
    (in room1)
    (CONNECTED room1 room2)
)
(:goal (in room2))
)

Plan

(toggle-light room1 room2)

[guicho271828]

Nested cond-effect is not allowed in the BNF definition of PDDL 3.1.

Excerpt from the document by Daniel L. Kovacs (excluding numeric-fluents parts) below. when has cond-effect in its body, which should be a conjunction of p-effect, which does not allow further use of when.

<effect>       ::= (and <c-effect>*)                                              
<effect>       ::= <c-effect>                                                     
<c-effect>     ::=:conditional−effects (forall (<typed list (variable)>) <effect>)
<c-effect>     ::=:conditional−effects (when <GD> <cond-effect>)                 
<c-effect>     ::= <p-effect>                                                     
<p-effect>     ::= (not <atomic formula(term)>)                                   
<p-effect>     ::= <atomic formula(term)>                                         
<cond-effect>  ::= (and <p-effect>*)                                              
<cond-effect>  ::= <p-effect>                                                     

[maltehelmert]

PDDL used to allow arbitrary nesting of forall, when, etc. At one point someone (I don't remember who or when) decided to change this unilaterally, without seeking community approval. I would be careful about considering this modified behaviour the standard, even if it is described in the document by Daniel Kovacs. I don't think the document by Daniel Kovacs is more "official" than, say, Drew McDermott's original TR, which does allow arbitrary nesting of effects (Section 7, http://icaps-conference.org/ipc2008/deterministic/data/mcdermott-et-al-tr-1998.pdf).

[guicho271828]

It is an orthogonal problem. The point is not about which is better or worse, more or less official. It is just that PDDL3.1 unfortunately does not allow it, and thus as long as VAL is PDDL3.1 compliant (although this is not clear either), it is not a bug. The technical report is specifying a version that is different from PDDL3.1, and so far, the latest PDDL is version 3.1.

For arbitrarily nested conditional effects to be accepted, we need a newer standard. Also, it would be nice to have a flag similar to gcc std=c+11.

[maltehelmert]

No official definition of what PDDL3.1 is or isn't exists. There used to be a PDDL committee that could make such as call, but it is no longer in existence, and (as far as I know) the document by Daniel Kovacs has never been accepted or vetted by any side. I think that when he published it, there was some vocal opposition precisely because there was a concern that some people would mistakenly believe it to be a normative document. So the bone of contention here is whether any PDF can claim to define the PDDL3.1 syntax, let alone semantics. I can put a PDF on my home page claiming that it specifies PDDL4.0, but that doesn't make it official.

But I agree that the arbitrary nesting of effects is at the very least a disputed PDDL feature, so VAL not implementing it should not be considered a bug. I guess it's best to set aside this discussion until the community steps up to rigorously define PDDL semantics.

[guicho271828]

Fair point. The reply is a bit long below...

The reason I prefer his pdf is because it is has a clearly defined compact BNF, is latest, is complete as one document and, last but not least, it exists. As a user and an implementer I believe it is the best document at the moment as a PDDL syntax specification. Similar point ("complete as one document") was discussed in [1]. It is better than nonexistent.

Note that the standardization process is not about finding the best, correct, universal way of specifying things, like a mathematical theory, but rather a concession and engineering. It needs some base prototype which is allowed to be insufficient but is clear and concise enough to build the next version. His BNF (and other PDDL1.2/2.1 BNFs) meets this criteria. A standard is not a paper, but an agreement. If no PDF can claim to define the syntax, it means the standardization has failed and the agreement was not made, i.e. no progress.

The problem is, somehow even researchers fall in the waterfall mentality when you think about the standard while their daily research is usually an iterative process and they are supposed to be good at it. A standard is an agreement, but not in the sense of truth assignment but merely of a temporary decision, something that is meant to last for a few years before a new, improved version is proposed for the next IPC. Although some care for backward compatibility is necessary and no drastic change is expected, a standard is meant to change. So, the opposition (or fear for making mistakes / making a bad standard officieal) is unreasonable.

I believe it is why the committee has dissolved. If they tried to find the best specification, then the cost was too high. This is one reason I believe "first BNF takes all" mentality can be safely applied. Because no one made a decision in PDDL3.1 (specified the BNF).

By the way, if we fix the part about the conditional effects in PDDL3.1, then it is more appropriate to just bump the minor version, i.e. PDDL3.2. It should be fine to put a new pdf on your website as long as you change the minor version, since no one have done it before and there is no naming conflict. Its impact all depends on whether an implementer (incl. IPC organizers) uses it. And I believe many will use it, especially if it is done on the fast downward website. I am optimistic, we wouldn't have to worry until some crazy person start proposing a bunch of useless junk alternatives, i.e. we can trust the community.

[1] “Type Problem in Domain Description!” or, Outsiders’ Suggestions for PDDL Improvement Robert P. Goldman and Peter Keller

[DerekLong101]

There is no current plan to make VAL handle nested conditionals, whether or not it is part of any specific BNF. VAL does not even handle PDDL3.1 yet, so I will reserve judgement on what other BNF/language modifications we should or should not support. VAL is what it is - if a feature is requested, let's handle it as a feature request.