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

As is, I don't find data-default to be useful, and decided to move away from it in fay for a number of reasons: * You cannot add arguments to it because of the existing Defaulthttp://hackage.haskell.org/package/data-default-0.5.3/docs/Data-Default.html... r => Defaulthttp://hackage.haskell.org/package/data-default-0.5.3/docs/Data-Default.html... (e -> r) instance or run it in e.g. IO (via Chris Done) * The previous point means it's likely you'll have to scrap your instance at some point instead of just changing a type * You need to either re-export def or users need to depend on data-default themselves. Even if it was in base (but not in Prelude) they would need to add an additional import * The semantics needs to be defined for each instance * I don't see any use case for abstracting over different instances of Default * I think it's useful to be explicit about the "default" value you are using. I'm unlikely to use `def' over `Set.empty'. Code is read more often than it's written. I think Empty sounds like a better name. Some things have a clear "empty" value that will never change. I don't object strongly to using Empty/Default for these. On Wed, May 21, 2014 at 5:37 PM, João Cristóvão wrote:

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

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

On Wed, May 21, 2014 at 9:11 AM, Adam Bergmark wrote:

As is, I don't find data-default to be useful, and decided to move away from it in fay for a number of reasons: [...]

I agree. Default is the bad kind of trivial: it gives you nothing, but in exchange takes away type inference and the ability to choose different defaults for varying circumstances. I wouldn't support adding it to base, and prefer to avoid packages that use it.

Hi Brian, John, While I see your point regarding type inference, I have a hard time seing your argument regarding triviality. Of course Data.Default instances for trivial types will be trivial. But that's hardly what I'm arguing about. Nor it is to save a few characters, from writing def instead of defaultStructureWhatever. The case is that for very long and complex structures, filled with trivial values, and with an obvious default value, writing that default value is a task best left for the compiler, with the help of generics.

to... save typing?

Yes, indeed, to save typing a lot of fields with trivial values, and then modifying it again if we add another trivial Text or List or IntMap value. Of course, this only works if there are default values for the trivial types, and what better place for this than Base. One could argue that there is already generic support for Monoids/mempty, but I argue that the subset of types that can have a default value is much bigger than those who have a Monoid instance.

and the ability to choose different defaults for varying circumstances

Well, in that case, you should not provide a Data.Default instance, of course. But there are certainly a lot of cases where the default value does come in handy, initial value of a fold, interacting with C code that requires empty structures, etc. If I am not seeing this right, or there is a better approach, please let me know. João 2014-05-22 1:43 GMT+01:00 John Wiegley :

...

...

...

...

...

Bryan O'Sullivan writes:

...

I agree. Default is the bad kind of trivial: it gives you nothing, but in exchange takes away type inference and the ability to choose different defaults for varying circumstances. I wouldn't support adding it to base, and prefer to avoid packages that use it.

I feel similarly, Bryan. All Data.Default seems to achieve is to overload a single name to... save typing?

If I'm already reading the documentation for a function I need to call, there's no reason the documentation can't also mention the default value I should be using, hopefully with an example of what typical specializations look like.

Having the name 'def' gives me little added benefit, since I don't know what to do with the value other than pass it. And if that's going to be how it's used the majority of the time, the library author could just provide a variant of the function which assumes the default.

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

Hi João,

... with an obvious default value ...

I think that's the problem some people have, that the default values for several types aren't obvious at all and therefore you have to know the default values of several types to easily read code using 'def'. The default values for container like types - like String or List - are mostly quite obvious, they're just the empty ones. But the default values for types like Int, Bool of Float aren't that obvious and they certainly don't make sense in any use case. That's also the reason why an Empty type class was advocated instead of the Default one, because than it's really obvious what the result for container like types is. Greetings, Daniel

I don't agree to Empty either. As I mentioned, the most compelling use cases for Default I see are things like ParserOptions and ConnectionInfo. Empty could be a separate typeclass with a different set of instances. It should probably come with laws (its monofoldable length/size should be 0). Roman * João Cristóvão [2014-05-22 12:36:24+0100]

Hi Roman, Daniel,

I do see your point, and I don't find it a problem. In those particular cases perhaps it only makes sense to define a Default value for the same cases as mempty applies, namely for Sum and Product.

So, I'm fine with not including default values for Int, Bool, Float...

However, I'm not sure I agree with calling it Empty. You might want to use Default with your own Algebraic data type where the concept of Default makes sense, but the concept of Empty does not. The Empty name may be a little too misleading (as mempty is already for Monoid, see the Product newtype).

Cheers, João

2014-05-22 9:10 GMT+01:00 Daniel Trstenjak :

...

Hi João,

...

... with an obvious default value ...

I think that's the problem some people have, that the default values for several types aren't obvious at all and therefore you have to know the default values of several types to easily read code using 'def'.

The default values for container like types - like String or List - are mostly quite obvious, they're just the empty ones. But the default values for types like Int, Bool of Float aren't that obvious and they certainly don't make sense in any use case.

That's also the reason why an Empty type class was advocated instead of the Default one, because than it's really obvious what the result for container like types is.

Greetings, Daniel _______________________________________________ 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

The issue i have is not the concept, I have actually written similar classes in a few situations, the issue is that there is little value in a shared implementation of it. There is no underlying meaning to 'default' that crosses project boundries. seeing 'Default a => blah ' in a type signature doesn't convey any useful information about a other than at some point, someone somewhere added a to a list based on their current whim. That said, I have written the class a few times, and that is fine, just because the code looks the same it doesn't necesarily mean it is conceptually reusable because they had a specific meaning. looking at my codebase I find PerlDefault - what the value would default to if 'undef' in perl. used when generating perl code. HsSynDefault - haskell syntax default, bits of haskell syntax (HsExp, HsDecl, etc..) with the annotations set to default leaving only the source bits to fill in. But both have defined meanings and when I see them in a type signature, it conveys useful information. -- John Meacham - http://notanumber.net/

I'm more or less +/-0 on adding the class itself. That said, I would be -1 on adding the class without adding a comprehensive suite of instances, as that simply forces users into a worse situation than they have now with more orphan instances and collisions between packages that need or want them. If this means that we don't do it at all, I'd prefer that to doing something badly, and producing a result which is less useful than the existing alternative. -Edward On Sat, May 24, 2014 at 11:11 PM, Markus Läll wrote:

For me, the default makes sense, too, in the very specialised cases (in the world of things that have types) like settings of a web server or cvs parser, where the application author defined it for to quickly launch some program or function. The 'default' there would mean 'something sensible', the meaning of which I don't yet care about. Probably the author of the package is also a frequent user of the default to test the thing he is writing.

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.

On Thu, May 22, 2014 at 10:08 PM, John Meacham wrote:

...

The issue i have is not the concept, I have actually written similar classes in a few situations, the issue is that there is little value in a shared implementation of it. There is no underlying meaning to 'default' that crosses project boundries. seeing 'Default a => blah ' in a type signature doesn't convey any useful information about a other than at some point, someone somewhere added a to a list based on their current whim.

That said, I have written the class a few times, and that is fine, just because the code looks the same it doesn't necesarily mean it is conceptually reusable because they had a specific meaning. looking at my codebase I find

PerlDefault - what the value would default to if 'undef' in perl. used when generating perl code. HsSynDefault - haskell syntax default, bits of haskell syntax (HsExp, HsDecl, etc..) with the annotations set to default leaving only the source bits to fill in.

But both have defined meanings and when I see them in a type signature, it conveys useful information.

-- John Meacham - http://notanumber.net/ _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Markus Läll

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

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 :

On Sat, May 24, 2014 at 2:11 PM, Markus Läll 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

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 :

...

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

...

On Sat, May 24, 2014 at 2:11 PM, Markus Läll 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

---

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

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

...

...

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

...

On Sat, May 24, 2014 at 2:11 PM, Markus Läll 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@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

-- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/

On Thu, May 29, 2014 at 9:44 AM, Bryan O'Sullivan wrote:

Yes, of course we should. The whole point of having typeclasses is that the instances should make sense for everyone. The bar for introducing both typeclasses and especially automatically derived instances is a whole lot higher than "works for me, sometimes".

I think a lot of early haskell programmers are very biased towards type classes when higher order functions are a much better solution to a given problem. You can write automatic deriving code for user classes directly now: http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/generic-programming.h... currently GHC only, but as soon as type families are solid It's definitely something I'm putting into jhc. John -- John Meacham - http://notanumber.net/

I honestly don't feel very strongly about usage of Default. What I've found it useful for is a very narrow category: a function which takes a configuration parameter that users likely never want to modify. For example: xml-conduit has various parsing and rendering settings, but most use cases are good with the default. There's a cognitive overhead for a user to remember the default parameter name (is it defaultXMLSettings? defaultXmlSettings? defParseSettings?). On Wed, May 21, 2014 at 7:11 PM, Adam Bergmark wrote:

As is, I don't find data-default to be useful, and decided to move away from it in fay for a number of reasons:

* You cannot add arguments to it because of the existing Defaulthttp://hackage.haskell.org/package/data-default-0.5.3/docs/Data-Default.html... r => Defaulthttp://hackage.haskell.org/package/data-default-0.5.3/docs/Data-Default.html... (e -> r) instance or run it in e.g. IO (via Chris Done) * The previous point means it's likely you'll have to scrap your instance at some point instead of just changing a type * You need to either re-export def or users need to depend on data-default themselves. Even if it was in base (but not in Prelude) they would need to add an additional import * The semantics needs to be defined for each instance * I don't see any use case for abstracting over different instances of Default * I think it's useful to be explicit about the "default" value you are using. I'm unlikely to use `def' over `Set.empty'. Code is read more often than it's written.

I think Empty sounds like a better name. Some things have a clear "empty" value that will never change. I don't object strongly to using Empty/Default for these.

On Wed, May 21, 2014 at 5:37 PM, João Cristóvão wrote:

...

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

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

Why not defining a class in xml-conduit then?

This is hardly something that affects just one or two packages. http://packdeps.haskellers.com/reverse/data-default There seems to be 232 packages using Data-Default. Cheers 2014-05-21 19:46 GMT+01:00 Michael Snoyman :

I honestly don't feel very strongly about usage of Default. What I've found it useful for is a very narrow category: a function which takes a configuration parameter that users likely never want to modify. For example: xml-conduit has various parsing and rendering settings, but most use cases are good with the default. There's a cognitive overhead for a user to remember the default parameter name (is it defaultXMLSettings? defaultXmlSettings? defParseSettings?).

On Wed, May 21, 2014 at 7:11 PM, Adam Bergmark wrote:

...

As is, I don't find data-default to be useful, and decided to move away from it in fay for a number of reasons:

* You cannot add arguments to it because of the existing Defaulthttp://hackage.haskell.org/package/data-default-0.5.3/docs/Data-Default.html... r => Defaulthttp://hackage.haskell.org/package/data-default-0.5.3/docs/Data-Default.html... (e -> r) instance or run it in e.g. IO (via Chris Done) * The previous point means it's likely you'll have to scrap your instance at some point instead of just changing a type * You need to either re-export def or users need to depend on data-default themselves. Even if it was in base (but not in Prelude) they would need to add an additional import * The semantics needs to be defined for each instance * I don't see any use case for abstracting over different instances of Default * I think it's useful to be explicit about the "default" value you are using. I'm unlikely to use `def' over `Set.empty'. Code is read more often than it's written.

I think Empty sounds like a better name. Some things have a clear "empty" value that will never change. I don't object strongly to using Empty/Default for these.

On Wed, May 21, 2014 at 5:37 PM, João Cristóvão wrote:

...

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

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 < >> hvr@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@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 > >

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