Just for curiocity, is there a practically useful computation that uses 'seq' in an essential manner, i.e. apart from the efficiency reasons?<br><br>Abhay<br><br><div class="gmail_quote">On Wed, May 7, 2008 at 2:48 PM, apfelmus <<a href="mailto:apfelmus@quantentunnel.de">apfelmus@quantentunnel.de</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">Luke Palmer wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
It seems that there is a culture developing where people intentionally<br>
ignore the existence of seq when reasoning about Haskell. Indeed I've<br>
heard many people argue that it shouldn't be in the language as it is<br>
now, that instead it should be a typeclass.<br>
<br>
I wonder if it's possible for the compiler to do more aggressive<br>
optimizations if it, too, ignored the existence of seq. Would it make<br>
it easier to do various sorts of lambda lifting, and would it make<br>
strictness analysis easier?<br>
</blockquote>
<br></div>
The introduction of seq has several implications.<br>
<br>
The first problem is that parametricity would dictate that the only functions of type<br>
<br>
forall a,b. a -> b -> b<br>
<br>
are<br>
<br>
const id<br>
const _|_<br>
_|_<br>
<br>
Since seq is different from these, giving it this polymorphic type weakens parametricity. This does have implications for optimizations, in particular for fusion, see also<br>
<br>
<a href="http://www.haskell.org/haskellwiki/Correctness_of_short_cut_fusion" target="_blank">http://www.haskell.org/haskellwiki/Correctness_of_short_cut_fusion</a><br>
<br>
Parametricity can be restored with a class constraint<br>
<br>
seq :: Eval a => a -> b -> b<br>
<br>
In fact, that's how Haskell 1.3 and 1.4 did it.<br>
<br>
<br>
The second problem are function types. With seq on functions, eta-expansion is broken, i.e. we no longer have<br>
<br>
f = \x.f x<div class="Ih2E3d"><br>
<br>
because seq can be used to distinguish<br>
<br></div>
_|_ and \x. _|_<br>
<br>
One of the many consequences of this is that simple laws like<br>
<br>
f = f . id<br>
<br>
no longer hold, which is a pity.<br>
<br>
<br>
But then again, _|_ complicates reasoning anyway and we most often pretend that we are only dealing with total functions. Unsurprisingly, this usually works. This can even be justified formally to some extend, see also<br>
<br>
N.A.Danielsson, J.Hughes, P.Jansson, J.Gibbons.<br>
Fast and Loose Reasoning is Morally Correct.<br>
<a href="http://www.comlab.ox.ac.uk/people/jeremy.gibbons/publications/fast+loose.pdf" target="_blank">http://www.comlab.ox.ac.uk/people/jeremy.gibbons/publications/fast+loose.pdf</a><br>
<br>
<br>
Regards,<br><font color="#888888">
apfelmus</font><div><div></div><div class="Wj3C7c"><br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br>