July 12th, 2024

Common Expression Language interpreter written in Rust

The GitHub repository features a Common Expression Language (CEL) implementation in Rust, offering a CEL-parser and interpreter for evaluating expressions. It emphasizes simplicity, speed, safety, and portability, providing examples and guidance in Rust, Java, Go, and TypeScript. Detailed documentation is available on the GitHub page.

Read original articleLink Icon
Common Expression Language interpreter written in Rust

The GitHub repository at the provided URL focuses on the Common Expression Language (CEL) implemented in Rust. It contains a CEL-parser and an interpreter tailored for evaluating CEL-expressions. The library prioritizes simplicity, speed, safety, and portability. Users can access examples and guidance on utilizing the library in Rust, with code snippets available in Java, Go, and TypeScript for illustrating CEL expression usage. For those considering leveraging this library, detailed examples and documentation are accessible on the GitHub page dedicated to the Common Expression Language implementation in Rust.

Related

My experience crafting an interpreter with Rust (2021)

My experience crafting an interpreter with Rust (2021)

Manuel Cerón details creating an interpreter with Rust, transitioning from Clojure. Leveraging Rust's safety features, he faced challenges with closures and classes, optimizing code for performance while balancing safety.

Show HN: a Rust lib to trigger actions based on your screen activity (with LLMs)

Show HN: a Rust lib to trigger actions based on your screen activity (with LLMs)

The GitHub project "Screen Pipe" uses Large Language Models to convert screen content into actions. Implemented in Rust + WASM, inspired by `adept.ai`, `rewind.ai`, and `Apple Shortcut`. Open source under MIT license.

Show HN: R2R V2 – A open source RAG engine with prod features

Show HN: R2R V2 – A open source RAG engine with prod features

The R2R GitHub repository offers an open-source RAG answer engine for scalable systems, featuring multimodal support, hybrid search, and a RESTful API. It includes installation guides, a dashboard, and community support. Developers benefit from configurable functionalities and resources for integration. Full documentation is available on the repository for exploration and contribution.

Spending too much time optimizing for loops

Spending too much time optimizing for loops

Researcher Octave Larose shared insights on optimizing Rust interpreters, focusing on improving performance for the SOM language. By enhancing loop handling and addressing challenges, significant speedups were achieved, balancing code elegance with efficiency.

Spending too much time optimizing for loops

Spending too much time optimizing for loops

Researcher Octave Larose discussed optimizing Rust interpreters, focusing on improving performance for the SOM language. They highlighted enhancing loop efficiency through bytecode and primitives, addressing challenges like Rust limitations and complex designs. Despite performance gains, trade-offs between efficiency and code elegance persist.

Link Icon 12 comments
By @clarkmcc - 3 months
Ah, I was wondering why the project was getting a few more eyes today! Maintainer here, I took over this excellent project from Tom Forbes in April 2023. He did a phenomenal job writing the parser and laying the groundwork for an interpreter. One of the beautiful things right now about this project is its simplicity — it’s tiny compared to cel-go for example. I’m also a huge fan of our Axum-style functions[1] where you can register pretty much any closure as a custom function to be used in your CEL expressions. There’s still some mileage to go to support some of the more obscure aspects of the spec, but I feel like we’re getting close, and we have an excellent little cadre of contributors that have been extremely helpful in moving this forward.

[1] https://github.com/clarkmcc/cel-rust/blob/master/example/src...

By @zackbrown - 3 months
This is really cool. I've been building a GUI system in Rust that features an expression language[0] — and we ruled out using CEL a while ago because the canonical Go CEL interpreter would cost several megabytes of runtime footprint (e.g. in a WASM bundle.)

Haven't measured the footprint of cel-rust yet, but I expect it's orders of magnitude smaller than cel-go. The Go runtime itself is the culprit with cel-go.

This Rust implementation may let us port to CEL after all, while maintaining Pax's <100KB wasm footprint. Nice work!

---

[0] https://www.pax.dev

By @ay - 3 months
Very interesting, and looks extremely flexible.

I had needed a small interpretive environment that would be highly controlled, used in a proprietary configuration templating solution for parametrizing various values.

I wrote https://github.com/ayourtch/aycalc - very rudimentary by default with just basic arithmetic, but easy to give different security guarantees, depending on the context - the references to functions and variables can be either separate from each other or share the space, also it’s easy to special-case the handling for both variables and functions.

The entire source code for the library is just around 400 lines, so i thought it can be a different enough type of a beast to mention, in case someone finds it useful.

By @dlahoda - 3 months
there is visual editor which exports cel https://github.com/react-querybuilder/react-querybuilder
By @ramon156 - 3 months
Probably a silly and useless idea, but what if there was an ORM that was designed around CEL?
By @incrudible - 3 months
From the CEL Github page:

> The required components of a system that supports CEL are:

> The textual representation of an expression as written by a developer. It is of similar syntax to expressions in C/C++/Java/JavaScript

Ok

> A binary representation of an expression. It is an abstract syntax tree (AST).

> A compiler library that converts the textual representation to the binary representation. This can be done ahead of time (in the control plane) or just before evaluation (in the data plane).

> A context containing one or more typed variables, often protobuf messages. Most use-cases will use attribute_context.proto

> An evaluator library that takes the binary format in the context and produces a result, usually a Boolean.

Why? All of these sound like implementation details to me, some of which I prefer not to have, such as the necessity for binary representation.

By @lalaithion - 3 months
CEL is super cool, it's really great to have a quick and easy way to add a filter parameter to every list API on your server. This project should add an easy way to take a list/iterator of something that implements Serde Serialize, and filter based on a CEL expression.
By @tempodox - 3 months
Cool! I made something remotely similar, a library for complex arithmetic that dynamically evaluates user-defined expressions. Since it only has pre-defined functions, the compiler can do pervasive constant folding.
By @snthpy - 3 months
Is there an equivalent of CEL for the Arrow ecosystem?

In particular is there a spec for what expressions are admissible for predicates or transformations for example here (https://arrow.apache.org/docs/python/generated/pyarrow.datas...) or in Substrait?

By @junon - 3 months
Man I almost built this exact thing about a year ago and while I would have used it just didn't have enough of a usecase to justify investing the time.

This is awesome work.

By @1oooqooq - 3 months
is CEL just a buzzword/certification gate keeping for typed data?!