Implementing Strict Core

[Gábor Lehel]

On Tue, May 7, 2013 at 6:38 PM, Johan Tibell <johan.tibell at gmail.com> wrote:

> Hi,
>
> All very good questions. Here's my current thinking on the matter:
>
> `a` and `!a` are compatible types. The compiler will insert the `seq`s
> where needed. I don't think this is useless.
>
> First, it serves as good documentation. Documenting strictness properties,
> e.g. as we do in the container library today, is awkward. Strictness
> annotations on types would make the documentation precise and succinct.
>
> Second, it's a bit more declarative than having put manually put bang
> patterns at the right places in the function definition and having to
> remember (and teach beginners) how to do that correctly..
>
> Third, it might help use generate better code, especially if we also
> implement Strict Core.
>

Right. I completely agree. The idea is attractive to me for the same
reasons. My questions basically relate to: how would you implement it?

Right now GHC's type checker works by solving type equality constraints.
Type equality is symmetric, and implies that the two types are
substitutable for each other in all contexts: there's no concept of "mixing
them up", because there's nothing to get mixed up, they are the same. But
`a` and `!a` aren't like that. You very much want to avoid mixing them up,
so you can insert `seq`s in the right places. But how would that mesh with
the present system?

Would you allow strictness annotations on type arguments in arbitrary
positions ([!Int] and so forth)? That leads to the issues regarding "how
could the compiler know how to strict-ify arbitrary types", and/or
co/contra/invariance of type parameters.


>
> I believe this is analogous to what Scala does for their by-value
> parameters, which types are preceded with a => annotation.
>

Looks like it's the reverse actually: http://stackoverflow.com/a/6297466


>
> Cheers,
> Johan
>
>
>


-- 
Your ship was destroyed in a monadic eruption.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130507/c69b8dfe/attachment.htm>