data-default

data-default copied to clipboard

I may be missing something, but as I see it the reason to split the original data-default into separate packages is to minimize dependencies.

As both data-default-class and data-default-instances-base only introduce the base dependency, we could merge the packages.

Keeping the separate packages has the downside that the instances in data-default-instances-base are orphan (which I generally considered undesirable). Are there any upsides?

+1

I'll add data-default-instances-containers and data-default-instances-old-locale as well, as the corresponding packages come bundled with GHC anyway.

Given that dlist is the only dependency which isn't pre-installed, I'm starting to question the reasoning behind splitting data-default in the first place.

I agree with @sol. I have always avoided the Default class in this package entirely because of the dlist dependency, which seemed totally gratuitous. But nowadays both old-locale and containers are both weird dependencies to have, and not required by many packages (the fact they are shipped with GHC is mostly historical). Merging data-default-class and data-default-instances-base keeps the dependencies light (which is what you expect for a package that defines only one trivial class).

As concrete examples, I'd love to use the union of data-default-class and data-default-instances-base in both CmdArgs and Shake, but would only do so if there was one package, that required only base, and that defined both the class and instances for the base types.

@lfairy I think it is preferable to only have base as a dependency for data-default and keep the other instances (containers, dlist, old-locale) orphan. Every dependency adds a cost, so minimizing dependencies for data-default makes it ultimately more useful.

BTW, similar to @ndmitchell I would love to use data-default for hspec if we resolve this issue.

What would be the best way to merge them? Move all the code from ...-instances-base into ...-class and have ...-instances-base depend on ...-class (reexporting the instances)?

@mauke That seems reasonable to me.