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

[João Cristóvão]

> 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 <adam at bergmark.nl>:
>> , 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
>
>