[m-dev.] map.merge argument order

[Paul Bone]

Hi guys.

Consider map.merge from the standard library:

        % Merge the contents of the two maps.
        % Throws an exception if both sets of keys are not disjoint.
        %
        % The cost of this predicate is proportional to the number of elements
        % in the second map, so for efficiency, you want to put the bigger map
        % first and the smaller map second.
        %
    :- func merge(map(K, V), map(K, V)) = map(K, V).
    :- pred merge(map(K, V)::in, map(K, V)::in, map(K, V)::out) is det.

Execution time is linear in the eize of the first argument and logarithmic
in the size of the second.  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)

If so the current argument order is unhelpful.  Is this something we should
try and change?  I recognize that obsoleting (with or without the pragma) a
predicate only to replace it with one with the exact same type/mode
signatures will be problematic, but I think that's a different question.
For now it'd be useful to know if the current argument order is inconvenient
or not and to what extent.

Thanks.


-- 
Paul Bone
http://www.bone.id.au