search

tomjaguarpaw / haskell-opaleye

Other
601 stars 115 forks source link

API design: why arrows? #409

Closed bollu closed 4 years ago

bollu commented 5 years ago

Hello,

I'm sorry I couldn't find a better channel of communication for this --- I was unable to find your e-mail on your Github account, so I decided to raise an issue.

I'm trying to understand what benefit Opaleye draws from using arrows and profunctors. Does the use of arrows allow Opaleye to inspect the computation structure before running the query? If so, could you link me to some code examples that does this? If now, why arrows? Is it because you feel that arrow syntax is a better fit for SQL queries?

I ask this from the context of bollu/dataflow where I'm experimenting with writing a DSL for a dataflow based chip (currently an interpreter, but I want to synthesise said chip on an FPGA at some point).

I'd love to hear about how to effectively use arrows to structure computation.

Thanks!

tomjaguarpaw commented 5 years ago

It's because a monad interface for Select would allow you to write crashing queries. See for example https://github.com/khibino/haskell-relational-record/issues/19.

I can't say I fully understand the issue but it's certainly nothing to do with inspecting the computation structure before running the query. That would be possible in Opaleye even with a monad, because the things that appear inside the Select type constructor are Fields. They are basically abstract so subsequent operations can't depend on their values anyway.

bollu commented 5 years ago

I see, thank you.

Are you aware of surrounding literature to optimise arrow computations by inspecting their structure? I'm trying to pick your brain on this :)

Feel free to close the issue, btw!

tomjaguarpaw commented 5 years ago

I'm not aware of any literature specifically.

There is a top down approach to this and a bottom up approach. The top down approach would be to think what algebraic structure the components of your DSL have. Then make them an instance of the typeclass which encodes that structure. The bottom up approach would be to define an intermediate representation which allows inspection and then see what style of surface DSL you can put on top of that.

tomjaguarpaw commented 4 years ago

I can now explain this a bit better: the left type parameter to a SelectArr is an upper bound on the free variables that can appear inside the SELECT. This is important because in the absence of LATERAL, aggregation, DISTINCT, binary operations, etc., require there to be no free variables in their argument.

However, given that we now have LATERAL support, this is moot.