Lack of user‑friendly language bindings for e‑graphs
Problem
Current e‑graph implementations are mostly internal research tools that lack external language bindings and ease of use, causing users to face challenges such as unfamiliar languages, missing bindings, and performance limitations when trying to integrate them into their own projects.
Pain points
- Lack of external language bindings (e.g., Clojure, Python, etc.)
- High learning curve for e‑graph concepts, leaving users unsure how to start
- Existing implementations are relatively slow and need optimization
Questions to verify
- Would providing easier‑to‑use language bindings (e.g., Clojure, Python) lower the entry barrier?
- Do users desire more comprehensive binding support in the current implementation?
- Is performance optimization of the existing implementation a key concern?
Evidence
quote · @Anonymous
Nice post and I want to encourage the author to keep going :)Incidentally, I recently vibe coded an e-graph library in Clojure and a CAS system on top of it. I am not very familiar with the theory and my background on symbolic algebra systems was mostly coming from SICP. My motivation was just to play with ideas and "see some things actually happen" also. My library doesn't have any binding support but does do some of the semiring completion stuff mentioned in the post.It was cool to see the numbers for the AC-10 benchmark match exactly. My lib is much slower, so this is motivating me to optimize it a bit. Anyway, I appreciate the post as well as the down to earth writing style.
quote · @Anonymous
Strictly for insiders only? I wouldn't even know where to find out what language that is. It has something to do with e-graphs, which seems to be a veritable rabbit hole.
Disclaimer: this card is distilled by AI from community discussions as “pain point evidence”. It is a starting point for need analysis and validation, not a “validated market need”. AI has analytical limits; please open the original discussion above to manually verify before key decisions.