On the benchmarks, this change leads only to a difference of the translator
output on a few trucks-strips instances, but these are only re-orderings. -> Merged.

No, I don't think we need to change lab for this.

The general validity test does not need a new issue because it is already
covered by issue215.

Malte, I will add the fix of the rest to my repository as soon as I have a
proper internet connection, you can get it from there for reviewing. I will also
upload a few test cases here.

Jendrik, I added you to the nosy list, because my fix changes the timing output
for "Parsing" to a block output (using block=True in timing in file
src/translate/timers.py)
Does this require a change in lab?

No objections to splitting to a separate issue, though we might as well choose a
new title for this one.

> So what do you mean with assignments in the first case?

Looks like an editing mistake. Replace

- duplicate literals or assignments should flag a warning or error; if we go for
a warning, then we should also make sure they are handled correctly

with

- duplicate literals should flag a warning or error; if we go for
a warning, then we should also make sure they are handled correctly

IIRC, there are actually IPC domains with duplicate atoms in the initial state
and we currently handle them correctly. But I'm not sure.

Malte,

regarding your first two points:

- literals referring incorrect atoms (undeclared predicate, wrong arity, unknown
object) should all be flagged with a useful error message
- similarly for "=" assignments referring to undeclared functions, having wrong
arity, referring to unknown objects, or unsupported value (not a non-negative
integer)

I think this should not only be done in the initial state specification but
everywhere, so I would prefer to split this off to a separate issue. What do you
think?

Regarding two other points:

- duplicate literals or assignments should flag a warning or error; if we go for
a warning, then we should also make sure they are handled correctly
- similarly, duplicate assignments to a fluent should flag an error if
contradictory and a warning or error if assigning the same value twice

You seem to distinguish assignments to fluents and other assignments because "a
warning or error if assigning the same value twice" is already be covered by the
other point. So what do you mean with assignments in the first case?

Ah, I see. Still, I do not see how fixing this issue would help there because
not mentioning an atom has a different semantics (false in PDDL, unspecified in
conformant planning).

Aye, for specifying uncertainty in the initial state. I've attached a conformant 
planning problem from the ring domain that uses a oneof clause (although no negated 
literals in this instance).

Sorry, I do not understand what you mean with "oneof clauses". Mutex groups?

It's the oneof clauses that I was considering. Negative literals can appear in 
them, no?

Christian, I don't think that allowing negative literals in :init would help for
domains with uncertainty. It would only add some sanity checks but atoms not
occurring in the :init section would still be false by default.

It would also remove one extra thing to modify for those who want to use the 
translator for domains with uncertainty in the initial state. I know I've used 
the translator code simply for parsing and the data structures it provides. I've 
subsequently had to add the support for negative initial literals (among other 
things) in doing so.

Forked off from issue292. See msg1879 for context.

Copying some text from there:
=============================================================================
Interesting, I never knew that negative literals in ":init" are allowed. But
they certainly are according to the PDDL 3.0 BNF.

They are, as Erez says, redundant, unless they clash with another positive
literal in the initial state, in which case I guess an error in the input should
be flagged. So they don't seem to serve a practical purpose. Nevertheless, we
should of course support them properly. While we're at it, we should make sure
that the following things in :init all work properly:

- literals referring incorrect atoms (undeclared predicate, wrong arity, unknown
object) should all be flagged with a useful error message
- similarly for "=" assignments referring to undeclared functions, having wrong
arity, referring to unknown objects, or unsupported value (not a non-negative
integer)
- duplicate literals or assignments should flag a warning or error; if we go for
a warning, then we should also make sure they are handled correctly
- negative literals should be allowed; if they clash with a positive literal, we
should report an error; otherwise, they can be ignored
- similarly, duplicate assignments to a fluent should flag an error if
contradictory and a warning or error if assigning the same value twice

Hope I didn't forget anything.