[m-dev.] map.merge argument order

[Julien Fischer]

On Fri, Jan 3, 2014 at 3:31 PM, Mark Brown <mark at mercurylang.org> wrote:

> Hi,
>
> On Mon, Dec 9, 2013 at 3:53 PM, Zoltan Somogyi <zs at unimelb.edu.au> wrote:
> > On 09-Dec-2013, Paul Bone <paul at bone.id.au> wrote:
> >> 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)
> >
> > Some people might, but I would argue that would be wrong; since the
> output
> > has no closer connection to the second input argument than to the first,
> > using state variable notation implies a closeness that isn't there.
>
> Paul buried his most important point deeply in the thread. Namely,
> that fold predicates pass the accumulator in the second argument, not
> the first, and the accumulator is generally larger. There is a need
> for a version of merge suitable for use with fold. I suggest adding
> merge_acc (or some such), along with a pointer to it in the comments

for merge.
>

Given that exactly the same situation exists for map.overlay, and was solved
by introducing map.overlay_large_map, it should probably be
map.merge_large_map.

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