Hi,<br><br><div class="gmail_quote">2012/2/19 Bas van Dijk <span dir="ltr"><<a href="mailto:v.dijk.bas@gmail.com">v.dijk.bas@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>I do think it's better to integrate this into the deepseq package (and<br>
thus removing the default implementation of rnf). Otherwise we end up<br>
with two ways of evaluating values to normal form.<br></blockquote><div><br>I agree with this, and I guess many people are already using the deepseq package (simply because it was there first), so it would be better to integrate the generic code with that package. As for the backwards compatibility loss, it is indeed a pity that you are forced to choose between a generic default and a "normal" default, but I don't see any easy way to change that, and the current behaviour is simple and predictable. So I do not propose we change that. In this case I agree with Bas, and propose removing the "normal" default for `rnf`.<br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br></div>One last issue: Say I have a type like: "data T = C !Int"<br>
Currently GHC Generics can't express the strictness annotation. This<br>
means that your deepseq will unnecessarily evaluate the Int (since it<br>
will always be evaluated already). It would be nice if the strictness<br>
information could be added to the K1 type. (José, would it be hard to<br>
add this to GHC.Generics?)<br></blockquote><div><br>I don't think so; I think the right place to put it is as a method of the Selector class, though.<br><br>But, I'm wondering, for your example, wouldn't/couldn't GHC optimize away `seq` calls to strict arguments?<br>
<br><br>Cheers,<br>Pedro<br><br></div></div><br>