Why are database queries a good place to use Arrows?

Question

I was reading this, which said:

Well, the point is that arrow notation forbids some computations that do notation allows. In particular all “arrow actions” must be “statically” known“.

and it explains:

Statically known" means that if we have a couple of rows of arrow notation

> -- y <- action1 -< x

> -- z <- action2 -< y

then the expression action2 cannot depend on x or indeed anything bound on the left hand side of an arrow notation row.

As far as I understand, this restriction is what makes arrows worthwhile.

Now, I was trying to learn Opaleye and I noticed that it uses arrows to combine things together.

Why is Opaleye using arrows? Why are arrows a well suited thing for this job? What is it about databases/queries that make this restriction useful?

Answer 1

Paramaterized database queries look like arrows:

• each has an input and an output
• they compose
• we want to treat them differently than Haskell functions

Composition (.) (or (<<<)) looks like an SQL subquery. (&&&) looks like an SQL join.

I believe that the "statically known" restriction relates to things you might reasonably be able to translate into SQL. Once you allow fmap / lmap / rmap with arbitrary Haskell functions, that isn't feasible (at least without SQL language extensions and GHC compiler plugins). I haven't worked out the details, though.

I don't know how many of the translations we might manage by hand Opaleye implements.

Answer 2

There is a difficulty around variable scope when combining aggregation and monadic bind in query languages. I've never come up with a particularly satisfying explanation but you can see a historical Reddit post of mine and a (fixed) issue with relational-record for some details.