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

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

You are right, of course, my mistake. So, to simplify: your library exports some data types with some non-obvious defaults: specify them manually. Your library exports some other data types with obvious defaults: let the compiler 'write those' for you. In any way, if the user want's to derive further nested data structures using your types, we can do so because you provided a Default instance. If you didn't, he will have to write all thoses instances by hand. 1) That's better! / More explicit! It is indeed more explicit and it may be easier to the people who read the code. It is also bulkier, and it _forces_ the user to do this. 2) Provide a default instance / let the user decide: The user wants to define its (nested) default instance by hand: it can. The user does not want to define its (nested) default instance by hand, it prefers to use the generics implementation: it can. So, really, this boils down to: should the user be offered this choice? João 2014-05-25 9:56 GMT+01:00 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 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