Ok, then it's aparently the intermediate representation (what the parser feeds to the evaluator), which makes sense. The evaluator doesn't care, whether it comes from the parser or from constructs-to-c generated code.
Concerning the use case, an SBCL based solution would likely perform much better, though the Scheme VM of Common Music (https://ccrma.stanford.edu/software/snd/snd/s7.html) is also purely interpreted.
> Ok, then it's aparently the intermediate representation (what the parser feeds to the evaluator), which makes sense. The evaluator doesn't care, whether it comes from the parser or from constructs-to-c generated code.
Precisely!
This is a great use case! I'd be interested in seeing what you come up with.
> in which format the code/rule-base is kept
When you use constructs-to-c, the generated C files represent your rules engine constructs as pointers to pointers of CLIPSLexeme, CLIPSFloat, CLIPSInteger, and CLIPSBitMap structs. It does not store it as the raw clips code fed into the interpreter. You can later use functions like `save-facts` to generate the rules in CLIPS syntax based on these pointers to pointers of structs.