Lispex is a language for writing business rules, such as a publisher's house style. It cannot touch files or the network, so it is safe to run inside any program.
We built Lispex because we needed a language we could trust with our rules. The full Topaz CLI includes the Lispex evaluator, so apps built with Topaz can load rules written in Lispex and run them safely.
1. Start from real rules
Lispex starts from rules people actually use. It is meant for rules that must give one answer for a given input, such as a house style or a shipping fee.
Before we add a feature, we check that the same input still gives the same answer and that a reader can follow how the rule got there. A rule decides, and the application that calls it acts on the decision. Features that would blur that line stay out of the language.
2. What is public, and who is responsible
STUDIO HAZE designs, develops and releases Lispex. One team owns the roadmap and the technical decisions, which keeps the design consistent and the project maintainable for the long term.
Official releases and public material are published in the public GitHub repository. Documentation and downloads are on this website. The evaluator source is not published, and internal development happens in a separate repository.
Both the npm package and the native executables are released under the Apache License 2.0. Every release also includes a notices file with the licenses of the libraries built into the executables.
3. The safety promise, and how to check it
A Lispex program cannot read or write files and cannot use the network. A rule only returns an answer. The application that called it decides what to do with that answer, and it also sets the limits the rule runs under.
Our next goal is to let anyone check this promise for themselves. Alongside Topaz 5.22, we will publish the language specification, the embedding contract Topaz uses and a conformance suite in the public repository.
4. Technical feedback
We value feedback from people who look closely at Lispex and point out its flaws. Bug reports with a rule and an input that reproduce the problem, wrong diagnostics, and cases where the documentation and the actual behavior disagree are some of the most useful things we receive.
Please send them as GitHub issues. We review reports by impact and reproducibility, and we weigh feature proposals against the design principles of Lispex and their value for real rules.
5. Evolution and compatibility
X.Y.0 is the first release of a new minor version. Later patch releases in the same line are compatible repairs. Versions and files we have already published stay available as they are.
When a change affects compatibility, the history explains why and how to move to it. What we are planning now is on the roadmap.
Lispex is the language we trust with our rules. We hope other developers come to trust it with theirs.