On 6/25/11 12:00 PM, Jens Blanck wrote: >>> So there's a range of possible Monoid instances for each type, >> >> More for some types than for others. For Maybe there are three: >> >> * always take the first/left value; >> * always take the last/right value; >> * or, use a semigroup operation defined on the values. >> >> The first two options are provided by the First and Last newtypes, and the >> third option is provided by the instance for Maybe itself (except that it >> spuriously requires a Monoid instance instead of just a semigroup). > > But why does the Map instance of Monoid _not_ mimic the one chosen for > Maybe. I claim this causes unnecessary surprises for users (and lifting the > Monoid instance seems more useful, but that is harder to substantiate).
For what it's worth, if people come to a decent enough consensus on which instance should be the default for Data.Map, then we should propose it on the libraries@ list. Of course we'll want to have Data.IntMap behave the same way, and consequently I'd update Data.Trie to follow suit. The various hashable and unordered containers will also probably want to follow suit. For Data.Trie, I only chose the version I did for conformity with IntMap. There's nothing especially interesting about the choice nor difficult about changing it (other than backwards compatibility issues). One issue that will come up, however, is that we'll want to generalize the First and Last newtypes so that they can be used consistently for all of different types which have these three Monoid instances. I'm not sure off hand where those newtypes are living these days, nor how much code it'd break to change them thus (and move them to base, if necessary). -- Live well, ~wren _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
