See also issue813.

The translator also should generate an error if the PDDL file contains two
actions with the same name (example task in issue430).

Here is another example of an input file where we should improve our error message:

https://groups.google.com/forum/#!topic/fast-downward/1MjEsD7U1Gg

Dear kcleung, I see that there is no answer in the tracker to your last message.
Did we ever send you an answer? (Apologies if we didn't!)

I have implemented some extra syntax checkers that check against:
* cyclical relationships between types
* validity of objects
* type checking of predicates and their arguments in :init and :end
* Symbol checking of all predicates and arguments in :action

It is now sitting in my repository:

https://bitbucket.org/kcleung/hg.fast-downward.org/branch/translate-writeout-
pddl

Could you please have a look and give me some constructive feedback?

Thx!

See issue472 for the next refactoring step. (Nothing happened there yet.)

Assigning this to myself as I'm adding it to my "to do when I don't have to do
anything more urgent" list. :-)

(If I don't work on it and you'd prefer to take over the token, just ping me.)

I've opened issue447 for the pddl_parser package. (Better to do this in separate
steps, I think, otherwise I'll probably run out of steam in the middle.)

Sounds good.

The pddl_parser package would instantiate the classes from the pddl package; in
essence, it's a big factory. (That's what I meant when I wrote that the
pddl_parser package would depend on the pddl package, but not vice versa.)

My intention was to do keep doing small normalizations like NNF transformation
in the parser for now, but document more clearly which transformations of this
kind it performs. If someone sees doing this separately as advantageous, the NNF
transformation could be separated out, but I think that would be a separate change.

The main advantage of this would be to make the pddl package smaller and hence
easier to understand. It currently has 1617 LOC, of which more than one third is
parsing code (~600 lines). I think separating functionality into separate module
reduces the units of code you need to understand one time if they only have a
unidirectional dependency. The resulting PDDL package would be focused on only
the data structures and nothing else. (My initial motivation was that I wanted
to introduce some helper classes for the parsing code and felt that the pddl
package was acquiring too many modules in the end.)

How would this look like? We currently already do some simplifications during
parsing (like transforming conditions to NNF). Would this be done by the parser
module as well or only as a post-processing step of the rest of the planner?
Where are the data structures defined that the parser creates as its result?

I've started looking into improving the error reporting in the translator, but I
think if we just add this on to the current parsing code, things will end up
being too convoluted. The parsing code looks in need of refactoring. I think it
needs more helper classes, some kind of symbol table, and more generally a
better way of maintaining state than the way it is done currently.

I've started making some changes in this direction, moving all the
parsing-related code into one place. It might even end up being its own package
(pddl_parser), which would depend on pddl but not vice versa, to make the
separation of concerns clearer. Does this sound like something useful or rather
like a bad direction to move in?

For other things that should be checked, see also first two points of msg1884 in
issue294.

I added files where this problem occurs

For example, when an undefined predicate is used as a precondition or effect.