<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Dec 9, 2013 at 4:31 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"><div class="im">On Mon, Dec 09, 2013 at 03:27:43PM +1100, Julien Fischer wrote:<br>
> On Mon, Dec 9, 2013 at 3:09 PM, Paul Bone <<a href="mailto:paul@bone.id.au">paul@bone.id.au</a>> wrote:<br>
><br>
> ><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<br>
> > elements<br>
> >         % in the second map, so for efficiency, you want to put the bigger<br>
> > 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.<br>
><br>
> It's very helpful if you wish to use state variable notation …<br>
<br>
</div>Check again, I'm asserting that the _current_ one isn't good for SV<br></blockquote><div><br></div><div>I get that.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

notation and the proposed change is.</blockquote><div><br></div><div>*What* proposed change?  So far as I can see you haven't proposed</div><div>any concrete change.  My two cents on this:  the current predicate versions of map.merge/3 is fine because:</div>
<div>(1) the efficiency implications of the argument ordering are _clearly_</div><div>documented</div><div>(2) the arguments are in the order that is consistent with what the</div><div>rest of the standard library expects, e.g. list.foldl(map.merge, … does what</div>
<div>you would expect it to.</div><div>(3) there is no additional overhead in traversing the input maps as</div><div>with Zoltan's proposed version that determines the sizes of the</div><div>inputs dynamically.</div><div>
<br></div><div>Cheers,</div><div>Julien.</div></div><br></div></div>