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

João Cristóvão jmacristovao at gmail.com
Sun May 25 07:49:20 UTC 2014


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


More information about the Libraries mailing list