<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Aug 31, 2017 at 3:42 PM Loïc Hoguin <<a href="mailto:essen@ninenines.eu">essen@ninenines.eu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
I certainly hope this is not the general policy for OTP. We program<br>
against the documentation. The documentation *is* our reality.<br>
<br></blockquote></div><div class="gmail_quote"><br></div><div class="gmail_quote">I think it is fair to evaluate on a case by case basis. Some times, the documentation and the implementation are not matching up. This means either the documentation or the implementation is wrong (not xor here!). Which of which is wrong depends a bit on the case, and there are definitely borderline situations where it is very hard to determine which way you should let the thing fall.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">I don't think you can make blanket statements on which way you should lean because there are good counterexamples in both "camps" so to speak.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Another view is that the documentation is the specification. But again, both the specification and the implementation can be wrong and some times the correct operation is to change the specification. When I worked with formal semantics, it was quite common that you altered the specification in ways that let you prove a meta-theoretic property about the specification. Not altering it would simply make the proof way to complicated and hard. Perhaps even impossible. It is an extreme variant of letting the documentation match the reality in a certain sense.<br></div><br></div>