Proposal: Strict types

[Max Bolingbroke]

On 21 February 2011 02:28, Johan Tibell <johan.tibell at gmail.com> wrote:
> On Sun, Feb 20, 2011 at 6:11 PM, Edward Z. Yang <ezyang at mit.edu> 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).

Max