A PDDL 3.1 parser implementation in Rust based on nom.
See src/briefcase_world.rs for an example.
Parser and domain/problem types can be used separately and will be completely decoupled through crate features in the future.
At this point the parser supports all domain and problem definition elements required to fully describe a PDDL 3.1 (and earlier) environment.
However, since types and enum variants are named closely to the underlying BNF descriptions (see below), they may be a bit unwieldy to use still.
Parsers were implemented based on the BNF elements listed in the paper:
"Complete BNF description of PDDL 3.1 (completely corrected)", Daniel L. Kovacs
Additional elements were added based on the individual specification papers.
-
<domain> -
<require-def> -
<require-key> -
<types-def> -
<constants-def> -
<predicates-def> -
<atomic formula skeleton> -
<predicate> -
<variable> -
<atomic function skeleton> -
<function-symbol> -
<functions-def> -
<function typed list (x)> -
<function type> -
<constraints> -
<structure-def> -
<typed list (x)> -
<primitive-type> -
<type> -
<emptyOr (x)> -
<action-def> -
<action-symbol> -
<action-def body> -
<pre-GD> -
<pref-GD> -
<pref-name> -
<GD> -
<f-comp> -
<literal(t)> -
<atomic formula(t)> -
<term> -
<function-term> -
<f-exp> -
<f-head> -
<binary-op> -
<multi-op> -
<binary-comp> -
<name> -
<letter> -
<any char> -
<number> -
<digit> -
<decimal> -
<effect> -
<c-effect> -
<p-effect> -
<cond-effect> -
<assign-op> -
<durative-action-def> -
<da-symbol> -
<da-def body> -
<da-GD> -
<pref-timed-GD> -
<timed-GD> -
<time-specifier> -
<interval> -
<duration-constraint> -
<simple-duration-constraint> -
<d-op> -
<d-value> -
<da-effect> -
<timed-effect> -
<f-assign-da> -
<f-exp-da> -
<assign-op-t> -
<f-exp-t> -
<derived-def>
Additional elements:
-
<extension-def> -
<domain-vars-def> -
<timeless-def>
-
<problem> -
<object declaration> -
<init> -
<init-el> -
<basic-function-term> -
<goal> -
<constraints> -
<pref-con-GD> -
<con-GD> -
<metric-spec> -
<optimization> -
<metric-f-exp> -
<length-spec>
Using embedded modal operators:
The following requirements can be parsed. Note that all requirement specific features are parsed unconditionally. A planner needs to ensure that it accepts or rejects a plan accordingly based on the stated domain requirements.
-
:strips -
:typing -
:negative-preconditions -
:disjunctive-preconditions -
:equality -
:existential-preconditions -
:universal-preconditions -
:quantified-preconditions -
:conditional-effects -
:fluents -
:numeric-fluents -
:adl -
:durative-actions -
:duration-inequalities -
:continuous-effects -
:derived-predicates -
:timed-initial-literals -
:preferences -
:constraints -
:action-costs