Todo, when I find the time:

- Fix some broken tests.

- [DONE] See if composite deltas can be re-implemented with primitive deltas that depend on their contents
   Motivation:
    - No more need for a 'CompositeLevel' class that keeps track of which delta is contained by which composite.
    - Composites that contain a common delta could be made conflicting (this is consistent with our "rules": a conflict can only occur between deltas that have a common dependency)
   Difficulty:
    - Still want to show/hide deltas at certain level.

- Add Version.getGraphState()
   Motivation:
    - Often, we need the graph state (i.e. snapshot) associated with some version, e.g., to make an update to it (creating a new version).
    - Currently, we use all kinds of tricks (sometimes very slow replaying of all deltas since big-bang, sometimes the more efficient rollback/forward from our current graph-state) to get a certain graph state.
    - Code would be easier to read if we can just get the GraphState out of any Version.
   Difficulty:
    - Decide how often to store snapshot. Tradeoff between memory use and speed.
    - In a first (naive) implementation, could just keep all generated snapshots (in lazy manner) in memory, forever.

- Make Version.findPathTo(v:Version) more efficient (use breadth-first search)
   Motivation:
    - This function is used very often. It makes code easy to read.
    - Currently implemented using Depth First Search (with a little heuristic)


- Fix import/export (serialization) of versions.


- Think: should self-embedding really be used for 'tagging'?
   Pro: Self-embedding already exists implicitly, why not allow it explicitly as well?
   Con: Makes several parts (e.g., merging) of the codebase more complex (need explicit tests to prevent infinite recursion)
   Con: Do we even need tagging? A global operation like "give me all versions with tag X" will never scale as the number of versions goes up. Everything should be scoped. A tag should only have meaning within a well-defined scope.


- Think: Introduce read-dependencies
- A NodeDeletion also unsets all outgoing edges of a node. Incoming edges must be unset by EdgeUpdates, and the NodeDeletion must depend on these EdgeUpdates. Maybe it will make the implementation (of conflict checking) simpler if a NodeDeletion would *not* automatically unset outgoing edges, and instead also would have to depend on EdgeUpdates that un-set the nodes?
   Pro: Simpler conflict-checking code
   Pro: Related to the previous, will also make the addition of read-dependencies easier to implement.
   Pro: Easier to explain to people


- Add meta-models and conformance checking
- Add action language to FSA
- Add concrete syntax
- Add neutral action language for graph operations
   see ModelVerse specification.
  implement VF2, ... on top of this action language.
  -. Then bootstrap.
      => look at Scheme


Cip:
   - maybe when live modeling alone, don't need to know dependencies, conflicts, between deltas
   - maybe only need two kinds of dependencies: Reads and Writes.
   - consistency checking on append-only set:
         look into database theory, eventual consistency to enable concurrent read/write access


   - nicer visualization for graphs:
         render them as objects/tables (can be done with graphviz)
   - interaction nets:
       the optimal implementatoin of functional languages
       (nice rabbit hole)
       garbage collection for free
   - ian piumarta