> but it would not be okay for so many ORM people to actually have properly bound SQL in-place.

It's okay... sometimes. But, as what the article is about, more often than not you need to start composing that SQL. SQL does not deal well with composability natively. Which means you need to bring your own solution to work around its limitations.

In theory, you could parse the SQL and build up some kind of AST on which composition could be built. Or, you could write a set of functions in the application language which somewhat resemble SQL, as demonstrated in the article, that build the same AST. It turns out the latter is considerably easier to implement.

> In theory, you could parse the SQL and build up some kind of AST on which compatibility could be built.

This is an interesting problem that I'd like to learn more about. Have you read anything about it?