<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 8 Jun 2016, at 6:19 pm, Reid Barton <<a href="mailto:rwbarton@gmail.com" class="">rwbarton@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Suppose you maintain a library that is used by a lot of first year uni students (like gloss). Suppose the next GHC version comes around and your library hasn’t been updated yet because you’re waiting on some dependencies to get fixed before you can release your own. Do you want your students to get a “cannot install on this version” error, or some confusing build error which they don’t understand?<br class=""></blockquote><div class=""><br class=""></div><div class="">This is a popular but ultimately silly argument. First, cabal dependency solver error messages are terrible; there's no way a new user would figure out from a bunch of solver output about things like "base-4.7.0.2" and "Dependency tree exhaustively searched" that the solution is to build with an older version of GHC. </div></div></div></div></div></blockquote><div><br class=""></div><div>:-) At least “Dependency tree exhaustively searched” sounds like it’s not the maintainer’s problem. I prefer the complaints to say “can you please bump the bounds on this package” rather than “your package is broken”.</div><div><br class=""></div><div>Ben.</div><div><br class=""></div></div></body></html>