Proposal: deepseq should not depend on containers

[Simon Marlow]

On 06/01/11 17:06, Daniel Peebles wrote:
> Same here. Is it really that big a deal to add deepseq to the boot
> libraries? It seems like GHC might eventually want to use some of its
> own parallelism constructs for compilation, and then deepseq could be
> required anyway?

You're right, it's not a big deal, and I'm not arguing against Johan's 
proposal.

Cheers,
	Simon



> Dan
>
> On Thu, Jan 6, 2011 at 11:23 AM, Iavor Diatchki
> <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>> wrote:
>
>     Hello,
>     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".
>     -Iavor
>
>
>     On Wed, Jan 5, 2011 at 2:45 PM, Simon Marlow <marlowsd at gmail.com
>     <mailto: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
>             <mailto: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?
>
>         Cheers,
>                 Simon
>
>
>         _______________________________________________
>         Libraries mailing list
>         Libraries at haskell.org <mailto:Libraries at haskell.org>
>         http://www.haskell.org/mailman/listinfo/libraries
>
>
>
>     _______________________________________________
>     Libraries mailing list
>     Libraries at haskell.org <mailto:Libraries at haskell.org>
>     http://www.haskell.org/mailman/listinfo/libraries
>
>