-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Not parsing the type hierarchy #70
Comments
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. |
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) |
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) |
Apparently, a type inherits only from a single type. But there may be many of such parent types. |
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
|
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.
|
Yep, I agree. It should also be easier to implement. |
According to the discussion in #70, only variables will have disjunctive type specifications. Constants have only one type. Moreover, types can only have one supertype, i.e. no multiple inheritance.
This commit fixes issue #76 and makes the parsing of typed lists of names separated from the typed lists of variables. Regarding the separation, since in the discussion in #70 and in a3af26d has been decided that "typed lists of names" should not have more than one parent (where 'parent' means a supertype for types, and a 'type' for constants), the parsing of typed list of names can be made separated from the parsing of other typed lists, e.g. the one of variables. This should simplify the code and make it more readable. Regarding issue #76, this commit adds two types of duplicates checks: 1) a check over simple typed lists, that simply checks whether there are two occurrences of the same item (which in PDDL terms means either duplicated types or duplicated constants); 2) a check over (complex) typed lists (i.e. with typed hierarchy), where we check whether multiple occurrences of names occurred (e.g. "constant_1 - type_1 constant_1 - type_2"). Tests for both checks have been added. Moreover, the 'storage' domain "IPC5 Domain: Storage Propositional" (path: tests/fixtures/pddl_files/storage/domain.pddl) had a duplication issue since the type of area was specified twice.
As discussed in #70, and in particular in comment #70 (comment) and #70 (comment), it has been decided to not allow multiple types excepts for action parameters and variables. This commit fixes the previous code regarding constants according to the above decision, namely, that constants should have at most one type specification. This change had some implication across the codebase. E.g.: - the initializer method of Constant should have a single optional type, rather than an optional collection of types - the utility function 'constants' is changed accordingly with the initializer - the problem parser is changed by making it to use DomainTransformer.typed_list_name, rather than DomainTransformer.typed_list_variables, to parse objects.
Closed by #73 |
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
Actual behaviour
The actual parsed types are:
(:types airplane airport city location package physobj place truck vehicle)
The text was updated successfully, but these errors were encountered: