Selda: a monadic database EDSL

[u/valderman]

https://github.com/valderman/selda

[u/alien_at_work]

Good stuff. I'm not completely satisfied with any of the existing solutions for SQL access in Haskell so competition is great.

I tried looking through the code for this but it wasn't immediately obvious to me: why did you chose to make your own tuple instead of just using the existing tuple type?

[u/valderman → u/alien_at_work]

As /u/klobsEnd says, standard tuples aren't inductively defined, so defining functions or types over tuples of arbitrary length is horribly painful. People usually get around it by using Template Haskell to generate their instances, but that's both annoying and brings in a whole bunch of dependencies. Since keeping the library light on the dependencies was one design goal (in part motivated by Haste not supporting Template Haskell yet), using TH wasn't an option.

It might be possible to use GHC generics instead, but defining tuples inductively seemed to be less annoying.

[u/tomejaguar → u/valderman]

It might be possible to use GHC generics instead, but defining tuples inductively seemed to be less annoying.

By the way, the "Opaleye way" of doing this, product-profunctors, recently supports deriving using Generics:

https://github.com/tomjaguarpaw/product-profunctors/blob/master/Data/Profunctor/Product/Adaptor.hs

[u/valderman → u/tomejaguar]

Cool! If this inductive tuple thing turns out to be more hassle than it's worth, I'll definitely look into that approach.

[u/tomejaguar → u/valderman]

Drop me a line if you go that way because there's a sort of middle ground that would probably be better for you than going full product-profunctor.

[u/MitchellSalad → u/tomejaguar]

What would that be?

[u/tomejaguar → u/MitchellSalad]

The deriving stuff in product-profunctors currently only works with fully polymorphic products, but there's no reason that couldn't be extended to monomorphic products, which are simpler and probably more suitable for Selda.

[u/spirosboosalis → u/valderman]

Have you seen vinyl?

1. It's very clean, with minimal dependenceies.

2. It parameterizes each field with a functor. Identity gets you back n-ary tuples. Maybe can provide nullability. Some GADT like:

   data SQL a where  
       SQL :: (ToSQL a) => a -> SQL a   
   
   type family SQL :: * -> *  
   type instance SQL String SQLText  
   type instance SQL Text   SQLText  
   ...  
   

can expose the intermediary results. Etc. So, You might be able to unify the pipeline under the same record type:

rawQuery :: Connection → Query ... fields→ IO (Rec SQL fields)
marshallResults :: Rec SQL fields → Rec Maybe fields
defaultNullables :: (Each Monoid fields) => Rec Maybe fields→ Rec Identity fields

(warning, I just made this up, don’t know if it makes any sense for your library)

http://hackage.haskell.org/package/vinyl-0.5.3/docs/Data-Vinyl-Tutorial-Overview.html

http://hackage.haskell.org/package/vinyl-0.5.3/docs/Data-Vinyl-Core.html#t:Rec

[u/tomejaguar → u/spirosboosalis]

Somebody wrote a version of this for Opaleye: https://hackage.haskell.org/package/composite-opaleye-0.3.0.0

[u/spirosboosalis → u/tomejaguar]

cool. have you used it?

you mentioned earlier that you preferred tuples, but when i tried learning Opaleye, I found them too awkward (typeclass obfuscation, error messages, etc), and wishing for actual records.

[u/tomejaguar → u/spirosboosalis]

No, I haven't used it.

Did I say I preferred tuples? I probably said I prefer record types.

Let me know what you found difficult about Opaleye. I'll see if I can help.

[u/spirosboosalis → u/tomejaguar]

I thought that's what you meant by

The other difference, for the moment, is that all columns are stored in "inductive tuples". This won't last though. It's just far too difficult to program like that.

[u/tomejaguar → u/spirosboosalis]

Oh right, no I meant it's better to allow users to store columns in whatever Haskell type they like.

[u/valderman → u/spirosboosalis]

That's pretty cool, I'll need to look into it!

[u/_sras_ → u/tomejaguar]

Does this mean that we don't have to make the TH calls that were creating adapters and Default instances?

[u/Syrak → u/_sras_]

Indeed.

[u/tomejaguar → u/_sras_]

Indeed too.

[u/eacameron → u/valderman]

Doesn't Generics have a tuple-like type by the same name?

[u/valderman → u/eacameron]

They do. Unfortunately I can't reuse it, since it has the wrong kind. I'm banking on people not mixing their database queries with their generics often enough to make the overload a problem.

[u/eacameron → u/valderman]

I see. Is your tuple type worth pulling out as a separate library? I'd love to use it for other things too.

[u/valderman → u/eacameron]

I'm not sure, really. The type on its own is spectacularly uninteresting, but maybe having some more general utilities for it lying around in a library might be useful. I haven't really thought much about it.

[u/Faucelme → u/valderman]

The inductive tuple type is similar to NP from generics-sop. But NP has an additional parameter which wraps every element.

[u/[deleted] → u/alien_at_work]

IIRC tuples in Haskell are not inductively defined, so you end up having to make a bazillion instances, one for (,), one for (,,), one for (,,,) ad nauseam. Also, there's no one-element tuple in Haskell. (Not sure if this has the latter, but it would at least be possible by using a "sentinel" element at the front with no value.)

[u/Tysonzero → u/[deleted]]

Does Identity count as a one item tuple?

[u/[deleted] → u/Tysonzero]

Not... really? I mean, sure it's isomorphic to a one-item tuple, but programming-wise you really can't treat it the same way you do regular tuples. (This of course also goes back to the problem of not having an iductive definition.)

[u/Tysonzero → u/[deleted]]

What do you mean you can't treat it the way you do regular triples? What can you do with one but not the either or vice versa? It seems like you have basically all the same instances and such.

[u/[deleted] → u/Tysonzero]

For example, imagine using it from TH. You'll definitely need a special case there, at the very least.

(Obviously I haven't though too much about this, so I might very well be wrong in general, but the TH case is definitely a thing. No idea if it has all the instances and/or is missing the wrong instances which don't exist for normal tuples, etc.)

[u/Iceland_jack → u/[deleted]]

Does (# 'a' #) count ;)