[m-dev.] maybe_error type

[Matt Giuca]

On Sun, Apr 21, 2013 at 12:38 PM, Paul Bone <paul at bone.id.au> wrote:

>
> I see what you mean, however I prefer a situation where the names of the
> function symbols are meaningful.  Otherwise we might as well have the
> stupid
> names of the Either monad from Haskell [...] Good symbol/variable names
> are important.
>

I agree.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/developers/attachments/20130421/d050a9a2/attachment.html>