Interestingly, this is not the way it works with beam. You have to figure out what query you want to write and then you have to translate that to beam. That correspondence is natural because beam is close to relational algebra. Then beam generates SQL automatically, again very naturally because beam is close to (the semantics of) SQL.
Ah ok, you're talking about SQL as being an abstraction from relational algebra. Yes I wish more people thought about SQL this way but I'm not sure how many actually do.
I can see that this would be a benefit in the long run, but it wouldn't be familiar to most devs in the beginning. Similar to learning Haskell, once you get over the hurdle of the concepts then there's less to think about over all but there is still that initial gap.
Certainly the declaritive nature of SQL should be a very good fit for Haskell.
Interestingly enough, Haskell has an inefficient version of the relational algebra builtin. The default monad instance for list provides all the semantics you need. Beam steels from this intuition. Most Haskell developers are familiar with using the list monad, so things come somewhat naturally.
The types go a bit crazier than lists internally, but the aim is minimize the times manual intervention is required
