On May 8, 2018 9:02:17 AM UTC, Christopher Allen wrote:

Is this something folks still think is a good idea? I purge Data.Default from projects I work on.

On Tue, May 8, 2018 at 3:58 AM, Marco Zocca wrote:

...

Dear all,

I've been increasingly relying on data-default-class, but sadly it doesn't look like it's currently maintained; there are some tickets on the github issue tracker that would need some attention.

I have tried contacting the authro/current maintainer Lukas Mai (CC'd) by email but have not received an answer so far (I hope he's doing well, btw).

This is my first public request for taking over the `data-default` family of packages:

data-default-class data-default-instances-base data-default-instances-containers data-default-instances-dlist data-default-instances-old-locale data-default

Kind regards, Marco Zocca (http://hackage.haskell.org/user/ocramz) _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- Chris Allen Currently working on http://haskellbook.com _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

It is sometimes useful for things like configuration, where a proper Monoid instance would be tricky and unnecessary. Other than this, I don't know of any legitimate uses.

It's completely lawless and there's no semantically meaningful or unique "default" value for most types. It's much better practice to use explicit default values declared by name and imported explicitly. Data.Default is probably one of the most notorious abuses of type classes in the ecosystem. I'm aware it's common, I'd just hoped people would've started trimming it away. Consider Monoid. What's the default value for `Int`? Should it be the identity? The zero? For which operations over `Int`? A "default" value should either be something explicitly created and defined as a value for a domain-specific purpose or it should have a specific meaning with respect to an operation defined by a law such as w/ the monoids of summation and multiplication. On Tue, May 8, 2018 at 4:10 AM, Marco Zocca wrote:

data-default alone is depended on by > 500 packages : http://packdeps.haskellers.com/reverse/data-default

Could you motivate why it's not a good idea ?

On Tue, May 8, 2018 at 11:02 AM, Christopher Allen wrote:

...

Is this something folks still think is a good idea? I purge Data.Default from projects I work on.

On Tue, May 8, 2018 at 3:58 AM, Marco Zocca wrote:

...

Dear all,

I've been increasingly relying on data-default-class, but sadly it doesn't look like it's currently maintained; there are some tickets on the github issue tracker that would need some attention.

I have tried contacting the authro/current maintainer Lukas Mai (CC'd) by email but have not received an answer so far (I hope he's doing well, btw).

This is my first public request for taking over the `data-default` family of packages:

data-default-class data-default-instances-base data-default-instances-containers data-default-instances-dlist data-default-instances-old-locale data-default

Kind regards, Marco Zocca (http://hackage.haskell.org/user/ocramz) _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- Chris Allen Currently working on http://haskellbook.com

-- Chris Allen Currently working on http://haskellbook.com

Does it make sense to consider stating a law for Default? e.g. if (Monoid t, Default t) then def = mempty On Tue, May 8, 2018 at 11:22 AM Chris Wong wrote:

On Tue, May 8, 2018 at 9:10 PM, Marco Zocca wrote:

...

data-default alone is depended on by > 500 packages : http://packdeps.haskellers.com/reverse/data-default

Could you motivate why it's not a good idea ?

I can think of two reasons:

- It has no laws, so there's formal specification that tells us whether an instance is "correct" or not.

- Type classes are useful when there is a large family of generic operations that can work with them. For example, the utility functions in Control.Monad [1] are used in all kinds of Haskell programs. But there are no such generic operations that apply to all Default instances.

That said -- as you note, it's has quite a few dependents so it's great that someone is stepping up to maintain it regardless.

Chris

[1] https://hackage.haskell.org/package/base-4.11.1.0/docs/Control-Monad.html#g:...

...

On Tue, May 8, 2018 at 11:02 AM, Christopher Allen wrote:

...

Is this something folks still think is a good idea? I purge Data.Default from projects I work on.

On Tue, May 8, 2018 at 3:58 AM, Marco Zocca wrote:

...

Dear all,

I've been increasingly relying on data-default-class, but sadly it doesn't look like it's currently maintained; there are some tickets on the github issue tracker that would need some attention.

I have tried contacting the authro/current maintainer Lukas Mai (CC'd) by email but have not received an answer so far (I hope he's doing well, btw).

This is my first public request for taking over the `data-default` family of packages:

data-default-class data-default-instances-base data-default-instances-containers data-default-instances-dlist data-default-instances-old-locale data-default

Kind regards, Marco Zocca (http://hackage.haskell.org/user/ocramz) _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- Chris Allen Currently working on http://haskellbook.com

---

Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- Chris Wong (https://lambda.xyz)

"I had not the vaguest idea what this meant and when I could not remember the words, my tutor threw the book at my head, which did not stimulate my intellect in any way." -- Bertrand Russell _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

While I very much agree with all of you on the need for solid typeclass laws, I think Default still has its place in the library author toolkit . Think for example of configuration data for very flexible functionality such as plotting. On the other hand, if it's such a bad idea, what's a good course of action in this case ? Take over and deprecate ? On Tue, May 8, 2018 at 11:21 AM, Chris Wong wrote:

On Tue, May 8, 2018 at 9:10 PM, Marco Zocca wrote:

...

data-default alone is depended on by > 500 packages : http://packdeps.haskellers.com/reverse/data-default

Could you motivate why it's not a good idea ?

I can think of two reasons:

- It has no laws, so there's formal specification that tells us whether an instance is "correct" or not.

- Type classes are useful when there is a large family of generic operations that can work with them. For example, the utility functions in Control.Monad [1] are used in all kinds of Haskell programs. But there are no such generic operations that apply to all Default instances.

That said -- as you note, it's has quite a few dependents so it's great that someone is stepping up to maintain it regardless.

Chris

[1] https://hackage.haskell.org/package/base-4.11.1.0/docs/Control-Monad.html#g:...

...

On Tue, May 8, 2018 at 11:02 AM, Christopher Allen wrote:

...

Is this something folks still think is a good idea? I purge Data.Default from projects I work on.

On Tue, May 8, 2018 at 3:58 AM, Marco Zocca wrote:

...

Dear all,

I've been increasingly relying on data-default-class, but sadly it doesn't look like it's currently maintained; there are some tickets on the github issue tracker that would need some attention.

I have tried contacting the authro/current maintainer Lukas Mai (CC'd) by email but have not received an answer so far (I hope he's doing well, btw).

This is my first public request for taking over the `data-default` family of packages:

data-default-class data-default-instances-base data-default-instances-containers data-default-instances-dlist data-default-instances-old-locale data-default

Kind regards, Marco Zocca (http://hackage.haskell.org/user/ocramz) _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- Chris Allen Currently working on http://haskellbook.com

---

Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- Chris Wong (https://lambda.xyz)

"I had not the vaguest idea what this meant and when I could not remember the words, my tutor threw the book at my head, which did not stimulate my intellect in any way." -- Bertrand Russell

Let me give you an example from xmonad. A good configuration system would let me, building a config, use it to set local defaults, like a variant of greenXPConfig for all XMonad.Prompt uses. But I can't use `def` for this. As a user, this has only changed the value I use to build a separate configuration I still have to use --- and done so in a way prone to produce weird errors if I make a mistake. Typeclasses are not flexible enough to provide a good solution here, and `def` ends up an annoyance instead of a help. On Tue, May 8, 2018 at 5:39 AM, Marco Zocca wrote:

While I very much agree with all of you on the need for solid typeclass laws, I think Default still has its place in the library author toolkit .

Think for example of configuration data for very flexible functionality such as plotting.

On the other hand, if it's such a bad idea, what's a good course of action in this case ? Take over and deprecate ?

...

On Tue, May 8, 2018 at 9:10 PM, Marco Zocca wrote:

...

data-default alone is depended on by > 500 packages : http://packdeps.haskellers.com/reverse/data-default

Could you motivate why it's not a good idea ?

I can think of two reasons:

- It has no laws, so there's formal specification that tells us whether an instance is "correct" or not.

- Type classes are useful when there is a large family of generic operations that can work with them. For example, the utility functions in Control.Monad [1] are used in all kinds of Haskell programs. But there are no such generic operations that apply to all Default instances.

That said -- as you note, it's has quite a few dependents so it's great

On Tue, May 8, 2018 at 11:21 AM, Chris Wong wrote: that

...

someone is stepping up to maintain it regardless.

Chris

[1] https://hackage.haskell.org/package/base-4.11.1.0/docs/ Control-Monad.html#g:4

...

On Tue, May 8, 2018 at 11:02 AM, Christopher Allen wrote:

...

Is this something folks still think is a good idea? I purge Data.Default from projects I work on.

On Tue, May 8, 2018 at 3:58 AM, Marco Zocca wrote:

...

Dear all,

I've been increasingly relying on data-default-class, but sadly it doesn't look like it's currently maintained; there are some tickets

on

...

...

...

the github issue tracker that would need some attention.

I have tried contacting the authro/current maintainer Lukas Mai (CC'd) by email but have not received an answer so far (I hope he's doing well, btw).

This is my first public request for taking over the `data-default` family of packages:

data-default-class data-default-instances-base data-default-instances-containers data-default-instances-dlist data-default-instances-old-locale data-default

Kind regards, Marco Zocca (http://hackage.haskell.org/user/ocramz) _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- Chris Allen Currently working on http://haskellbook.com

---

Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- Chris Wong (https://lambda.xyz)

"I had not the vaguest idea what this meant and when I could not remember the words, my tutor threw the book at my head, which did not stimulate my intellect in any way." -- Bertrand Russell

---

Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

I agree that you should avoid Data.Default, but there is still value in keeping the package up to date since it is well-used. I would appreciate it being actively maintained. I would however find it in bad taste to do a take over that immediately marks the package as deprecated... Cheers, Adam On Tue, 8 May 2018 at 22:22 Tony Morris wrote:

Because it's a penalising way of "passing an argument to a function" with no benefit.

On 05/08/2018 07:10 PM, Marco Zocca wrote:

...

data-default alone is depended on by > 500 packages : http://packdeps.haskellers.com/reverse/data-default

Could you motivate why it's not a good idea ?

On Tue, May 8, 2018 at 11:02 AM, Christopher Allen wrote:

...

Is this something folks still think is a good idea? I purge Data.Default from projects I work on.

On Tue, May 8, 2018 at 3:58 AM, Marco Zocca wrote:

...

Dear all,

I've been increasingly relying on data-default-class, but sadly it doesn't look like it's currently maintained; there are some tickets on the github issue tracker that would need some attention.

I have tried contacting the authro/current maintainer Lukas Mai (CC'd) by email but have not received an answer so far (I hope he's doing well, btw).

This is my first public request for taking over the `data-default` family of packages:

data-default-class data-default-instances-base data-default-instances-containers data-default-instances-dlist data-default-instances-old-locale data-default

Kind regards, Marco Zocca (http://hackage.haskell.org/user/ocramz) _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- Chris Allen Currently working on http://haskellbook.com

---

Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

I think it would be better to just define a new typeclass with some added constraints/documentation to clarify what the defaults mean in hasql. It may end up being a copy of the Default class but I'd still prefer that. Cheers, Adam On Thu, 10 May 2018 at 19:08 Viktor Dukhovni wrote:

...

On May 10, 2018, at 12:56 PM, Adam Bergmark wrote:

I agree that you should avoid Data.Default, but there is still value in keeping the package up to date since it is well-used. I would appreciate it being actively maintained.

I would however find it in bad taste to do a take over that immediately marks the package as deprecated...

I use Hasql, and Hasql makes extensive use of Default to implement default encoders for various data types and tuples thereof. Is there a better design that the author of Hasql should be using instead?

https://hackage.haskell.org/package/hasql-1.1.1/docs/Hasql-Encoders.html#t:V...

-- Viktor.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

I think a reasonable alternative is *passive* maintenance. Keep the package compiling, but commit to never adding new instances. This should gradually nudge people away when they try to use the package, find something is missing, and see the big bold "we're not gonna fix that". On Thu, May 10, 2018, 12:56 PM Adam Bergmark wrote:

I agree that you should avoid Data.Default, but there is still value in keeping the package up to date since it is well-used. I would appreciate it being actively maintained.

I would however find it in bad taste to do a take over that immediately marks the package as deprecated...

Cheers, Adam

On Tue, 8 May 2018 at 22:22 Tony Morris wrote:

...

Because it's a penalising way of "passing an argument to a function" with no benefit.

On 05/08/2018 07:10 PM, Marco Zocca wrote:

...

data-default alone is depended on by > 500 packages : http://packdeps.haskellers.com/reverse/data-default

Could you motivate why it's not a good idea ?

On Tue, May 8, 2018 at 11:02 AM, Christopher Allen wrote:

...

Is this something folks still think is a good idea? I purge Data.Default from projects I work on.

On Tue, May 8, 2018 at 3:58 AM, Marco Zocca wrote:

...

Dear all,

I've been increasingly relying on data-default-class, but sadly it doesn't look like it's currently maintained; there are some tickets on the github issue tracker that would need some attention.

I have tried contacting the authro/current maintainer Lukas Mai (CC'd) by email but have not received an answer so far (I hope he's doing well, btw).

This is my first public request for taking over the `data-default` family of packages:

data-default-class data-default-instances-base data-default-instances-containers data-default-instances-dlist data-default-instances-old-locale data-default

Kind regards, Marco Zocca (http://hackage.haskell.org/user/ocramz) _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- Chris Allen Currently working on http://haskellbook.com

---

Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.