jordan VS dependent-sum

I'm having some trouble getting GHC to use a quantified constraint in my library jordan (Link is to the specific PR where the issue is arising, and is very much a WIP).

> Let’s say I wanted to introduce Jordan at work, as part of a drive for a Haskell web service. I’d have to explain to everybody what the hell Rank-N types are

If so, that's a problem of jordan's documentation. If it's documented with enough practical examples of how to get things done, and it's not buggy, no one needs to know about how it does it, or even why we have to write "forall" here. And I see from the article that it even uses generic so you can get instances derived for you (probably don't even have to add the RankNTypes pragma in your own files). Even the hand-written examples of https://github.com/AnthonySuper/jordan/blob/master/jordan/RE... don't seem to require any esoteric knowledge. But it's probably hard to write about Haskell without showing off all the fancy features that make things work under the hood :)

I remember following http://www.serpentine.com/wreq/tutorial.html years ago for work while starting out with Haskell. It introduced the absolute minimal stuff needed for lens (I didn't delve any deeper into lens than what the tutorial showed), and I was immediately productive. Now I took a quick look at the source of wreq and the first file I see has RankNTypes, GADT's, etc. and I never knew.

The github page for this project is located here. While I'm not gunning to replace Aeson or anything, I would really appreciate any feedback anybody has to offer!

What is the dependent-sum library for? I must be missing something subtle, because it looks like an over-complicated sum type?