You seem to persist in believing the problem is on the <i>input</i> side. It&#x27;s not; it&#x27;s on the <i>output</i> side. My entire point is that the resulting SQL generation code is what ends up quite hairy, because the way we have found to separate concerns in 2015 and SQL are very, very different.<p>Let me put it this way... it is <i>precisely because</i> a fluent, Haskell-native SQL querying interface little resembles SQL in either syntax or usage that there is the problem. It is precisely that there have to be these library <i>at all</i> that is the problem. If it were easy, these library wouldn&#x27;t even exist, or would be little more than drivers, but they&#x27;re not just drivers... they do a <i>lot</i> of real work.<p>If SQL didn&#x27;t stink by the standards of modern separation of concerns, we wouldn&#x27;t <i>need</i> &quot;ground breaking&quot; work!<p>Or, to put it another another way:<p><pre><code>    $ git clone git@github.com:slick&#x2F;slick.git
    $ cd slick
    $ cloc .
    ---------------------------------------
    Language   files  blank  comment  code
    ---------------------------------------
    Scala      261    3589   3844     23129
</code></pre>
Cut down to just the Scala. 23kilolines of Scala is a lot of Scala! This is not an &quot;easy&quot; task. &quot;Easy&quot; would be something that just wrapped up the existing syntax in a slightly more native form and would clock in somewhere in the several hundred range.