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

[João Cristóvão]

> There is always the option of folding Default into base, resolving
concerns about where you get instances for it and the ensuing package
explosion once and for all.

(+1) for that.


2014-05-21 16:37 GMT+01:00 João Cristóvão <jmacristovao at gmail.com>:

> I stand corrected, he actually posted something on github this month.
>
> Lucas, what would you think about merging generics support into
> Data.Default?
>
> João
>
>
> 2014-05-21 16:31 GMT+01:00 João Cristóvão <jmacristovao at gmail.com>:
>
> I definitely see your point, and have suffered that myself, of course.
>>
>> I just guess I did not want to get with the trouble of taking ownership
>> of a package, after trying to contact Lucas Mai on February this year, with
>> no response.
>> His github repository shows no activity since October last year.
>> https://github.com/mauke
>>
>> But I do guess it is the right thing to do: if anyone knows Lucas and can
>> contact him, to see if he stills wishes to maintain the package, I would
>> very much appreciate that (I've also included the .cabal listed email in
>> this conversation).
>> If he is not interested or does not respond within a reasonable time
>> frame, I propose myself as maintainer of the package (and will gladly
>> accept suggestions).
>>
>> Cheers
>> João
>>
>>
>> 2014-05-21 16:18 GMT+01:00 Michael Snoyman <michael at snoyman.com>:
>>
>> Starting a new thread to continuing discussing this (I should have done
>>> so in the first place).
>>>
>>> Here's the problem: a class like Default is most useful if everyone's
>>> using the same class. The reason is that multiple libraries are all free to
>>> reexport the `def` symbol, and they'll all refer to the same identifier. If
>>> multiple `def`s exist, then this doesn't work, you need to be careful about
>>> *which* `def` you're using, and you may as well just export a default value
>>> under its own unique name.
>>>
>>> I think data-default-generics is overall an improvement on data-default,
>>> but the very nature of a fork here makes both packages less useful. I'd
>>> much rather that data-default simply merged in data-default-generics.
>>>
>>>
>>> On Wed, May 21, 2014 at 6:12 PM, João Cristóvão <jmacristovao at gmail.com>wrote:
>>>
>>>> Sorry for continuing the off-topic, and for promoting a package of mine:
>>>>
>>>> If you only need the class definition,
>>>> http://hackage.haskell.org/package/data-default-class is a better
>>>> choice, with no dependencies.
>>>>
>>>> If you prefer a single package with all the dependencies (and with
>>>> additional generics support), my own fork might be useful:
>>>> http://hackage.haskell.org/package/data-default-generics
>>>>
>>>> Although I mirrored the original package dependencies, many of which
>>>> might actually be unnecessary... (given the generics implementation).
>>>>
>>>> Cheers
>>>>
>>>>
>>>> 2014-05-21 15:59 GMT+01:00 Michael Snoyman <michael at snoyman.com>:
>>>>
>>>> At the risk of veering terribly off-topic... the splitting of
>>>>> data-default into all of those packages caused me a bunch of dependency
>>>>> headaches, most of which I still don't fully comprehend. I miss the good
>>>>> ol' days of a single package.
>>>>>
>>>>>
>>>>> On Wed, May 21, 2014 at 5:53 PM, Edward Kmett <ekmett at gmail.com>wrote:
>>>>>
>>>>>> I find myself rather hesitant to recommend that instantiation of the
>>>>>> idea ever since it exploded into a half-dozen packages full of orphan
>>>>>> instances, but yes.
>>>>>>
>>>>>> -Edward
>>>>>>
>>>>>>
>>>>>> On Wed, May 21, 2014 at 6:38 AM, Herbert Valerio Riedel <hvr at gnu.org>wrote:
>>>>>>
>>>>>>> On 2014-05-21 at 00:23:44 +0200, Andreas Abel wrote:
>>>>>>> >>> _Lots_ of users initialize empty maps with mempty
>>>>>>> >
>>>>>>> > Well, this is another issue, empty should be overloaded via
>>>>>>> >
>>>>>>> > class Empty a where
>>>>>>> >   empty :: a
>>>>>>>
>>>>>>> Btw, isn't this what
>>>>>>>
>>>>>>>   http://hackage.haskell.org/package/data-default
>>>>>>>
>>>>>>> provides?
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140521/057f6a36/attachment.html>