Remaking a rule-engine DSL

A few years ago, I reimplemented a domain-specific language (DSL) originally designed for the rule engine at work. The toy reimplementation was written in Javascript (originally in Python), and released to GitHub. I did not expect it to do much, as it was specifically designed for a very specific use-case I should not reveal.

A somewhat cute pic vomited by bing copilot

The main goal of the design was something that can be easily serializable. Turing-completeness was not a concern, as I only needed it to do just 2 things:

1. Easy boolean comparison (if x is == to y)
2. Grab a value from a field from a dictionary/hash

I first started with writing anonymous function in Python. However, when I attempted to spread the work to a set of threads/processes, the interpreter complained that lambdas are not serializable. At the time, I needed the logic to live outside the main code, so I eventually create the DSL for the purpose.

The first thing that came to mind was lisp, as I like how the code somewhat resembles arrays/lists. The similarity is a good thing, as I stored the configuration in YAML already. Therefore, I do not have to worry about creating a new way to represent the logic.

Saving the language as a list brings an alternative advantage, I didn’t need to create a parser from scratch, i.e. no need to tokenize / perform lexical analysis (lexer). In other words, the author is the lexer. All I needed to implement is to take the input list, find if it is a program (we call it a rule), and execute it with respect to a context.

const schema = ["condition.Equal", ["basic.Field", "foo"], ["basic.Field", "bar"]];

// returns a function that checks if context.foo === context.bar
const rule = ruler.parse(rule)

const context = {foo: "meow", bar: "woof"};
rule(context) // returns false

Everything worked well and as expected. Then a few days ago I stumbled upon an article to implement scheme in Python. I probably read the article before, when I was putting in a lot of time learning Clojure. However, this time around, I decided to reimplement the library again, back with Python, from scratch.

So this time I needed to tokenize, and perform the lexer on my own. If I only deal with numbers, everything is easy, but when it comes to string things get more complicated. I followed another tutorial, and rediscovered make-a-lisp project. Eventually I gave up, and used the lexer provided by hy-lang.

The lexer takes an s-expression, and returns a structure that resembles an abstract syntax tree. From there, I build my parser by traversing the tree, returning the rule as a closure that takes a dictionary as context.

const schema = ["condition.Equal", ["basic.Field", "foo"], ["basic.Field", "bar"]];

// returns a function that checks if context.foo === context.bar
const rule = ruler.parse(rule)

const context = {foo: "meow", bar: "woof"};
rule(context) // returns false

There’s no real advantage to the new implementation, as I have left the job for a few years. The implementation I left probably still runs well to this date (it better be after so many iterations that led to it). However, I do still learn a thing or two throughout this journey. If you find this interesting, feel free to check out the Javascript (where it expects rule schema in array), or the new Python version (s-expression).

The above is the detailed content of Remaking a rule-engine DSL. For more information, please follow other related articles on the PHP Chinese website!