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

[John Meacham]

Obvious completely depends on context, if you are using numbers
multiplicatively then 1 is the obvious default, if you are using them
additively then zero is. 'Nothing' or (Default a => Just def :: Maybe
a) are both reasonable maybe defaults. I'm not saying that default
classes are not sometimes useful, but there is not much need for a
'shared' one when adding the ten lines to your own program is easier
and less likely to cause conflicts or break. In a given context, then
there are obvious defaults, devoid of context then it's all on a whim
and you will have to branch the class anyway when your obvious
disagrees with someone elses.

    John

On Sun, May 25, 2014 at 9:53 AM, João Cristóvão <jmacristovao at gmail.com> wrote:
>> 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
>>
>>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries



-- 
John Meacham - http://notanumber.net/