[m-dev.] map.merge argument order

[Paul Bone]

On Mon, Dec 09, 2013 at 07:05:02PM +1100, Matt Giuca wrote:
> 
> Having said all that, I *strongly dislike* changing libraries like this.
> I've been burned by this before, when the Mercury team re-ordered some
> arguments to map.insert to be more conducive to state variables, breaking
> hundreds of lines of code. This change would be possibly worse, because it
> wouldn't triggered any compiler errors, but may introduce subtle
> performance issues into peoples' code that has already taken into account
> the characteristics of this predicate. (Note: This is just my opinion; I
> have no personal stake in this as I don't think I have any code that uses
> this predicate.)
> 

Thanks Matt for your input.

Whenever we've made changes to the standard library that change or remove an
existing predicate or function we've marked the old version as obsolete
using the obsolete pragma, causing the compiler to issue warnings when
obsolete code it used.  We've then released at least one or two (I don't
remember which) major stable versions of Mercury with the obsolete pragma so
that anyone using obsolete code and following the current version of Mercury
will see an obsolescence message giving them time to update their code.

It is true that there is perhaps more we could do, such as version the
library code and provide longer backwards compatibility.  We are gradually
working towards improving Mercury in these ways and more and will gladly
accept suitable patches and work with contributors.

I'm not proposing to change the behaviour or argument order of anything
without carefully considering such a change.  If we find that through this
discussion changing the argument order would be useful then we would need to
find the best way to do that.  Only after we know the costs and benefits of
such a change can we determine if such a change would actually be
worthwhile.

Thanks.


-- 
Paul Bone
http://www.bone.id.au