Comment by ryjo | Hacker News Reader

Comment by ryjo | Hacker News Reader

Parent Full thread

Good find in the apg! That thing is a wealth of info. It look like contructs-to-c wouldn't make things faster, but would instead reduce the compiled code size.

If I'm understanding your meaning, you mean "interpreted" in a sense that it translates to C code, and C code is interpreted and translated into machine code. Is that accurate?

It's possible that you and I are referring to different things when we use the word "interpreted." When I think "interpreted" in the context of computer programming, I'm thinking in terms of interpreted-at-runtime programming languages like Ruby, Python, and CLIPS before you use `constructs-to-c`. In my mind, using `constructs-to-c` changes this from an "interpreted" to a "compiled" language in that the expert system you write in CLIPS code is its own language with its own data structures, algorithms, and DSL. When you use `constructs-to-c`, you "compile" your application using the programming language of your expert system, thus it is no longer interpreted at run time.

> you mean "interpreted" in a sense that it translates to C code, and C code is interpreted and translated into machine code

No, I mean that the Lisp variant of CLIPS is a pure interpreter, (assumingly) not even threaded, and (certainly) no JIT. The "constructs-to-c" feature apparently doesn't change anything to that, i.e. even in the "translated to C" version of the CLIPS code it is still interpreted.

> I'm thinking in terms of interpreted-at-runtime programming languages like Ruby, Python

Me too.

> and CLIPS before you use `constructs-to-c` ... changes this from an "interpreted" to a "compiled" language

Didn't find evidence for this so far; as far as I understand it's still the same interpreter.

I'm sorry, but I still think I'm not sure what you mean by interpreter. I hope you don't mind if I press further, but I'm very much enjoying this deep dive into the CLIPS C API with you.

When you compile your code including the c files generated by the constructs-to-c command, you must update the main.c file as well as the makefile that ships with CLIPS. During that update, there are a few things you must do:

1. add the generated c files to the makefile 2. you remove the function calls in the main.c file that cause CLIPS to capture STDIN and STDOUT. That is: you remove one layer of abstraction that sits between your rules and i/o streams. 3. you remove the generic CreateEnvironment function call in main.c and replace it with InitCImage_1, a function that calls CreateRuntimeEnvironment.

CreateRuntimeEnvironment differs from CreateEnvironment because you are able to pass in pre-built:

1. symbolTable 2. floatTable 3. integerTable 4. bitmapTable

Which are your rules engine constructs represented in C.

In addition to these four things, CreateRuntimeEnvironment passes in functions the user may have defined as UserDefinedFunctions (UDFs) in C. This is a more direct path than having CLIPS first interpret CLIPS rules like `(defrule foo =>)` and then translate them into these C representations.

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.

> 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.

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!

Reply on news.ycombinator.com