<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 24, 2016 at 11:06 PM, Tom Ellis <span dir="ltr"><<a href="mailto:tom-lists-haskell-cafe-2013@jaguarpaw.co.uk" target="_blank">tom-lists-haskell-cafe-2013@jaguarpaw.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm planning to update and refresh Opaleye's documentation and add some new<br>
functionality for common use cases. To help with this I'd like to request<br>
input from anyone who has ever tried the library.<br>
<br>
Specifically, what do you (or did you) find hard about using Opaleye and<br>
what did you dislike about it? If you tried it and gave up, what was the<br>
major sticking point?<br></blockquote><div><br></div><div>I dislike the whole `Default` type class stuff and have a very hard time reasoning about what is going on behind it. I understand it's basically creating "n-ary structures" (the description is as vague as my understanding), but I still struggle with it. My preference here is specific type classes for the operations that need constraints on what a table is (which could be derived generically on base data types).</div><div><br></div><div>Worse, the lack of type inference on left joins is an absolute killer. Knowing that my application will ultimately need a left join at some point makes me very uneasy about introducing Opaleye, because I just know how frustrating it's going to be when I get to that point.</div><div><br></div><div>I dislike the need for arrows (and lets be honest, it really is a need - using just functor/applicative/category leads to even less readable code), but as we both know - no one has found a viable alternative yet.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm already aware that many people dislike the boilerplate involved in<br>
defining your tables and types, and the polymorphic products are<br>
particularly uncomfortable for some. You don't need to mention these issues<br>
unless you particularly want to!<br></blockquote><div><br></div><div>I do want to, because they prevent me from using the library as is. Instead, I use it as an implementation layer and have to roll my own API on top. </div><div><br></div><div>I hope this is constructive, I don't intend this to be just a rant. I am still using Opaleye, in spite of these issues!</div><div>- ocharles</div></div></div></div>