A more useful Monoid instance for Data.Map

[Daniel Peebles]

I don't actually think there are any rules/optimizations for fmap of
newtype constructors or extractors in general. Luckily, unsafeCoerce is
explicitly specified to be safe, in this kind of situation (assuming the
Map is actually parametric in its value type, which it is)! ;)

On Sat, Apr 28, 2012 at 12:31 PM, Evan Laforge <qdunkan at gmail.com> wrote:

> On Fri, Apr 27, 2012 at 7:00 PM, Daniel Peebles <pumpkingod at gmail.com>
> wrote:
> > Why not be explicit about the replacement strategy by injecting your
> values
> > into First/Last? My point is that in terms of functionality, using
> mappend
> > on the values is strictly more general than the current instance. It
> seems
> > unfortunate to be stuck with the current instance for historical reasons,
> > but I guess that's how a lot of this stuff works :/
>
> Yeah, I suppose it would be a bit more regular that way.  I'm always
> reluctant to map newtypes over things other than lists because I don't
> trust there to be a RULES that will eliminate it, but I suppose for
> Map there must be.  I guess I wouldn't mind updating my code if the
> definition changed.  It's hard to change a general purpose method
> though, simply because searching for it in your code will turn up so
> many false positives.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20120428/1fca819c/attachment.htm>