[m-dev.] map.merge argument order

Julien Fischer jfischer at opturion.com
Fri Jan 3 15:35:03 AEDT 2014

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

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

More information about the developers mailing list