[m-dev.] map.merge argument order

[Mark Brown]

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.

For those who remember the creation of the sv* modules, you may recall
that it was the desire to use higher-order programming that motivated
changing the argument order. This was the reason why the difficult
decision was made to put all users through such a change, IIRC, not
merely to make state variables more convenient.

Cheers,
Mark.