<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 3, 2014 at 3:31 PM, Mark Brown <span dir="ltr"><<a href="mailto:mark@mercurylang.org" target="_blank">mark@mercurylang.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<div class="im"><br>
On Mon, Dec 9, 2013 at 3:53 PM, Zoltan Somogyi <<a href="mailto:zs@unimelb.edu.au">zs@unimelb.edu.au</a>> wrote:<br>
> On 09-Dec-2013, Paul Bone <<a href="mailto:paul@bone.id.au">paul@bone.id.au</a>> wrote:<br>
>> 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>
> Some people might, but I would argue that would be wrong; since the output<br>
> has no closer connection to the second input argument than to the first,<br>
> using state variable notation implies a closeness that isn't there.<br>
<br>
</div>Paul buried his most important point deeply in the thread. Namely,<br>
that fold predicates pass the accumulator in the second argument, not<br>
the first, and the accumulator is generally larger. There is a need<br>
for a version of merge suitable for use with fold. I suggest adding<br>
merge_acc (or some such), along with a pointer to it in the comments </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
for merge.<br></blockquote><div><br></div><div>Given that exactly the same situation exists for map.overlay, and was solved</div><div>by introducing map.overlay_large_map, it should probably be map.merge_large_map.</div>
<div><br></div><div>Cheers,</div><div>Julien.</div></div><br></div></div>