Well, it's similar to all the approaches which use natural or fractal phenomena as input to generate music: it's essentially the output of a non-optimal random generator arbitrarily mapped to musical features. There are too many arbitrary human-made decicions between the input and the output to claim that it is "music of spheres" or "music of dna or proteins", i.e. the musical effect of any structures in the input data is rather arbitrary.
Your observation on non-optimal random generative mapping misses a crucial point, the key challenge lies in establishing a topological invariant mapping, which ensures that the intrinsic structures and properties of the input data are preserved in the output. This becomes even more complex when dealing with higher-order structures that span multiple modalities.
Yet the topologies of celestial bodies, or RNA or protein structures, nor the patterns generated by cellular automata or other popular sources have nothing to do with music. You could just as well interpret the patterns in a herd of cows or a flock of birds musically. What you ultimately hear as music is the arbitrary, man-made interpretation of a quasi-random set and its mapping onto music. Through this mapping and its active design by a person, it becomes virtually irrelevant which data was used as input. I have worked as a professional musician and producer and also have a PhD in molecular biology and biophysics and have been involved in algorithmically generated music for thirty years. You can take any random number generator and quantize it in a musically optimized way and get similar results. There is nothing characteristic that makes the experienced listener of such music think "oh, that's typical of protein music".
> downloading copyright works without having obtained a license
This is not illegal in all countries. If Nvidia did that e.g. in Switzerland, there would be no legal issue. Only making copies or publishing works without permission would be an issue. So why should those sites be shut down for the whole world, if there are many countries where it is legal to download books from them? Countries where such downloads are illegal could use different technical means instead to prevent their citizens from doing so, not affecting the rest of the world.
Working with Impromptu or Extempore looks similar. What is the advantage of CL supposed to be in this use case? Apparently it uses the Lisp version of Common Music, which switched to the Scheme S7 interpreter many years ago.
There is an objective benefit to using `constructs-to-c` and that is something you mention in your original comment: you generate a single binary file containing all of your business logic, thus avoiding running a "fully interpreted" app in production.
In order to determine if it gives a performance boost to your particular rules engine, you should test it out and benchmark it with something you'd consider a "real world" example.
> you should test it out and benchmark it with something you'd consider a "real world" example.
I thought that you might have specific experience with "real world" applications, thus my question.
The CLIPS "Advanced Programming Guide" states in secion 11.1, that "...compiles all of the constructs [..] into a single executable and reduces the size of the executable image. A run-time program will not run any faster than a program loaded using the load or bload commands"; so as far as I understand it, the code is still interpreted (i.e. not affected by the translation to C).
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:
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.
> 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.
> I thought that you might have specific experience with "real world" applications, thus my question.
As to this point: I don't at present have "real world" experience writing CLIPS. My experience thus far has been entirely research-driven based on observations I've made in "real world" scenarios.
If you want to read about some other people who have used CLIPS in real world scenarios, here's the most comprehensive HN thread to date so far on the subject:
Thanks. I was also in the discussion. When CLIPS is used as an expert system shell, then performance comparisons are pretty restricted. But since you have seemed to use it more for "indexing" and "caching", which is a domain shared by other interpreters used for the web, a performance comparison seems more feasible, especially if you already have implemented such features with other interpreters as well.
> you have seemed to use it more for "indexing" and "caching", which is a domain shared by other interpreters used for the web
That's the idea! I think CLIPS is a good framework for a generic run-loop (or `while` loop). If you can conceptualize your app as such, you can reap the benefits inherent in the rete algorithm within your application logic.
Does anyone have background information why this project is conducted and what the experiences are with V lang? They stated "Exploring V capabilities in bare metal programming and improving the compiler" in the readme; what are the experiences so far? Doesn't V have a GC? Is it used in the kernel?
Dylan (then known as Ralph) started with the acquisition of Coral Software, a year or two after the big language search. We started building the kernel in C++ then, and later the “Junior” project (i.e., the one that finally shipped) did the whole thing in C++ with NewtonScript on top.
There was also a brief period pre-Junior when I advocated using C++ with Smalltalk on top. Newton did not have a very linear project history. :)
Thanks. Just found this paper: https://dl.acm.org/doi/pdf/10.1145/217838.217844.
Very interesting. Why didn't Dylan and Smalltalk make it, i.e. in which respect was NewtonScript better? Was the latter natively compiled or interpreted?
The MessagePad hardware was pretty limited. There was 128kB of RAM, of which NewtonScript got to use about half. But there was 4MB of ROM. So the ability to leave objects in ROM was very important. Most (all?) other languages including Dylan and Smalltalk assume objects all reside in RAM and are mutable. The prototype inheritance system is what made this work, as described in that paper.
NS used a simple bytecode interpreter, except toward the end where we had an AOT native compiler you could apply to individual functions (native functions were much larger than bytecode so you had to be selective).
Later hardware had more RAM (up to 4MB in the MP2000) and we might have been able to try some kind of JIT compilation, if the product had survived longer.
Please accept my thanks to you and the rest of the team --- my Newton MessagePad 110 was one of my most favourite tools--- could you please convince Apple to make an iPhone which supports an Apple Pencil?
It pretty much got me through college, allowing me to balance class schedules and multiple part-time jobs, as well as coordinating a family and tracking my daughter's schedule --- at one point in time I was taking notes in it for Art History (w/ little sketches of each painting/sculpture/building) and faxing them to the secretary for the art department for a learning disabled student --- turned out that that student was then photocopying them for everyone in the dorms to use (this only came out when the professor was asking why everyone's grades were better on average than previous years).
Still kind of sad Apple hasn't made a replacement....
