[m-dev.] map.merge argument order

[Paul Bone]

On Mon, Dec 09, 2013 at 04:40:42PM +1100, Julien Fischer wrote:
> On Mon, Dec 9, 2013 at 4:31 PM, Paul Bone <paul at bone.id.au> wrote:
> >
> > Check again, I'm asserting that the _current_ one isn't good for SV
> >
> 
> I get that.
> 
> 
> > notation and the proposed change is.
> 
> 
> *What* proposed change?  So far as I can see you haven't proposed
> any concrete change.  My two cents on this:  the current predicate versions
> of map.merge/3 is fine because:

I'm proposing that merge(MapA, MapB, Map) take time proportional to the size
of MapA.  Currently it takes time proportional to the size of MapB.

> (1) the efficiency implications of the argument ordering are _clearly_
> documented
> (2) the arguments are in the order that is consistent with what the
> rest of the standard library expects, e.g. list.foldl(map.merge, … does what
> you would expect it to.

No it doesn't.

> (3) there is no additional overhead in traversing the input maps as
> with Zoltan's proposed version that determines the sizes of the
> inputs dynamically.

I agree with this point.  However Zoltan's solution was to keep a version of
the predicate no additional runtime costs for those programmers that know
which map is smaller.


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