joeyh

joeyh at

Interesting to look at http://hackage.haskell.org/package/esqueleto in relation to this.

The Introduction covers most all points raised:

  • It rejects the relational algebra approach, instead wanting any expression in the DSL to be easily translatable to SQL by the user.
  • Wants to support as many SQL features as possible. Presumably uses strong typing to help features tie together in only correct ways, so avoiding the "noise words" in the lisp DSL, although I don't know how well using types scales, given the size of SQL.
  • Rejects portability; it's up to the user to deal with that.

That seems sane, and especially on the portability question, I wonder if that's not better dealt with by first getting a eDSL that can express non-portable SQL, and then dealing with the portability issues at the host language level. Kind of the same way we deal with OS portability.

There are some other tricky things in doing a SQL DSL efficiently, like getting it to fuse queries when composing expressions. IIRC I saw a talk about solving that at ICFP.

Sajith Sasidharan, Christopher Allan Webber likes this.

Christopher Allan Webber shared this.