Proposal: Strict types

[Gábor Lehel]

On Mon, Feb 21, 2011 at 11:04 AM, Max Bolingbroke
<batterseapower at hotmail.com> wrote:
> 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).

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


>
> Max
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>



-- 
Work is punishment for failing to procrastinate effectively.