Clojurians Log v2

> Pipe syntax naturally expresses queries with linear operator structure. Complex queries with tree-like structure don’t map as directly to pipe syntax. Quite a strong disincentive, I'd say. And, on top of that: > Automated translation is an area for future work

Yea, it only minimally helps compose complex queries from simpler subqueries. It seems like it's still not possible to build large queries from smaller pieces without string concatenation. Maybe the string concatenation is a bit more simplified, but it's still string manipulation.

I probably was not clear in my original question: I am interested in using honey to construct sql pipe syntax strings. I am not interested in translating pipe syntax to original SQL. As for its use, I work primarily with event logs. One use case is to measure changes in states reflected in the log. As such, I make heavy use of nested analytic functions. BigQuery does not support recursive analytic functions so you have to rely on inline views or CTEs. That gets nasty pretty quickly for exactly the same problem that threading macros address. Pipe syntax is easier to look at and easier to generate.

I think your intent was clear, I was just describing why it's extremely unlikely to find something like this. A niche thing times a niche thing times a serious limitation equals almost zero. If you can query what you want with the pipe syntax despite its limitations and if you don't actually have to look at the pipe queries, then I'd just create a few helper functions for HoneySQL that convert a "pipe-like" linear definition into a regular nested map. Should be easy enough since there's no need to deal with parsing and combining strings.