Added first version of DebugManager. Implemented draft of the rule engine

This commit is contained in:
2020-11-20 13:41:45 +01:00
parent cd066881b4
commit 315f8ea09b
156 changed files with 8388 additions and 2852 deletions
+7
View File
@@ -0,0 +1,7 @@
The documentation is build using Sphinx
I prefer using VSCode for the documentation
install the following extensions:
* LiveServer (from Ritwick Dey)
* reStructuredText (from Lextudio Inc)
doc page for reStructuredText : https://docs.restructuredtext.net/
shortcuts : https://docs.restructuredtext.net/articles/shortcuts.html
+1 -1
View File
@@ -661,7 +661,7 @@ Some example :
and so on...
So when a concept is defined using its bnf definition, I use the **BnfParser** to create the grammar, and then
So when a concept is defined using its bnf definition, I use the **BnfDefinitionParser** to create the grammar, and then
I use the **BnfNodeParser** to recognize the concepts
The current implementation to recognize a concept is not very efficient. All the definitions are in a dictionary
+66
View File
@@ -0,0 +1,66 @@
Format Rules
============
Basic definition
****************
Format rules are rules that define how the result of the execution must be printed.
I guess that it will be ultimately be replaced / transformed into the program that can speak
::
> when <predicate> print <action>
where:
predicate is a valid sheerka syntax
action is a custom language defined below
Action
*******
::
ACTION := FUNCTION | VARIABLE | RAW
FUNCTION := IDENT \( PARAM* (, PARAM)* \)
PARAM :=
VARIABLE := \{PREFIX:IDENT \}
PREFIX :=
RAW :=
Some examples
::
blue(digest) : {command}\nlist(body)
Predicate
*********
The predicate indicates the conditions to trigger the print / formatting
You can use the whole Sheerka language (methods and Concepts)
In addition to the regular function, you have also access to local variables
+-----------------+-------------------------------------------------------------------------------------------------------------------------+
| Name | Definition |
+=================+=========================================================================================================================+
| __obj | The current object being processed |
+-----------------+-------------------------------------------------------------------------------------------------------------------------+
| __ret | current object if it is a ``ReturnValueConcept`` |
+-----------------+-------------------------------------------------------------------------------------------------------------------------+
| __ret_value | |
| | * current value's body if the current value is a ``ReturnValueConcept`` |
| | * current value's body's body if the current value is a ``ReturnValueConcept`` and the body is a container concept |
| | * current value otherwise |
+-----------------+-------------------------------------------------------------------------------------------------------------------------+
| __ret_container | When the current value is a ``ReturnValueConcept`` and its body is a container concept such as |
| | * ``ParserResultConcept`` |
| | * ``ErrorConcept`` |
| | * ``OnlySuccessfulConcept`` |
| | * ... |
+-----------------+-------------------------------------------------------------------------------------------------------------------------+
+1 -1
View File
@@ -652,7 +652,7 @@ Some example :
and so on...
So when a concept is defined using its bnf definition, I use the **BnfParser** to create the grammar, and then
So when a concept is defined using its bnf definition, I use the **BnfDefinitionParser** to create the grammar, and then
I use the **BnfNodeParser** to recognize the concepts
The current implementation to recognize a concept is not very efficient. All the definitions are in a dictionary