<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 9, 2013 at 3:09 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">
<br>
Consider map.merge from the standard library:<br>
<br>
        % Merge the contents of the two maps.<br>
        % Throws an exception if both sets of keys are not disjoint.<br>
        %<br>
        % The cost of this predicate is proportional to the number of elements<br>
        % in the second map, so for efficiency, you want to put the bigger map<br>
        % first and the smaller map second.<br>
        %<br>
    :- func merge(map(K, V), map(K, V)) = map(K, V).<br>
    :- pred merge(map(K, V)::in, map(K, V)::in, map(K, V)::out) is det.<br>
<br>
Execution time is linear in the eize of the first argument and logarithmic<br>
in the size of the second.  I'd like to get an understanding of how people<br>
use this predicate, in particular, would people like to use it with state<br>
variable notation, such as:<br>
<br>
    merge(LittleMap, !BigAccumulatingMap)<br>
<br>
If so the current argument order is unhelpful.  </blockquote><div><br></div><div>It's very helpful if you wish to use state variable notation …</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Is this something we should<br>
try and change?  </blockquote><div><br></div><div>To what?  What are you trying to achieve?  You can't prevent</div><div>programmers from using the inefficient argument ordering (however</div><div>the declared arguments are ordered) because both inputs have the</div>
<div>same type.</div><div><br></div><div>Cheers,</div><div>Julien.</div><div> </div></div><br></div></div>