[m-dev.] map.merge argument order

[Zoltan Somogyi]

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.

The only change to the interface that I think may be helpful is a version
of merge that dynamicaly FIGURES OUT which map is the smaller, and does
the right thing performance-wise. It should be possible to code it in a way
that figures this out WITHOUT traversing the bigger map completely, which
is important, since it could be huge. However, note that even if this is done,
the test will add overhead, so if the programmer knows in advance which map
will be larger, the old predicate will still be preferable. The new predicate
would be better only in two cases: for programs where each input map is the
bigger one some of the time, and for programs whose programmers do not want
the burden of understanding the behavior of their own programs :-(

Zoltan.