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

, 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 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 :

...

On Sat, May 24, 2014 at 2:11 PM, Markus Läll 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

---

Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries