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

[João Cristóvão]

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/19efa5f7/attachment.html>