- Temporary states should not cause a permanent overhead (issue386)
  Solved by using temporary state registries.
- Think about making SearchNodes include a state rather than a State ID.
  We decided against doing this. Now that we unpack states, they are heavy
  weight objects again and should not be copied unnecessarily.
- States should be stored more compactly (issue214).
- Think about when to unpack states (issue348).
- Get rid of global state registry (issue416).
- Use task interface in search engines and state registries (issue509).
- Possibly move successor generation out of the class StateRegistry (if we find an efficient way to do so)
- Possibly make axiom evaluation optional (if we find an efficient way to do so)

- Separate the state-related code into a separate subdirectory and namespace
  with a clearly documented (and small) interface to the main code. This module
  should contain:
  - StateRegistry
  - IntPacker
  - PerStateInformation
  - StateId
  - GlobalState (maybe renamed to RegisteredState)
  - Try to avoid dependency on the semantic of operators.
  - Maybe even make this module completely independent of the task interface at
all. 
    (only assume that there are states that have a factored representation of
    multivalued variables with given domain sizes).

Issue348 is now done.

Issue416 and issue509 are done (I'm marking them in the summary). The main remaining work is to get rid of code duplication caused by having two state classes (State/GlobalState) and finding a better strategy when to unpack states. We are trying to do both in issue348.

Afterwards, we want to create a clean and small interface to the rest of the planner by separating the state-related code into a namespace/subdirectory as already described in the summary. We discussed two potential issues related to this separation:

(1) to move the successor computation out of the state registry. This is a bit tricky to do without losing performance.

(2) to make axiom evaluation optional, i.e., to store state data without evaluated axioms and have a function "evaluate_axioms" in the state class. Accessing derived values without evaluating axioms before would be an error. This would save memory on storing the states but potentially cost runtime for evaluating axioms on a state more than once.

There is a lot of work left to do that is more related to supporting the task
interface than to the state representation. I think this fits better into
issue509. We should finish supporting the task interface in the search code,
before we continue here.

Added a summary of the previous points and the results of our meeting today.

Hi Florian, sorry for the confusion, "meta" issues are the ones with priority
"meta" rather than the "meta" keyword. Keyword "meta" is old and unused; we used
it for non-code things (the website, mainly).

issue423 and issue424 are also follow up work on issue214. We might also want to
do them as part of step 3).

Some of the steps are done. Here is the updated version

1) [DONE] Temporary states should not cause a permanent overhead (issue386)
   Solved by using temporary state registries.
2) [DONE] Think about making SearchNodes include a state rather than a State ID.
   We decided against doing this. Now that we unpack states, they are heavy
weight objects again
   and should not be copied unnecessarily.
3) States should be stored more compactly
   The main work here is merged already (issue214).
   We are still working on follow-up work in issue348.
4) Get rid of global state registry (issue416)
5) Separate the state-related code into a separate subdirectory and namespace
with a clearly documented (and small) interface to the main code.

Is this master plan still up to date?

4) Separate the state-related code into a separate subdirectory and namespace
with a clearly documented (and small) interface to the main code.

This is a meta-issue where we want to collect more long-term ideas for the way
states are represented in the planner.

1) Temporary states should not cause a permanent overhead (issue386)
2) Think about making SearchNodes include a state rather than a State ID.
3) States should be stored more compactly (issue214)