<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Apr 21, 2013 at 12:38 PM, Paul Bone <span dir="ltr"><<a href="mailto:paul@bone.id.au" target="_blank">paul@bone.id.au</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
</div>I see what you mean, however I prefer a situation where the names of the<br>
function symbols are meaningful.  Otherwise we might as well have the stupid<br>
names of the Either monad from Haskell [...] Good symbol/variable names are important.<br></blockquote><div><br></div><div style>I agree.</div><div style><br></div><div style>But I would recommend against changing the library in a way that could break existing code. (It sounds like the previous change to maybe_error, keeping the old one as an overload, was a backwards-compatible change.) I have been burned several times by Mercury's standard library suddenly changing, and breaking my code. (On two occasions, I believe, the argument order of some predicates changed, and on a third, the string type suddenly became Unicode-aware.) In all of these occasions, the change was for "the greater good", and the library was better after the change than before, but it broke code, and worse, it was not possible to carefully write code that would work before and after the break.</div>

<div style><br></div><div style>But Mercury is a mature project now. It is out of beta (that used to be the excuse, for fifteen years, "we're version 0.x so we can change whatever we want"), and it has external users. It should no longer be breaking in between minor releases. Making breaking changes should be a major coordinated effort (akin to Python 3), not just something a developer does spontaneously because he sees an opportunity for improvement.</div>

</div></div></div>