That's because types within predicate definitions are ignored -- you can write
"(at ?x - (foo (((bar) baz bla))) ?y - (or (not (and ?x :action foo))))" and I
think the planner would accept it.

Unfortunately, there is no authoritative semantics for type annotations in the
:predicates block and no two people I've talked to have given the same opinion
on what the semantics should be...

We can tighten that, too, and only allow declared :types in the predicate type
definitions.

What's funny here is that sometimes EITHER is benign (e.g., if the EITHER is in a 
predicate type declaration), or at least fails quietly.

Hi Robert, "either" is generally not supported (see
http://www.fast-downward.org/PddlSupport#Limitations). The translator doesn't
even know that "either" is a keyword -- you would get the same error message if

(exists (?E - (either c_human c_exploit))
                    (controls_proc ?E ?P))

were replaced by

(exists (?E - (foobar c_human c_exploit))
                    (controls_proc ?E ?P))

The problem here (as in so many places) is lack of clear error reporting. The
parser expects that the thing after "?E - " -- in this case "(foobar c_human
c_exploit)" is an atomic name. Instead, it is a list. The translator doesn't
actually check that the thing it sees is an atomic name, but just happily
proceeds assuming that it is a valid typename. Later on, it tries to put this
typename into a dictionary, which it cannot, since lists (such as "(foobar
c_human c_explit)") are not hashable.

I'll look into improving the reporting here.

Related to 298.

Ah.  Got through that, and there's the same bug in an effects expression with a 
UNIVERSALLY quantified EFFECT that has an EITHER type.

Again, can be rewritten into a conjunction of simply-typed quantified effects.

The translator seems to fail on this precondition subexpression:
(exists (?E - (either c_human c_exploit))
                    (controls_proc ?E ?P))
The same either expression works elsewhere, but fails in pddl_types.py; can't 
compute a hash function for (either c_human c_exploit).

I will attach domain and problem file.

Note that it's not impossible to rewrite the either to two separate 
existentials, so a bug, but not critical.

Backtrace:
Traceback (most recent call last):
  File "/Users/rpg/src/fast-downward/src//translate/translate.py", line 570, in 
<module>
    task = pddl.open()
  File "/Users/rpg/src/fast-downward/src/translate/pddl/pddl_file.py", line 47, 
in open
    return tasks.Task.parse(domain_pddl, task_pddl)
  File "/Users/rpg/src/fast-downward/src/translate/pddl/tasks.py", line 40, in 
parse
    = parse_domain(domain_pddl)
  File "/Users/rpg/src/fast-downward/src/translate/pddl/tasks.py", line 160, in 
parse_domain
    action = actions.Action.parse(entry)
  File "/Users/rpg/src/fast-downward/src/translate/pddl/actions.py", line 38, in 
parse
    precondition = conditions.parse_condition(iterator.next())
  File "/Users/rpg/src/fast-downward/src/translate/pddl/conditions.py", line 5, 
in parse_condition
    condition = parse_condition_aux(alist, False)
  File "/Users/rpg/src/fast-downward/src/translate/pddl/conditions.py", line 37, 
in parse_condition_aux
    parts = [parse_condition_aux(part, negated) for part in args]
  File "/Users/rpg/src/fast-downward/src/translate/pddl/conditions.py", line 46, 
in parse_condition_aux
    return ExistentialCondition(parameters, parts)
  File "/Users/rpg/src/fast-downward/src/translate/pddl/conditions.py", line 
209, in __init__
    self.hash = hash((self.__class__, self.parameters, self.parts))
  File "/Users/rpg/src/fast-downward/src/translate/pddl/pddl_types.py", line 38, 
in __hash__
    hashval = hash((self.name, self.type))
TypeError: unhashable type: 'list'