[m-dev.] map.merge argument order

[Julien Fischer]

On Mon, Dec 9, 2013 at 4:56 PM, Paul Bone <paul at bone.id.au> wrote:

> 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.
>

What on earth do you think it does then?

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


Which should be map.merge/3.

I'm curious to why (of all things) you think this is a problem.

Cheers,
Julien.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/developers/attachments/20131209/717fe65a/attachment.html>