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