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?<div>
<br></div><div>Dan</div><div><br><div class="gmail_quote">On Thu, Jan 6, 2011 at 11:23 AM, Iavor Diatchki <span dir="ltr"><<a href="mailto:iavor.diatchki@gmail.com">iavor.diatchki@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hello,<div>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".</div>
<div>-Iavor</div><div><div></div><div class="h5"><div><br></div><div><br><div class="gmail_quote">On Wed, Jan 5, 2011 at 2:45 PM, Simon Marlow <span dir="ltr"><<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On 05/01/11 22:10, Johan Tibell wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, Jan 5, 2011 at 9:24 PM, Ian Lynagh<<a href="mailto:igloo@earth.li" target="_blank">igloo@earth.li</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
However, I think types in the GHC bootlibs should be an exception to<br>
this rule. Otherwise any classes that someone wants the bootlibs to have<br>
an instance for will need to be added to the bootlibs, and we'd like to<br>
keep the set of bootlibs as small as possible.<br>
</blockquote>
<br>
What would happen if GHC HQ find an interesting package on Hackage and<br>
put it in bootlib because they found it useful for GHC? Would that<br>
library author then not be allowed to add new dependencies to his/her<br>
package? I find that to be quite a weird model. Normally you don't get<br>
to dictate what the respective authors of packages you depend on do<br>
with their packages. (You can ask nicely of course.)<br>
</blockquote>
<br></div>
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.<br>
<br>
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.<div>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The reason I want to get rid of the container dependency is that I<br>
don't want the data structure package I'm working depend on another<br>
data structure package that provides similar functionality. That<br>
seems, weird. I'd rather just skip the NFData instances.<br>
</blockquote>
<br></div>
It seems a little weird, but I don't think it has any undesirable consequences in practice, does it?<br>
<br>
Cheers,<br><font color="#888888">
Simon</font><div><div></div><div><br>
<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
<br></blockquote></div><br></div>