1. Range-based for loops for collections (issue510)
2. Add task transformation that ignores costs (issue511).
3. Add TaskTransformation class (issue512).
4. Add more (helper) functions (issue515).
5. Use task interface in existing heuristics
   - LM-cut (issue528)
   - PDB heuristics (issue529)
   - Merge and shrink (issue548)
   - landmark heuristics (issue551)
   - cea (issue552)
   - cg (issue553)
   - goal count, ipc max, h^max (issue554)
   - h^m (issue555)
6. Support access to axiom layers and axiom default values through task
   interface (issue660).
7. Use task interface for AxiomEvaluator (issue660).
8. Make GlobalState independent from globals (in particular g_root_task):
   remove GlobalState::dump* (can be replaced with State::dump*);
   store state size in GlobalState and StateRegistry (issue665).
9. Get rid of GlobalOperator::marked (issue535).
10. Use task interface in pruning methods (issue629).
11. Think about the way initial state data is handled.
12. Remove cost_type from Heuristic (issue684).
13. Replace stored GlobalOperator* by operator ids for preferred operators,
    applicable operators in successor generator, notify_state_transition,
    pruning, etc. (issue629, issue688, issue696, issue725, issue726, issue748)
14. Store global task data in RootTask and remove global variables that
    currently store the task (issue700).
15. Use task interface for StateRegistry (issue791)
16. Duplicate EvaluationContext/EvaluationResult/HeuristicCache for State
    (instead of GlobalState)
17. Use task interface in search engines.
    As a first step we want to hard code the task used by the searches to
    g_root_task. Searches should keep the cost_type parameter and pass it
    to get_adjusted_cost.
18. Get rid of GlobalOperator.
19. Handle task transformations in path-dependent heuristics (issue686)
20. Use task interface for IntPacker (issue699)
21. Get rid of g_axiom_evaluator (issue774, issue794)
22. Get rid of g_state_packer (issue774)
23. Get rid of g_successor_generator (issue792)
24. Get rid of g_initial_state_data (issue774)
25. Get rid of g_use_metric
26. Get rid of g_root_task (issue833)
27. Clean up globals.cc (issue793)
28. Add TaskProxy::get_id() (issue824)

issue686 is now its own meta issue for handling transformations in
path-dependent heuristics. Since this issue is about using the task interface
and this now done everywhere, its main task is done and we can close it.

I removed issue833 from the list since it is now its own meta issue. The
difference between this issue and issue833 is that this one is about using the
task interface and issue833 is about how to pass around the root task and its
transformations.

Item 16 was only on the list because we planned to get rid of GlobalState. This
is no longer our plan. GlobalStates are no longer states from the global task
but states that come from any state registry. We will also need the class in the
future but should probably rename it.

Item 17 is done (there is no way to access the global task without the task
interface any more).

Issue833 will handle item 26; items 15 and 27 are done with issue791 and issue793

Issue792 is now done as well, resolving item 23.

Issue824 and issue794 are now done.

Add task #28 to summary.

Items 20, 22 and 24 are resolved by issue774.

Added references to issue792, issue793, and issue794.

add reference to issue791

reference to issue774

I added a note to remove the metric section from the output to issue371 and
removed g_use_metric in the default branch.

It should not be part of the task interface.

I think it would make sense to remove it from the input altogether; setting all
action costs to 1 if the :action-costs feature is not used would more naturally
be a responsibility of the translator. But given the finite amount of time we
have, we can of course leave things as is in the translator and only remove
g_use_metric from the search component.

To be clear, use_metric is used while parsing the task. If use_metric is false,
all operator costs are set to 1. But this is compiled into the task and handled
by a local variable. Since the task interface does not support use_metric, we
currently write it to a global variable to print it later. What I'm suggesting
would just remove the output and the global variable. An alternative would be to
support it through the task interface.

I would leave dump_everything in, but remove g_use_metric. It may make sense to
remove it from the SAS file format as well, or at least document clearly that it
does nothing.

g_use_metric (item 25 in the summary) is currently only used in the method
dump_everything which in turn is unused. The only reason it is stored globally
is to potentially print whether a metric was used while parsing. Is this
necessary, or can we remove it? What about the dump_everything method?

updated summary after issue700 was closed.

Updated summary with global variables that should disappear in the task
interface eventually.

cross reference to issue 748.

cross reference to issue726

Reference issue725

We discussed a solution for the initial state: the root task will own an axiom
evaluator (and a successor generator) and generate them in its constructor.
We'll add methods to the axiom evaluator that work on unpacked state data
(vector<int>). This will lead to some code duplication, which we might be able
to avoid with templates. Depending on how we want to handle unpacking states
(see issue348), we could eventually get rid off the method evaluates axioms on
packed states. 

In the long run, every task could own an axiom evaluator (and successor
generator) or re-use the one from its parent.

We also talked about a good place to start introducing the task interface into
the search algorithms and decided it would be easier, if we first duplicated
EvaluationContext/EvaluationResult/HeristicCache so they can be used with States
(not just GlobalStates). Once this is done, we can concentrate on one search
algorithm at a time.

I updated the plan in the summary re-ordering items a bit.

updated references to issue629, issue688, issue696, and issue700.

Add item 20 and tick off item 18.

Add issue686.

Update summary

Tick off number 8.

Please take into account that axioms also count as operators, which is why
OperatorProxy stores more than just an index.

Add reference to issue665.

Updated summary after some offline discussion. Jendrik and I noticed that the code 
for different running issues made different assumptions about the data structures 
that will be used within searches after they are switched to the task interface.

We had a look at the code that currently uses GlobalOperator to see how they could be 
changed. One suggestion that would work as far as we can see, is to use operator 
indices (int) in most places that currently store GlobalOperator*. An alternative 
would be to store OperatorProxies but we previously said to avoid any proxies in 
containers or other long-term storage. Our plan is to try this in an issue branch to 
see if we get a performance hit from looking up the operator when we need it.

Remove obvious comment.

Update summary.

Using the task interface for axioms (points 8. and 9.) is issue660.

Using the task interface in pruning methods is issue629.

I added TODOs for supporting the task interface in the search engines (and
smaller steps on the way).

One thing, we should discuss is how to handle initial state data.
Currently, RootTask gets the initial state in four steps:
  1) RootTask accesses the global state registry.
  2) The registry reads values from g_initial_state_data, packs the data, and
evaluates axioms on the packed data.
  3) The registry returns a GlobalState that contains a pointer to the packed data.
  4) RootTask converts the GlobalState into a State (unpacks the data) and
returns it.

The problem with that is that we want to use the task interface in the registry,
i.e., the registry should get its initial state data from the task, not the
other way around. The question then is, who should be responsible for evaluating
axioms on the initial state data, who should store the data, etc.

I created issues for the remaining heuristics:
- landmark heuristics (issue551)
- cea (issue552)
- cg (issue553)
- goal count, ipc max, h^max (issue554)
- h^m (issue555)

Using the new task interface in merge-and-shrink is issue548.

5. Use task interface in existing heuristics
   - LM-cut (issue528)
   - PDB heuristics (issue529)
   - Merge and shrink
   - cg
   - ...

4. Add more (helper) functions (issue515).

3. Add TaskTransformation class (issue512).

2. Add task transformation that ignores costs (issue511).

Let's start collecting our ideas:

1. Range-based for loops for collections (issue510)

This meta issue groups all issues related to the task class. A preliminary 
version of the task class has been added in issue439. We'd like to collect and 
discuss all further enhancements in this meta issue.