data-default WAS: [containers] Proposal: Change to the Data.Map Monoid

[Adam Bergmark]

> , or do something like:
> defaultXpto = def { manually specify all Int values, white taking
> advantage of the derived remaining fields }.

Then you'd have to tell all users of your library to use defaultXpto and
NOT `def' since that gives the wrong default.


On Sun, May 25, 2014 at 9:49 AM, João Cristóvão <jmacristovao at gmail.com>wrote:

> Well, it seems to be difficult getting a consensus over this.
>
> In one hand some people say its an abuse of the class system. I have a
> hard time seeing this argument as I see an immediate use for this, but
> I guess I'm a pragmatist.
>
> One opinion is that we could add instances but only for
> 'container-like structures' and Newtypes like Product and Sum, leaving
> Int, Word, etc out. That would be better than nothing.
>
> I definitely agree that the class without instances is barely useful
> for the automatic deriving case I detailed above. But regarding that,
> John Lato wrote:
>
> > In practice the problem I have with deriving the instance generically is
> that it just doesn't work.
> > I commonly have several Bool values, and possibly some Ints or Doubles,
> and they all need different defaults.
> > The only way to make that work would be newtypeing over Bool and writing
> the default instances by hand.
> > No thanks, just writing a straightforward value is much nicer.
>
> Perhaps we have wildly different ways of defining things, but I hardly
> see this as a general problem, but rather as a personal preference.
> I either have already defined the Newtype in most cases, and thus do
> not see this as a problem, or do something like:
>
> defaultXpto = def { manually specify all Int values, white taking
> advantage of the derived remaining fields }.
>
> And then only recommend/export the defaultXpto value.
>
> Thus, even adding things like default instances of Int and Word as 0
> hardly strikes me as problem.
> Either you know you want everything to zero, or you would have to
> specify those values anyway, either partially or fully manually.
> Adding a default class and generic implementation _does not take way
> this option_.
>
> But my main point here is: should we limit generic deriving of
> instances because some people don't see value in it for themselves,
> given that some clearly do? It is not something that forces a
> particular way of work, but instead offers you that option, thus I
> cannot understand some of the objections.
> (I guess I'm also wondering this: why isn't generic monoid deriving
> also in base? Perhaps due to the same objections? but this would be
> offtopic, I'm sorry).
>
> Cheers,
> João
>
>
>
>
>
> 2014-05-25 1:14 GMT+01:00 Evan Laforge <qdunkan at gmail.com>:
> > On Sat, May 24, 2014 at 2:11 PM, Markus Läll <markus.l2ll at gmail.com>
> wrote:
> >> So I would be +1 for adding a class to the base (as many would otherwise
> >> re-implement it anyway), but with no instances. The module could also
> state
> >> the policy behind the class, i.e "don't write defaults for widely used
> >> types/types that you didn't create yourself" or whatever else people
> agree
> >> upon.
> >
> > There's not much point to adding a class with no instances, it's not
> > exactly "re-implement" if it's just one line to define.  Put another
> > way, you can't say everyone "re-implements" it if there's no
> > implementation!  And since classes are global, it's anti-modular.
> > It's ok to define non-modular but convenient things in your own
> > program, but the standard library should emphasize modularity.
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://www.haskell.org/mailman/listinfo/libraries
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140525/9ce7c337/attachment.html>