strict bits of datatypes

[Adrian Hey]

Simon Peyton-Jones wrote:
> | strict fields have no effect on deconstructing data types.
>
> That's GHC's behaviour too.  I think it's the right one too!   (It's 
certainly easy to explain.)

This reminds me of something I discovered about using strict fields in
AVL trees (with ghc). Using strict fields results in slower code than
doing the `seq` desugaring by hand.

If I have..

data AVL e = E
            | N !(AVL e) e !(AVL e)
.. etc

then presumably this..

case avl of N l e r -> N (f l) e r

desugars to something like ..

case avl of N l e r -> let l' = f l
                        in l' `seq` r `seq` N l' e r

but IMO it should desugar to..

case avl of N l e r -> let l' = f l
                        in l' `seq` N l' e r

which is what I ended up writing by hand all over the place
(dropping the strictness annotation in the data type).

That is, variables that have been obtained by matching strict
fields (r in the case) should not be re-seqed if they are
re-used in another strict context.

Now this explanation for the slow down I observed is just speculation
on my part (I don't actually know what ghc or any other compiler
does). But on modern memory architectures, forcing the code to inspect
heap records that it shouldn't have to inspect will be a bad thing.

So semantically I agree with "strict fields have no effect on
deconstructing data types", but they should have an effect on
the code that an optimising compiler generates IMO.

Regards
-- 
Adrian Hey