Not parsing the type hierarchy

[Francesco Fuggitti]

Subject of the issue

The type hierarchy is not preserved when parsing a PDDL domain.

Steps to reproduce

To reproduce the error, just try to parse a domain with a defined type hierarchy, such as this domain.

Expected behaviour

The parsed domain types should be

(:types truck airplane - vehicle
        package vehicle - physobj
        airport location - place
        city place physobj - object)

Actual behaviour

The actual parsed types are:
(:types airplane airport city location package physobj place truck vehicle)

[Christian Muise]

Self-contained code to test:

from pddl.formatter import domain_to_string
from pddl.parser.domain import DomainParser

DOM = """
(define (domain logistics)
  (:requirements :strips :typing) 
  (:types truck
          airplane - vehicle
          package
          vehicle - physobj
          airport
          location - place
          city
          place 
          physobj - object)
  
  (:predicates 	(in-city ?loc - place ?city - city)
		(at ?obj - physobj ?loc - place)
		(in ?pkg - package ?veh - vehicle))
  
(:action LOAD-TRUCK
   :parameters    (?pkg - package ?truck - truck ?loc - place)
   :precondition  (and (at ?truck ?loc) (at ?pkg ?loc))
   :effect        (and (not (at ?pkg ?loc)) (in ?pkg ?truck)))

)
"""
domain = DomainParser()(DOM)

print(f"\n\tTypes ({type(domain.types)}):\n\t  {domain.types}\n")

print(domain_to_string(domain))

I think the types should ultimately be a dictionary mapping a type to its parent type. Then objects should have all the types they belong to be accessible.

[Francesco Fuggitti]

I also think that the mapping dictionary is the solution to go. However, I'm just wondering how we can cover the (afaik not so common) (either <primitive-type>+) case. I guess that covering this case would require a more structured approach, i.e., defining a Type class inheriting from a PrimitiveType base class. What do you think?

[Christian Muise]

What are the semantics again? A type inherits from two others? If that's the case, then we can just have the dict map a type to a list of types (most often just one)

[Francesco Fuggitti]

Apparently, a type inherits only from a single type. But there may be many of such parent types.

[Christian Muise]

Hrmz...this isn't in the type def, though, right? Just the parameters of an action or predicate (i.e., typing an object). Across all the classical domains in the API, only storage has it used:

(:predicates (clear ?s - storearea)
             (in ?x - (either storearea crate) ?p - place)
             (available ?h - hoist)
             (lifting ?h - hoist ?c - crate)
             (at ?h - hoist ?a - area)
             (on ?c - crate ?s - storearea)
             (connected ?a1 ?a2 - area)
             (compatible ?c1 ?c2 - crate))

[Francesco Fuggitti]

Although most of the examples are on predicates or actions, from the BNF grammar (here) it seems that it can be a type def as well. But you're right, it rarely (if not never) appears as type def.

<types-def>              ::= (:types <typed list (name)>)
[...]
<typed list (x)>         ::= x*
<typed list (x)>         ::= x+ - <type> <typed list(x)>
<primitive-type>         ::= <name>
<primitive-type>         ::= object
<type>                   ::= (either <primitive-type>+)
<type>                   ::= <primitive-type>

[Christian Muise]

My vote is to ignore the BNF (it was always unofficial (this repo is what makes things official!)) and just allow it for the parameter specs. An excerpt from "the book" on the matter...

[Francesco Fuggitti]

Yep, I agree. It should also be easier to implement.

[Marco Favorito]

Closed by #73