<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Dec 27, 2013 at 4:11 PM, Ben Millwood <span dir="ltr"><<a href="mailto:haskell@benmachine.co.uk" target="_blank">haskell@benmachine.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On Sun, Dec 22, 2013 at 12:02:16PM -0800, John Lato wrote:<br>

</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
On Dec 22, 2013 7:28 AM, "Herbert Valerio Riedel" <<a href="mailto:hvr@gnu.org" target="_blank">hvr@gnu.org</a>> wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
<br>
On 2013-12-22 at 11:32:20 +0100, Thomas Schilling wrote:<br></div><div class="im">
> Either I should be able to check at compile time, or I should get a<br>
> defined exception call which then must be handled by the library.  In<br>
> either case it should be documented with the function.<br>
<br>
It might be worth adding more information to the Haddock-comments<br>
mentioning the respective `HAVE_*` CPP symbol and whether a<br>
fallback-implementation is used.<br>
<br>
Moreover, the use of `error` to signal non-existing implementations<br>
could be reconsidered (e.g. maybe switch to a properly thrown<br>
"call-not-implemented" exception)<br>
</div></blockquote><div class="im">
<br>
This would definitely be better than calling error. Personally I would<br>
prefer conditional exports, as it would turn up errors sooner.<br>
<br>
John L.<br>
</div></blockquote>
<br>
What does client code look like, if this is your implementation strategy? Note that the network package recently changed to *stop* conditionally exporting things, because it led to bad error messages (yes, your error is caught at compile time, but it's not so clear what it *is*) and ugly client code. See e.g. <a href="https://github.com/haskell/network/issues/40" target="_blank">https://github.com/haskell/<u></u>network/issues/40</a><br>

</blockquote></div><br></div><div class="gmail_extra">These days I pretty much exclusively work on linux systems, so my client code is pretty clean :)</div><div class="gmail_extra"><br></div><div class="gmail_extra">I would consider that example from the network package a different situation.  Conditionally-defined data types are not the same as a function that might not be exported.  If you're serializing/logging, it makes perfect sense to enumerate values that aren't supported locally for example, and I can see that working around that could lead to really ugly client code.  But I don't think it makes much sense to export a function that just calls error if it's unsupported.  Handling an exception is at least as awkward as CPP in that case, and in practice worse because we can't differentiate between error calls except by matching on the message string.  At least a custom exception would solve that problem.  But for me, conditional exports are still better.  A big advantage for us is that when we update our toolchain (e.g. a new ghc release comes out), it's much faster to find problems in the toolchain build by just typechecking code rather than actually needing to run executables to test every possibly-defined function we might call (of course we do end-to-end testing as well, but this is a case where errors arising sooner leads to significantly less work).</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">As an alternative, how about throwing an exception, but also using CPP to add a WARNING pragma to any function that's system-unavailable?  Then we'd get a good message at compile-time.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">John L.</div></div>