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

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 :

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 :

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 :

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 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 :

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 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 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@haskell.org > http://www.haskell.org/mailman/listinfo/libraries >

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries