[m-dev.] map.merge argument order

[Julien Fischer]

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

> On Mon, Dec 09, 2013 at 03:27:43PM +1100, Julien Fischer wrote:
> > On Mon, Dec 9, 2013 at 3:09 PM, Paul Bone <paul at bone.id.au> wrote:
> >
> > >
> > > 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.
> >
> > It's very helpful if you wish to use state variable notation …
>
> 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:
(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.
(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.

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