[m-dev.] map.merge argument order

Peter Schachte pschachte at gmail.com
Mon Dec 9 19:31:30 AEDT 2013


On 09/12/13 19:05, giucam (contact) 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.

I'd like to amplify Matt's comments on this.  Changing argument order in
the standard library has been a constant irritation to me and my
students in Declarative Programming.  Students do their work on their
own laptops, and then submit it to be assessed on centrally maintained
machines, and these tend to be different versions.  It's mystifying at
first that the the code won't compile, and unfortunately, the error
messages are often not very helpful locating the problem in such cases. 
OK, it's not unexpected to find that code written with the latest
library may not work with an older library version, but the fact you
can't drop back to using the old version and expect it to work with both
is not what one expects, and it can be time consuming and frustrating to
engineer code that will work with multiple versions of the mercury library.

-- 
Peter Schachte               I suppose it is tempting, if the only tool
University of Melbourne      you have is a hammer, to treat everything
schachte at unimelb.edu.au      as if it were a nail. -- Abraham Maslow
www.cs.mu.oz.au/~schachte/
Phone: +61 3 8344 1338
I support the NTEU's campaign for a fair enterprise agreement.
Find out more: nteu.org.au/melb | facebook.com/nteu.unimelb

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/developers/attachments/20131209/89a3e34e/attachment.html>


More information about the developers mailing list