[m-dev.] map.merge argument order

[Paul Bone]

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
notation and the proposed change is.

> 
> Is this something we should
> > try and change?
> 
> 
> To what?  What are you trying to achieve?  You can't prevent
> programmers from using the inefficient argument ordering (however
> the declared arguments are ordered) because both inputs have the
> same type.

I was trying to make state variable notation more convenient.  I wasn't
trying to say that I'd found a way to prevent programmers from doing
inefficient things, it'd be easier to find a reliable method of herding
rats. :-P


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