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