Re: Proposal: Strict types

On Mon, Feb 21, 2011 at 11:04 AM, 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. Adding strictness to your program introduces extra case bindings at the Core level and therefore makes this problem more frequent. You can see this problem with the following program:

"""

g_f :: Bool -> Bool g_f y = y

{-# RULES "g/f" forall y. g (f y) = g_f y #-}

{-# NOINLINE f #-} f :: Bool -> Bool f = id

{-# NOINLINE g #-} g :: Bool -> Bool g = not

one x = g y  where !y = f x

two x = g y  where y = f x

main = do    print (one True, two True) """

GHC successfully rewrites "one" but not "two" using the RULE, so the output is (False, True).

Hmm... did you mean to say "two" but not "one"?

Max

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Work is punishment for failing to procrastinate effectively.