Re: Proposal: Strict types

Max Bolingbroke wrote:

On 21 February 2011 02:28, Johan Tibell wrote:

...

On Sun, Feb 20, 2011 at 6:11 PM, Edward Z. Yang wrote:

...

I'm curious about how strict types interact horribly with fusion and other optimisations; I know strictness limits your optimisation ability, but my impression is that it shouldn't blow up too horribly unless you're trying to implement extremely clever optimisations.

I'm curious too. In my experience it often helps e.g. getting things unboxed.

I haven't seen what Roman is describing, but I would guess that it's something like if GHC sees:

let x = f y in g x

Then it can apply a rule g (f y) = foo. But if it sees:

case f y of x -> g x

It may get scared and not do the rewrite.

Yes, GHC won't rewrite in this case which is a big problem. The other big problem is that strict types have much uglier laws than lazy ones. For instance, fst (x,y) = x but strictFst (StrictPair x y) = y `seq` x. Strict types lead a lot of seqs which are often quite artificial, disrupt other optimisations because of the dependencies they introduce and prevent code from becoming dead. In general, there seems to be a big difference between "evaluate this now" (which is what strict types do), "it's ok to evaluate this now" (which is what's needed for unboxing) and "this is guaranteed to be evaluated at this point" (which strict types do, too, and which is quite useful). There is also http://hackage.haskell.org/trac/ghc/ticket/4081. Roman