FSTRIPS Language: Change Syntax for External Procedures

[gfrances]

I'd like to change the syntax we use to declare external procedures in PDDL files to something simpler, inspired by the way GPT handles this. Specifically, I would get rid of the need to prefix external symbols with an @, and simply have an extra top-level block in the PDDL declaring which symbols (usually functions or predicates) are external, e.g:

(:predicates (valid ?p - position))
(:external valid)

[gfrances]

That change would simplify the grammar, but we should either wait until integration of Tarski with the FS planner (preferrable), or else do the change in both places at the same time (likely too much unnecessary work)

[gfrances]

@miquelramirez , the support for external symbols is not working, and I'm fixing it now, but I see that you might be using it in two places: in action names (rule "actionName" in the grammar) and in event names (rule "eventSymbol"). Are you? Is it working for you? What do you think of the suggestion above?

[gfrances]

Ok, actually the issue is more interesting than i thought. A few thoughts:

There are actually a few distinct dimensions along which we can qualify predicate and function symbols:

• Whether the symbol is externally denoted (so far signaled by a @ heading the symbol name). This is a semantic, not syntactic, distinction.
• Whether the symbol is variadic (aka multigrade). Which we can see as shorthand for a (countable) family of predicates with same name and arbitrary arity, for one of its parameters type. An example again is an alldiff predicate, which we always assume to be defined over integer variables (or subtypes thereof), but we don't care about its arity.
• Related to the previous point, and only for external symbols: whether the truth value of the symbol can be computed only when the full state is available. I think we were distinguishing these rare cases with a double @@, which I don't like too much either, but perhaps I would leave this as it is at the moment, and tacke these cases later on.
• Whether the symbol is "built-in". This is a less crisp distinction, but so far we assume that certain symbols (e.g. alldiff again) are built-in, meaning that they don't need to be declared in the :predicates list. I don't like this too much, and it could perhaps be a good moment to fix it.

The problem with "fixing" this last point arises when, as with alldiff, a predicate is builtin and variadic at the same time. If we wanted to force the modeler to declare it in the :predicates section, then what would that declaration look like? We cannot do it unless we change other things, as the predicate does not have a fixed arity.

A possible way out of this:

• We have an extra block (in the domain file): :variadic_predicates which lists the names of those predicates with variadic arity, the same way that we would list a normal unary predicate. So for instance in BW, I could use an alldiff by writing:

(:variadic-predicates (alldiff ?b - block))

Of course, same for :variadic_functions, but this time the type of the return value of the function can be different from the type of the inputs. In these cases, the check for well-formedness should not take into account the arities, only types. I hate the proliferation of block names (i.e. :variadic_predicates, :variadic_functions, etc.), but among all alternatives I have considered, this one is the one I like best at the moment.

• Additionally, we also have an extra block :external which lists only the names of those predicates / symbols with external denotation. This allows us to get rid of the "@" in the grammar and all related code hacks. We can at the moment list here predicates such as alldiff, understanding that their denotation is not Tarski's business, but is provided by some upper layer. The only thing we'd then need is to make sure that the FSTRIPS parser, upon encountering one of these few external symbols, knows that it is built-in. An alternative would be to have some extra requirement key :constraints, or perhaps an extra declaration block :builtins... perhaps this last one would be a good choice?

[miquelramirez]

Hello @gfrances,

I just processed this discussion, which is quite substantial.

I think that following Blai's lead and coming up with specific sections for these kind of predicates and functions is the most sensible way to go. I think that having several :variadic and independent external sections is not a good idea.

I propose introduce an entirely new concept into PDDL-like languages for anything else than action schemata: nested declarations. For instance something like

(:predicates
    (foo ?t1 ?t2 - object)

    :external(
        (baz ?t1 ?t2 - object)
        (@baz2 ?t1 ?t2 -object))

    :variadic (
        (bar ?t1 ?t2 - object))
)

where rather than @@ we use just @ for externally defined symbols that require full access to states rather than just the denotation of any subterms.

This kind of follows with the design of the language for complex constructs - action schemata - and also mimicks the way we will have tarski programming interface to handle this (i.e. by adding "tags" to existing standard syntactic elements).

[gfrances]

Miquel! Sorry again for the delay. I like the idea of nesting stuff! There is one problem though: as with all these types of hierarchical taxonomies, they don't look that well when you want to associate multiple "tags" to the same syntactic element. For instance, if I want a predicate which is variadic and has external denotation... how should I handle that? Repeating its declaration looks like a really bad option. Let me suggest a slightly different approach:

(:predicates
    (foo ?t1 ?t2 - object)
    (baz ?t1 ?t2 - object) is external
    (bar ?t1 ?t2 -object)) is external and variadic
    (baz2 ?t1 ?t2 -object)) is absolute
)

Ok, perhaps "absolute" is not the best adjective, but we would just need some better name there to make explicit that the denotation of the symbol requires the full state. In other words, we move to a tag-based declaration. What do you think? Not sure if this syntactic style clashes a bit with idiomatic Lisp, mostly because I never developed a taste for Lispian aesthetics :-) If that is the case, we could use some syntactic variation of the same idea? I'll wait for your feedback before changing the implementation.

[gfrances]

BTW do you get notified if I don't write @miquelramirez ? :-)

[miquelramirez]

I get notified since I am "watching" the repo.

Regarding the nesting, I hadn't considered the case of being both external and variadic, but perhaps it could just look like:

(:variadic (:external ...))

Same dilemma as with C++ const and virtual. I will never truly understand why virtual goes behind the method name, like const does :-) But easier, since return types can't be const here :-)

I like how close is to natural language, I think you're complicating the parsing a bit... but perhaps not that much. What I don't like is how it clashes frontally with the Lispian style. It is very much like mixing 1970s brutalism with baroque... something that looks like to have escaped from an H. P. Lovecraft novel...

[gfrances]

I like your approach better - I told you I lack this Lispian taste! My option is clearly too neat for Lisp :-) Thanks!