[m-dev.] map.merge argument order

[Paul Bone]

On Mon, Dec 09, 2013 at 03:53:05PM +1100, Zoltan Somogyi 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.

This is a good point, often these parameters aren't related.  However
sometimes they are, see compiler/interval.m:1085

    create_shadow_vars(ArgVars, VarsToExtract, VarSet0, VarSet,
        VarTypes0, VarTypes, map.init, NewRename, map.init, VoidRename),
    !:VarInfo = interval_var_info(VarSet, VarTypes),
    map.old_merge(!.VarRename, NewRename, !:VarRename),

State variable notation seems to make sense here.


> 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 :-(

Agreed.  I wonder if the non-automatic one should be the version whose name
is shorter, encouraging it's use.  This possibly puts the programmers who do
not want the burden of understanding their programs at a disadvantage,
however they're already at a loss and I won't loose much sleep about it such
a decision.

Since in Mercury we don't have destructive update and usually have to
reconstruct the parts of a tree that refer to the parts that actually
changed.  Is there any significant extra cost to storing the size of the
subtrees within each node?  (I don't expect to find current Mercury-specific
benchmarks, but I wonder if some general benchmarks exist.)

Thanks for your feedback.


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