Issue164

Title :requirements declarations in problem files are not supported
Priority bug Status resolved
Superseder Nosy List malte, rpgoldman
Assigned To malte Keywords
Optional summary

Created on 2010-12-17.23:07:21 by malte, last changed by malte.

Messages
msg2085 (view) Author: rpgoldman Date: 2012-03-11.18:23:20
Thanks, Malte.  It's not hard for us to force our domains and problems into the 
right ordering, since they are programmatically generated, so in the interests of 
conformance, we will just do that.
msg2084 (view) Author: malte Date: 2012-03-11.18:13:13
> Drawing from Derek and Maria's PDDL 2.1 paper, it seems unambiguous that such 
> requirements are permitted:

Sorry, I made a bad typo. :-) Instead of
   >> :requirements in problem files are not allowed.
I meant to write
   :requirements in problem files are *now* allowed.

I changed and pushed the code to accept :requirements in problem files
yesterday, so it should work now. (Your example from issue318 still fails due to
the ordering of objects/init/goal, but if that is changed, it parses.)
msg2083 (view) Author: rpgoldman Date: 2012-03-11.18:10:34
Drawing from Derek and Maria's PDDL 2.1 paper, it seems unambiguous that such 
requirements are permitted:

<problem>
::= (define (problem <name>) (:domain <name>)
[<require-def>] [<object declaration> ] <init> <goal> [<metric-spec>] [<length-
spec> ])

WRT handling these as if Common Lisp keyword arguments, I don't know what to 
say.  BNF is simply a bad tool if you wish to capture a grammar in which there 
are named arguments or any other construct that permits partial order.  I don't 
have a good sense of where ordering is mandatory in PDDL, and where the 
appearance of mandatory ordering is simply an inadvertent consequence of the use 
of BNF.  I suppose I am just rehashing earlier correspondence.
msg2082 (view) Author: malte Date: 2012-03-11.00:55:04
:requirements in problem files are not allowed.

Regarding the more general issue, I wouldn't generally be averse to allowing
:keyword parameters to appear in any order everywhere (I think that's the usual
LISP semantics), but I wouldn't want to implement that without word from Derek
et al. that such a change would be appreciated. (Or put differently, it is
probably a bad idea to support this unilaterally.)
msg2081 (view) Author: malte Date: 2012-03-11.00:39:16
> See issue164 for another example of this, provided by Robert Goldman.

That should have been issue318.
msg2043 (view) Author: rpgoldman Date: 2012-02-06.21:13:48
The problem seems not to be simply the question of requirements.  I seem to also 
have trouble because I have been assuming that the contents of a PROBLEM 
definition need not be specifically ordered.

The documentation of PDDL seems ambiguous on this point.  McDermott's original 
Tech Report states clearly that DOMAIN definitions' components may appear in any 
order.  However, it is silent on the question of ordering of PROBLEM 
specifications.

The use of BNF for specifying the syntax does not help, since BNF does not have 
a "shuffle" operator to indicate clearly when it is intended that components can 
appear in any order.
msg2040 (view) Author: rpgoldman Date: 2012-02-03.23:21:44
I can verify that FF handles these forms.  To be more precise, it is possible that 
FF simply ignores them, but it does not cause it to fail in parsing.
msg2039 (view) Author: malte Date: 2012-02-03.22:50:22
See issue164 for another example of this, provided by Robert Goldman.
msg891 (view) Author: malte Date: 2010-12-17.23:07:21
The translator only accepts :requirements lines in domain files, but not in
problem files. According to the source I checked (theFox & Long 2003 JAIR paper
on PDDL 2.1), :requirements declarations should also be allowed in problem
files. Haven't checked what FF and VAL do here.

This bug was originally reported by Tomas de la Rosa.
History
Date User Action Args
2012-03-11 18:23:52maltesetstatus: chatting -> resolved
2012-03-11 18:23:20rpgoldmansetstatus: resolved -> chatting
messages: + msg2085
2012-03-11 18:13:13maltesetstatus: chatting -> resolved
messages: + msg2084
2012-03-11 18:10:41rpgoldmansetstatus: resolved -> chatting
messages: + msg2083
2012-03-11 00:55:05maltesetstatus: chatting -> resolved
assignedto: malte
messages: + msg2082
2012-03-11 00:39:17maltesetmessages: + msg2081
2012-02-06 21:13:49rpgoldmansetmessages: + msg2043
2012-02-03 23:21:44rpgoldmansetmessages: + msg2040
2012-02-03 22:50:22maltesetnosy: + rpgoldman
messages: + msg2039
2010-12-17 23:07:21maltecreate