Jump to: navigation, search

Restorer v2

1,284 bytes added, 18:44, 10 September 2015
no edit summary
== Concept ==
The result that we want to achieve can be described as a graph of objects, each edge of it having a special "relationship" meaning. This graph should be generated using a set of pre-defined rules, e.g.
* fork() -- an object type "task" may create a copy of itself, each "linked" node of this graph get "linked" to the new object
* open() -- a new object type "file" appear in a graph "linked" to the "task" object doing open()
And so on.
Another way of describing the thing is -- a string of sequences like <pre>{o,t,[l]*}</pre> where <pre>o</pre> is an ID of an object, <pre>t</pre> is its type, <pre>[l]*</pre> is an array of links to another objects. The generation rules can look like
* fork() -- <pre>({(*),task,[(*)]}) -> \1,{$new,task,([parent=\2,\3])}</pre> which means that any task can create a copy of itself having it as parent (link) and the rest of objects shared
* open() -- <pre>{(*),task,(*)} -> {-1,task,[file=$new]},{$new,file,[]}<pre> which means that any task can create a new object of type file linked to it
The restoring process then is: given a final graph or string and the set of generating rules find out what sequence of the latter can produce the former.
This task (in its 2nd description) reminds the task of solving the context-sensitive grammar.
[[Category: Plans]]

Navigation menu