Proposal: Strict types

[Roman Leshchinskiy]

Max Bolingbroke 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.

Yes, GHC won't rewrite in this case which is a big problem. The other big
problem is that strict types have much uglier laws than lazy ones. For
instance, fst (x,y) = x but strictFst (StrictPair x y) = y `seq` x. Strict
types lead a lot of seqs which are often quite artificial, disrupt other
optimisations because of the dependencies they introduce and prevent code
from becoming dead. In general, there seems to be a big difference between
"evaluate this now" (which is what strict types do), "it's ok to evaluate
this now" (which is what's needed for unboxing) and "this is guaranteed to
be evaluated at this point" (which strict types do, too, and which is
quite useful).

There is also http://hackage.haskell.org/trac/ghc/ticket/4081.

Roman