[m-dev.] map.merge argument order

[Julien Fischer]

On Mon, Dec 9, 2013 at 3:09 PM, Paul Bone <paul at bone.id.au> wrote:

>
> Consider map.merge from the standard library:
>
>         % Merge the contents of the two maps.
>         % Throws an exception if both sets of keys are not disjoint.
>         %
>         % The cost of this predicate is proportional to the number of
> elements
>         % in the second map, so for efficiency, you want to put the bigger
> map
>         % first and the smaller map second.
>         %
>     :- func merge(map(K, V), map(K, V)) = map(K, V).
>     :- pred merge(map(K, V)::in, map(K, V)::in, map(K, V)::out) is det.
>
> Execution time is linear in the eize of the first argument and logarithmic
> in the size of the second.  I'd like to get an understanding of how people
> use this predicate, in particular, would people like to use it with state
> variable notation, such as:
>
>     merge(LittleMap, !BigAccumulatingMap)
>
> If so the current argument order is unhelpful.


It's very helpful if you wish to use state variable notation …

Is this something we should
> try and change?


To what?  What are you trying to achieve?  You can't prevent
programmers from using the inefficient argument ordering (however
the declared arguments are ordered) because both inputs have the
same type.

Cheers,
Julien.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/developers/attachments/20131209/4efd8467/attachment.html>