Show HN: Prela – Purely Algebraic Relation Combinators(github.com)
github.com
Show HN: Prela – Purely Algebraic Relation Combinators
https://github.com/remysucre/prela
Prela is an embedded query language based on Tarski's Algebra of Relations. Its queries are concise, clear, and fast. It is implemented by shallow embedding in a host programming language: Prela operators are regular functions in the host. The implementation follows continuation-passing style which compiles to efficient columnar execution.
13 comments
Julian Hyde (Apache Calcite author) has a side project called Morel
Morel is an ML dialect that can compile set-producing expressions into bytecode that Calcite can execute against databases
Sort of like "If you could query anything with SQL but it's ML instead"
I bring this up because the example query looks very similar to Morel queries
Neat xample of solving a combinatorial optimization problem with a single query that he posted recently to Twitter:
https://x.com/i/status/2062066151841321370
http://blog.hydromatic.net/2026/06/02/package-queries.html
Morel is an ML dialect that can compile set-producing expressions into bytecode that Calcite can execute against databases
Sort of like "If you could query anything with SQL but it's ML instead"
I bring this up because the example query looks very similar to Morel queries
Neat xample of solving a combinatorial optimization problem with a single query that he posted recently to Twitter:
https://x.com/i/status/2062066151841321370
http://blog.hydromatic.net/2026/06/02/package-queries.html
> Prela queries are readable even to those new to the language
Not really, too many obscure symbols.
Certainly learnable but I wouldn't say immediately readable.
Not really, too many obscure symbols.
Certainly learnable but I wouldn't say immediately readable.
It seems to be assuming a familiarity with logic algebras in general. It's main operator is just the common math symbol for logical conjunction (∧) [0] and how familiar it feels versus how obscure it feels depends on your mathematical background (and how long it has been). But yeah, most programming languages tend to prefer operators like & or && or `and` for logical conjunction, so Prela chose the mathematical choice over the programming language choice. Which is perhaps easily explainable by Prela starting as trying to be a pure syntax of Relational Algebra [1] which does usually prefer the mathematical symbols, given it is the mathematical theory (underpinning things like SQL) for academic/mathematical discussion more than a working programming language. Though we live in a time of Unicode where that distinction starts to get blurry again and mathematical symbols are easier to use than prior eras without dedicated APL keyboards or things like that.
[0] https://en.wikipedia.org/wiki/Logical_conjunction
[1] https://en.wikipedia.org/wiki/Relational_algebra
[0] https://en.wikipedia.org/wiki/Logical_conjunction
[1] https://en.wikipedia.org/wiki/Relational_algebra
SQL, JS, Excel are really hard to substitute because of how widely used they are by people. Even if something new comes up that it's objectively better, so far has always failed gaining traction because of this reality.
I wonder though, is such a dialect better for agents? Have you tried to measure if an agent performs better expressing queries in such a language instead of SQL?
I wonder though, is such a dialect better for agents? Have you tried to measure if an agent performs better expressing queries in such a language instead of SQL?
Claude had no problem translating SQL into Prela, and because you have fine grained control over the query plan (a Prela query is a plan), it was able to optimize queries to be very fast
I'm more curious about going from text to Prela instead of going from text to SQL and measuring any difference in the performance there. On one hand models have been trained on a lot of SQL on the other hand they are really good in mathematical reasoning too so thinking in Perla might be a natural fit for them.
There are fewer foot guns in Prela in particular no NULLs which should help both humans and robots.
Having control over the execution plan is super interesting ! This is a very common frustration when writing SQL.
Do you think it would be possible to offer Prela as a direct interface to a relational database?
Do you think it would be possible to offer Prela as a direct interface to a relational database?
Yes, maybe not the language itself, but the ideas behind it. Tarski's Algebra of Relations is actually a better model for modern columns stores than the standard relational algebra, because a column is a binary relation from the primary key into its value.
It would be pretty easy to put a DuckDB data source into this code.
It might be pretty easy to use overloading to get special case implementations that form SQL queries progressively until the results need to be materialized as something like a dataframe for the function code to work on.
It might be pretty easy to use overloading to get special case implementations that form SQL queries progressively until the results need to be materialized as something like a dataframe for the function code to work on.
The heading saying "Simple (SPJ)" caught my eye, because I'm not sure SPJ has ever talked about simplicity in an especially referenceable way. Were you thinking of Rich Hickey's "Simple made Easy", or did SPJ do a presentation I missed out on?