Issues reported by others that fall under this:

issue1029
issue1030

At some point in the process of issue1030 I went through the issue tracker to find more issues related to the translator error reporting. We decided it makes sense to collect them all in one place and discussed that this might be a good place for that. By doing so, I'm also changing this issue to have priority meta, so this now serves to have an overview about all the related issues in one place from now on. So here's a summary of what I've found:

Issues that are already dealt with after merging issue1030:
- too many parentheses (issue215)
- use undefined predicate name (issue215)
- first token in domain is not "define" (issue1029)
- empty conditions (issue1030)
- undeclared predicates (issue215 and issue220)
- "either" disallowed (issue220 and issue297)
- predicates with wrong arity (issu294)

Next, here is a list of things mentioned in other issues that are not yet addressed:
- disallow predicates with the same name as object types (issue171 and issue293)
- disallow duplicate action names (issue215 and issue430)
- use of object name instead of variable (issue220)
- "numeric" should be a reserved term and in particular not allowed for object types (issue220)
- complain about undefined objects (issue813)
- complain about using variables undeclared in parameters (no issue)

There's also issue472 that is related to this one, but I think it is sufficiently independent to not be considered part of this meta issue.

When we merged issue1030, we left many open pull request comments on the table. It would be nice to address them eventually. See

    https://github.com/aibasel/downward/pull/155

for more details. Make sure to display the changes for the file where the diff is too large to be shown by default to see everything. The whole list includes comments by Victor, Salomé, Florian, Clemens and me (and possibly others).

Added reference to issue1029 to summary.

Error reporting should also mention more about the context in which the error
occurs, such as a line number and perhaps a few lines of context in the PDDL
file. See message by David Epstein on Fast Downward list 09.06.2019 10:08 (CEST).

I'm attaching another example where our error reporting should be improved:


...
Completing instantiation...
Traceback (most recent call last):
  File "./translate/translate.py", line 578, in <module>
    sas_task = pddl_to_sas(task)
  File "./translate/translate.py", line 441, in pddl_to_sas
    reachable_action_params) = instantiate.explore(task)
  File "/home/abdon/downward/src/translate/instantiate.py", line 77, in explore
    return instantiate(task, model)
  File "/home/abdon/downward/src/translate/instantiate.py", line 57, in instantiate
    fluent_facts, type_to_objects)
  File "/home/abdon/downward/src/translate/pddl/actions.py", line 137, in
instantiate
    objects_by_type, effects)
  File "/home/abdon/downward/src/translate/pddl/effects.py", line 129, in
instantiate
    self._instantiate(var_mapping, init_facts, fluent_facts, result)
  File "/home/abdon/downward/src/translate/pddl/effects.py", line 137, in
_instantiate
    self.literal.instantiate(var_mapping, init_facts, fluent_facts, effects)
  File "/home/abdon/downward/src/translate/pddl/conditions.py", line 300, in
instantiate
    raise Impossible()
pddl.conditions.Impossible


The cause of this is apparently that some condition is written as "(open ?door)"
instead of the correct "(open ?d)".

> As another example where better error reporting would be useful, see issue297. I
> think the underlying problem there is that the input uses the "either"
> construct, which we do not support.

Actually no, there is another problem. Still, we should complain about "either"
if we don't support it.

As another example where better error reporting would be useful, see issue297. I
think the underlying problem there is that the input uses the "either"
construct, which we do not support.

> Will open a separate issue for this.

issue293

> It also allows using types as predicates (which is correct according to the
> PDDL 1 specification), but does not check if this clashes with actual
> predicates, as is e.g. the case in the Schedule-ADL domain (not in our
> repository -- we renamed the type "temperature" to "temperature-type" to
> avoid the name clash). In case of such clashes, we typically get a very
> uninformative error message about a tuple index being out of range.

I just got another error report about this behaviour. Will open a separate issue
for this.

The translator accepts quite a few things that are invalid PDDL. Test cases
include the domains mentioned in issue218 before the issue was fixed.

In particular, the translator accepts:

 * predicates that are not declared
 * an object type named "number", which should be reserved for actual
   numeric quantities

It also allows using types as predicates (which is correct according to the PDDL
1 specification), but does not check if this clashes with actual predicates, as
is e.g. the case in the Schedule-ADL domain (not in our repository -- we renamed
the type "temperature" to "temperature-type" to avoid the name clash). In case
of such clashes, we typically get a very uninformative error message about a
tuple index being out of range.