Implemented a first and basic version of a Rete rule engine
This commit is contained in:
@@ -1093,3 +1093,37 @@ Blog
|
||||
""""""
|
||||
Hi, I have the feeling that I am almost there with the parsers part. I have
|
||||
|
||||
|
||||
|
||||
|
||||
2021-01-30
|
||||
**********
|
||||
|
||||
Blog
|
||||
""""""
|
||||
|
||||
It's been a very long time since I wrote in the blog. I guess I was too busy to spend some time on it.
|
||||
2020 was the year of the COVID 19. I guess that being contained with my son and my wife gave me other priorities.
|
||||
|
||||
Nevertheless, I kept on working on Sheerka.
|
||||
|
||||
One major achivement that I made was a demonstration of Sheerka to other people. I happened in mid September.
|
||||
I demonstrated how to declare numbers using the ExactParser and the BnfNodeParser. Even thought I did not explicitly
|
||||
mentionned theses names, my demo was far to technique. The impression I gave was that Sheerka was too complicated (in
|
||||
the sens of too technical too use). Unfortunately, that was the case.
|
||||
|
||||
Did the demo come too soon ? I guess so, in a certain way, but It really helped me to have a first feedback, even if it did
|
||||
not reward the months of hard works.
|
||||
|
||||
Where am I today ? It's impressive the admit that since that demon (in September) I did not implemented any major capability.
|
||||
Sheerka does not know much bettet that at this time
|
||||
|
||||
I did though work on :
|
||||
|
||||
* performances
|
||||
* debugger
|
||||
* simple version of the rule engine (that goes with the debuggger)
|
||||
|
||||
Actually almost FOUR months of work for technical benefit. There were some parts of the code that were rewritten.
|
||||
|
||||
I am a little bit sad, time flies so fast.
|
||||
@@ -1,100 +0,0 @@
|
||||
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
|
||||
Reference in New Issue
Block a user