Changes

Jump to navigation Jump to search
1,284 bytes added ,  18:44, 10 September 2015
no edit summary
Line 4: Line 4:     
== Concept ==
 
== 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]]
 
[[Category: Plans]]

Navigation menu