Issue215

Title translator should loudly complain about invalid PDDL
Priority wish Status chatting
Superseder Nosy List erez, gabi, haz, kcleung, malte
Assigned To malte Keywords translator
Optional summary

Created on 2011-01-25.16:28:22 by erez, last changed by malte.

Files
File name Uploaded Type Edit Remove
suitcase_domain.pddl erez, 2011-01-25.18:05:21 application/octet-stream
suitcase_problem_10.pddl erez, 2011-01-25.18:05:51 application/octet-stream
Messages
msg7475 (view) Author: malte Date: 2018-09-16.12:17:09
See also issue813.
msg5020 (view) Author: gabi Date: 2016-01-05.16:56:59
The translator also should generate an error if the PDDL file contains two
actions with the same name (example task in issue430).
msg4604 (view) Author: malte Date: 2015-09-17.18:17:25
Here is another example of an input file where we should improve our error message:

https://groups.google.com/forum/#!topic/fast-downward/1MjEsD7U1Gg
msg4603 (view) Author: malte Date: 2015-09-17.18:16:35
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!)
msg4106 (view) Author: kcleung Date: 2015-03-24.03:17:37
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!
msg3484 (view) Author: malte Date: 2014-09-20.23:08:36
See issue472 for the next refactoring step. (Nothing happened there yet.)
msg3298 (view) Author: malte Date: 2014-08-09.20:23:31
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.)
msg3257 (view) Author: malte Date: 2014-07-31.14:26:18
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.)
msg3251 (view) Author: gabi Date: 2014-07-30.10:35:13
Sounds good.
msg3250 (view) Author: malte Date: 2014-07-29.13:48:44
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.)
msg3249 (view) Author: gabi Date: 2014-07-29.11:24:02
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?
msg3248 (view) Author: malte Date: 2014-07-28.03:53:24
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?
msg2528 (view) Author: gabi Date: 2013-06-28.16:48:34
For other things that should be checked, see also first two points of msg1884 in
issue294.
msg1230 (view) Author: erez Date: 2011-01-25.18:06:05
I added files where this problem occurs
msg1228 (view) Author: erez Date: 2011-01-25.16:28:21
For example, when an undefined predicate is used as a precondition or effect.
History
Date User Action Args
2018-09-16 12:17:09maltesetmessages: + msg7475
2016-01-05 16:56:59gabisetmessages: + msg5020
2015-09-17 18:17:25maltesetmessages: + msg4604
2015-09-17 18:16:35maltesetmessages: + msg4603
2015-03-24 03:17:37kcleungsetnosy: + kcleung
messages: + msg4106
2014-10-04 19:49:57maltesetkeyword: + translator
title: Translator Should Loudly Complain About Invalid PDDL -> translator should loudly complain about invalid PDDL
2014-09-20 23:08:36maltesetmessages: + msg3484
2014-08-09 20:23:31maltesetassignedto: malte
messages: + msg3298
2014-08-02 16:12:56hazsetnosy: + haz
2014-07-31 14:26:18maltesetmessages: + msg3257
2014-07-30 10:35:13gabisetmessages: + msg3251
2014-07-29 13:48:44maltesetmessages: + msg3250
2014-07-29 11:24:02gabisetmessages: + msg3249
2014-07-28 03:53:24maltesetmessages: + msg3248
2013-06-28 16:48:34gabisetmessages: + msg2528
2011-01-25 18:06:05erezsetmessages: + msg1230
2011-01-25 18:05:51erezsetfiles: + suitcase_problem_10.pddl
2011-01-25 18:05:21erezsetfiles: + suitcase_domain.pddl
2011-01-25 16:28:22erezcreate