miquelramirez
commented
7 years ago Let me go over each of the points above:
-
CLINGO & GRINGO - Certainly, the flag name needs to change... that was the first name it occurred to me, which I admit isn't the best. Regarding installation, I'd suggest to use an environment variable to specify the basepath of the
gringoexecutable. It is agnostic w.r.t. to whether people are using package, build from sources or even platform. -
Generalising the grounding to FSTRIPS sounds to me as a worthy thing to do... Nevertheless, determining reachability of an atomic formula like
x(o) > lb() \& x(o) < ubis something that I think the ASP guys haven't really looked into yet, and kind of falls outside of what ASP can realistically do. Maybe we can do some sort of static analysis, limited over the numeric/functional effects so we can have atoms likereachable( x(o) > lb() \& x(o) < ub )to denote that the atomic formula is potentially achievable froms0. But that is going to be very weak, very often, unless there is an interesting interplay between numeric action effects and logical preconditions (e.g. a non trivial atomic formula over a predicative state variable appears in the precondition of an action that decreases the value ofx(o), allowing to bring its value within the bounds). -
Getting rid of FD would be a very good thing, we don't really need it anymore... besides the data structures that we use of the "AST". Note as well that there's a third parser, my extensions to numerics and hybrid domains based on
ANTLR. Maybe the best solution to have the parsers as modules of the front end. I know Anders' parser... and well, I think it is a mistake to do the parsing in C++, type safety gets in the way of processing the syntax tree... Python, C# etc. all have native implementations of libraries that allow for fast lexical and structural analysis anyways.
gfrances
The (as of now, optional) use of the ASP-based parser by the frontend should be slightly refactored so that:
A system-wide clingo instalation is used, instead of looking for a binary in a subpath of the FS directory. If a system-wide version or, if necessary, some version of Clingo pointed out to by, say, a certain environment variable, is found, then the option to ground the problem with Clingo is made available. Otherwise, it is not, and an exception is thrown if the user specifies the
--gringoflag, etc. (perhaps the flag name should be changed to hide the internals of what we use to solve the LP?)A bit more thought should be given to what we want to do when the problem is a FSTRIPS problem. FSTRIPS models usually suffer less with grounding, as actions are much more compact, but still we may benefit of the reachability analysis now performed with LP?
Ultimately, it doesn't make much sense to keep two different PDDL parsers. The goal here would be perhaps to get rid of one of the two... ideally the FD parser, since that would mean one less dependence. (Note: @miquelramirez 's "smart" parser also introduces a dependence to pyparsing, but of course that's a much cleaner dependence than a dependence to a patched, old, and no longer maintained version of FD codebase). Of relevance here also: Anders has a C++ PDDL parser which he is actively maintaining and pushing forward. As of now, though, I wouldn't even suggest to try to port all the work of generating the LP to a different programming language, much less to C++ :-)