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

[Andreas Abel]

I agree, "default" is just to unspecified.  I do not think it makes 
sense to make a library for this, in any case not in base.

"empty" (for collections) or "dontCare" (for any type) would make more 
sense.

On 29.05.2014 02:17, John Meacham wrote:
> 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
>
>
>


-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

andreas.abel at gu.se
http://www2.tcs.ifi.lmu.de/~abel/