Reimplemented explain feature

docs/source/blog/blog.rst

@@ -2,6 +2,7 @@
     :maxdepth: 1
 
     concepts
+    rules
     parsers
     persistence
 

docs/source/blog/parsers.rst

@@ -0,0 +1,8 @@
+Concepts
+========
+
+
+
+Basic definition
+****************
+To define a new concept

docs/source/blog/rules.rst

@@ -0,0 +1,100 @@
+Rules
+========
+
+
+
+Basic definition
+****************
+To define a new rule
+
+
+::
+
+    > when <predicate> then <action>
+
+Rules can have name, so you can also use the syntax
+
+::
+
+    > def rule <name> as when <predicate> then <action>
+
+
+Existing rule engines
+*********************
+
+I am not quite sure yet about the implementation. I have started to search on the net to see if 
+I can found some interesting implementation that I can use.
+
+I found:
+
+* Durable Rules Engine : https://github.com/jruizgit/rules
+
+    Python implementation, with the rule engine written in C (or C++) to be faster. A good candidate
+
+* PyKE : http://pyke.sourceforge.net/knowledge_bases/rule_bases.html
+
+    Another Python implementation of the rule engine
+
+* Business-rules : https://github.com/venmo/business-rules
+
+* Intellect : https://github.com/nemonik/Intellect
+
+* CLIPS : http://www.clipsrules.net/
+
+    A standard. Run on a separate server. I need to check how it can be embedded, or dockerized
+
+* And of course drools : https://www.drools.org/
+
+    Another standard
+
+I am not an expert in rule engine. So I guess that the best way to figure out what engine to use it to list what are the feature that I need.
+
+
+Use cases
+*********
+
+I see the rules engine like the caching service or the logging service. It can be used anywhere in the code.
+It's not just a global feature of Sheerka. It's another way of achieving common task.
+
+For example, in the print service, I want to print all the failed ``ReturnValueConcept`` in red.
+Doing it in an imperative way (ie coding this functionality) is
+
+1. Intrusive in the code. I need to understand what code and where to put it
+2. Not straightforward : if I want to that all successful ``ReturnValueConcept`` in green, chances are that I will have to rewrite some code
+
+So It has to be declarative. With an engine that takes these declarations and correctly paint the outputs.
+And a declarative system that accepts conditions is (I guess) a rule engine.
+
+So let's try something like:
+
+::
+
+    > when action==Print and obj==ReturnValueConcept and obj.status then print_the_status_in_red()
+
+We immediately see that the rule engine will have to be aware of the current system.
+So the chosen rule engine will have to manage state or facts. I haven't checked all the listed one, but I am quite sure that they all do,
+as it's the minimum requirement for a rule engine.
+
+I also need two types of rules.
+
+    * permanent rules
+        It will be triggered as long as the system allows it
+
+    * one use rule:
+        it will be triggered only once
+
+If I take my example to color the status of the ``ReturnValueConcept``, it may be a permanent rule,
+that will apply to any output, or it can be something that is specific to the current execution context.
+
+
+In the predicate part, I need to control how expression are evaluated.
+    For example in the expression ``action==Print``, Print can be a string ('Print'), a builtin concept (``BuiltinConcepts.PRINT``) or even another concept
+
+
+In the predicate part, as well as in the action part, I must be able to used other concepts
+
+::
+
+    > def concept status is not ok as <whatever suits>
+    > def concept paint in red as <whatever suits>
+    > when status is not ok then paint in red