ryjo

Still working on CLIPS-related libraries. My most recent one is CLIPSmqueue[1]. I'm employed full-time, so progress is slow as CLIPS stuff comes second to that. However, I've got a much larger CLIPS-related project in the works that I've been taking my time on, and I'm excited for when I finally feel ready to release it.

I'm not sure these projects will ever "go anywhere," but at the very least I'm honing my craft as a programmer. I've learned so much, and I have so much more to learn.

---

[1]https://github.com/mrryanjohnston/CLIPSmqueue

Hey, HN. This is a small C library that enables usage of POSIX message queues (mqueue) in CLIPS. This enables IPC between multiple CLIPS processes using kernel-managed message queues, including load-balancing receives and priority-handling.

The repo includes a fairly full test suite as well as examples that demonstrate multi-process communication between CLIPS rules engines.

My purpose in providing this library (and other CLIPS libraries I've released) is to expand the usecases in which CLIPS can be leveraged. Feedback welcome.

Very cool. Neat how you managed to get logical symbols in to the language itself! When might someone use preconditions in Lean theorems?

This article caught my eye because it's focused on imperative programming, and I've been very focused on declarative vs imperative programming over the last few years. I implemented a version of your function in CLIPS, a Rules-based language that takes a declarative approach to code:

(defrule sum-is-0 (list $? ?first $? ?second $?) (test (= 0 (+ ?first ?second))) => (println TRUE))

(defrule sum-is-not-0 (not (and (list $? ?first $? ?second $?) (test (= 0 (+ ?first ?second))))) => (println FALSE))

(assert (list 1 0 2 -1)) (run) (exit)

The theorem you write in Lean to prove the function kind-of exists in CLIPS Rules; you define the conditions that must occur in order to execute the Right Hand Side of the Rule. Note that the above simply prints `TRUE` or `FALSE`; it is possible to write imperative `deffunction`s that return values in CLIPS, but I wanted to see if I could draw parallels for myself between Lean code and theorems. Here's a gist with the simple version and a slightly more robust version that describes the index at which the matching numbers appear: https://gist.github.com/mrryanjohnston/680deaee87533dfedc74b...

Thank you for writing this and for your work on Lean! This is a concept that's been circling in my head for a minute now, and I feel like this article has unlocked some level of understanding I was missing before.

  Location: Pittsburgh, Pa
  Remote: Yes
  Willing to relocate: No
  Technologies: CLIPS, Ruby (on Rails), Go, JavaScript, C, SQL
  Résumé: https://drive.google.com/file/d/1M-tC7qpehmsJfd3JBk3KtXEQ5wDJz89t
  Email: mrryanjohnston (at) gmail
  Website: https://ryjo.codes

12+ years of experience writing code professionally, active in open source, passionate about education and freedom of knowledge. Very interested in Rules Engines. Love working on teams of self-starters, enjoy pushing the boundaries of my understanding. Comfortable mentoring others as well as helping non-technical folks with difficult-to-grok concepts.

Hey, Lio! Thanks so much for the kind feedback. I'm really happy the stuff I write is helpful to others :D

If you haven't seen it, here's a past post that got some good traction on HN that you might find interesting: https://news.ycombinator.com/item?id=40201729

Previous discussion here: https://news.ycombinator.com/item?id=16406471

From the article:

> Conventional programming languages, such as FORTRAN and C, are designed and optimized for the procedural manipulation of data (such as numbers and arrays). Humans, however, often solve complex problems using very abstract, symbolic approaches which are not well suited for implementation in conventional languages. Although abstract information can be modeled in these languages, considerable programming effort is required to transform the information to a format usable with procedural programming paradigms.

> One of the results of research in the area of artificial intelligence has been the development of techniques which allow the modeling of information at higher levels of abstraction. These techniques are embodied in languages or tools which allow programs to be built that closely resemble human logic in their implementation and are therefore easier to develop and maintain. These programs, which emulate human expertise in well defined problem domains, are called expert systems. The availability of expert system tools has greatly reduced the effort and cost involved in developing an expert system.

Really awesome. Thanks for this thorough write-up. I don't totally understand the deeper math concepts mentioned in this article around RNNs, but it's sparked some of my own thoughts. It feels similar to things I've been exploring lately-- that is: building your app interwoven with forward chaining algorithms. In your case, you're using RNNs, and in mine, I'm building into the Rete algorithm.

You also touch on something in this article that I've found quite powerful: putting things in terms of digesting an input string character-by-character. Then, we offload all of the reasoning logic to our algorithm. We write very thin i/o logic, and then the algorithm does the rest.

This is another reason I am learning CLIPS. It implements a form of the Rete algorithm. A Rete network provides the same benefits of a neural network without the bells-and-whistles, and thus would be a great candidate for anyone who thinks they could benefit from the reasoning power provided by LLMs.

> I jump between client projects relatively often

Using debuggers makes a lot of sense in this case. If I had to switch context that frequently between relatively stable applications, it would be helpful to have a debugger framework for doing work.

`printf` statements are helpful when the error exists beneath the debugger: in the application framework itself.

> they're not always available

100% agreed. `printf` is "one tool" I can use to follow the control flow of a function call across frameworks, programming languages, and even operating systems. It's also something I can reliably assume my coworkers have in their tool belt, and thus provides a common language that even multiple different organizations can use to cross-collaborate a specific debugging session.

Writing a JSON parser is a good way to teach yourself better programming practices. I attribute my understanding of pointer arithmetic and i/o streams to my own efforts in parsing/generating JSON.

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

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