Proposal: deepseq should not depend on containers
iavor.diatchki at gmail.com
Thu Jan 6 17:23:13 CET 2011
I agree with Johan that the dependency seems backward. "containers" is a
perfectly fine package but there is no reason to assume that everyone has
it. Consider, for example, a situation where I want to write a replacement
for "containers"---it would certainly be undesirable for my package to
depend on "containers".
On Wed, Jan 5, 2011 at 2:45 PM, Simon Marlow <marlowsd at gmail.com> wrote:
> On 05/01/11 22:10, Johan Tibell wrote:
>> On Wed, Jan 5, 2011 at 9:24 PM, Ian Lynagh<igloo at earth.li> wrote:
>>> However, I think types in the GHC bootlibs should be an exception to
>>> this rule. Otherwise any classes that someone wants the bootlibs to have
>>> an instance for will need to be added to the bootlibs, and we'd like to
>>> keep the set of bootlibs as small as possible.
>> What would happen if GHC HQ find an interesting package on Hackage and
>> put it in bootlib because they found it useful for GHC? Would that
>> library author then not be allowed to add new dependencies to his/her
>> package? I find that to be quite a weird model. Normally you don't get
>> to dictate what the respective authors of packages you depend on do
>> with their packages. (You can ask nicely of course.)
> Of course we don't get to dictate. If the library grew some dependencies
> that we couldn't put in bootlibs we have two options: stop using the library
> in GHC, or carry on using the old version.
> We already have one library like this: binary, which is shipped as
> ghc-binary so that users can install and upgrade binary without breaking
> GHC. The renaming is only necessary due to limitations in Cabal and the
> package system, which don't know that binary is only used internally in GHC
> and could safely be mixed with another version of binary without problems.
> The reason I want to get rid of the container dependency is that I
>> don't want the data structure package I'm working depend on another
>> data structure package that provides similar functionality. That
>> seems, weird. I'd rather just skip the NFData instances.
> It seems a little weird, but I don't think it has any undesirable
> consequences in practice, does it?
> Libraries mailing list
> Libraries at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libraries