Arbitrary read > process > write functionality

[haz]

Part of what excites me most about tarski is the promise of having an arbitrary PDDL-like tool suite at my finger-tips. If you take a look at what I did for epistemic planning, we have...

• Include operations to split up PDDL files
• Special syntax to flag fluent definitions
• Added fields for the action schema
• Custom syntax for the individual fluents (wherever they may appear)

Now, I spent quite a few hours putting in parser hacks to make that viable (and it's not pretty :P). My hope would be that things like this are an order of magnitude easier with something like tarski. I don't mean functionality supported out of the box, but rather the flexibility to add functionality at a whim.

How close are we to that dream?

[miquelramirez]

Hi Chris,

Something like that motivated the development of tarski. One of the tutorials covers the mother of all epistemic planning approaches.

Note that tarski is not meant to be just a "pddl tool", as pddl is just one way to specify succinctly and in a modular way planning instances. So for instance "splitting pddl files" is as hard or as easy as loading the original files, manipulate the AST as one wants and write back as many pddl specifications as you want or need.

Parsers in my experiences tend to be very hard to extend and that is because of how tightly coupled is the interpretation of the different produced grammar rules. I am thinking that perhaps moving on from antlr and adopt ply would be a sensible idea, that would make easier for peeps to embark onto language design (a sorely neglected research are in planning if you ask me).

I haven't followed up the links on your post yet, I presume that I will find examples of what you mean?

[haz]

Introduced functionality to cover/simplify this:

create a new .g4 grammar file, compile it, adapt the reader (perhaps by subclassing or extending the reader class, etc.).

...might just do the trick.

tarski.language.add_new_primitive(
  'oneof',
  requirement=':non-deterministic',
  valid_locations=[':effect'],
  min_args=2,
  max_args=None
)

tarski.parse_stuff(...)

You get the point. Essentially do all the funky antlr stuff behind the scenes, and expose functionality that covers 90% of the use-cases we have for augmenting a language.

[gfrances]

I see what you mean. This being Python, everything is very much possible, but one problem I see with this design is that it'd require the user to have the entire ANTLR installed on the system (ATM we only require the Pypi-installable antlr4-python3-runtime package). Of course that might be an acceptable price to pay, if you're willing to do this stuff, but might put off some of your users.

I can imagine though that if we go for something Python-native, like ply, as mentioned by Miquel, this might become much more feasible?

[haz]

Aha! Didn't realize that it ships with pre-compiled grammar defs. Absolutely makes sense, and this just means I'd vote 100x over for moving to ply for things like this. I'd prefer that route over having to require the full antlr system.

[JoanEspasa]

aye, ply should be the way to go.

[gfrances]

Actually, I'm seeing that Ply has been somewhat superseeded by Sly, but otherwise yes, I agree it'd be cool to give this a try. If anyone has a few spare cycles for this, I could definitely try to help on this.

[hectorpal]

Pick and mix translations

In a recent slack discussion, @haz said:

I'll likely put together & release a wrapper on top of tarski that lets you do common compilation things (ground with a single line, flatten to avoid objects/constants, clone original state fluents, etc).

It’d be nice to enable parametric literals for translations like K(lit, set_of_lit), and lifted versions of that.
This would enable “pick and mix” translations like:

• Lets put few softgoals, some conformant, some epistemic.
• Now let’s solve that classical problem.
• Better: solve a FOND problem.

@haz added:

• That gets at having custom PDDL syntax (like I did for epistemic planning).
• Requires some better parsing / BNF support, though...