4 ms·

I didn't find the time yet to check the details in the source code, so I can only speculate from experience with other VMs. As it seems from your description th

by Rochus 2y ago

I didn't find the time yet to check the details in the source code, so I can only speculate from experience with other VMs. As it seems from your description the constructs-to-c version removes the interactive part (REPL) which is apparently not needed in stand-alone applications. But that's unrelated to the question in which format the code/rule-base is kept and executed. The C files could embed both a text or a byte code version of the CLIPS code/rule-base, and the interpreter is implemented in C anyway. But I think I have to check in the (generated) source code (the architecture manual doesn't even mention the term "interpreter"). For some years I was thinking about using CLIPS for algorithmic music composition, but it might be too slow; seems to be not trivial to get reliable performance figures.

ryjo 2y ago
> For some years I was thinking about using CLIPS for algorithmic music composition 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.
- Rochus 2y ago
  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 https://ccrma.stanford.edu/software/snd/snd/s7.html) is also purely interpreted.
  - ryjo 2y ago
    > 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!

by Rochus 2y ago

ryjo 2y ago

> For some years I was thinking about using CLIPS for algorithmic music composition 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.

Rochus 2y ago
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 https://ccrma.stanford.edu/software/snd/snd/s7.html) is also purely interpreted.
- ryjo 2y ago
  > 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!