Proposal: deepseq should not depend on containers

[Daniel Peebles]

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?

Dan

On Thu, Jan 6, 2011 at 11:23 AM, Iavor Diatchki <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> 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?
>>
>> Cheers,
>>        Simon
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20110106/81b7c853/attachment.htm>