[Haskell-cafe] strict version of Haskell - does it exist?

[Austin Seipp]

The strict-ghc-plugin (under my maintenance) is just a continuation of
one of the original demos Max had for plugin support in the compiler.
The idea is fairly simple: 'let' and 'case' are the forms for creating
lazy/strict bindings in Core. It just systematically replaces all
occurrences of 'let' in Core with 'case'. So 'let b = e1 in e2'
becomes 'case e1 of { b -> e2 }', making 'b' strict. It also replaces
all applications of the form 'App e1 e2' (which is also lazy, as e2 is
evaluated on demand) with an equivalent binding like 'case e2 of { x
-> App e1 x }'. Pretty simple, and results in a totally strict
program.

The idea is just a proof of concept; in particular, I (and likely Max
although I cannot speak for him) am not using it as a position to say
that sometimes you want everything strict. You don't; at some point,
you're not even using Haskell anymore I suppose (remember: non-strict
semantics.) I can't think of any instance in which I would need or
want to use this plugin, honestly. But maybe someone else would - I
did refactor it to where you can strictify individual functions, as
opposed to full-blown modules, via annotations. So you could
selectively strictify things if you found it beneficial on certain
identifiers. But then there's the question of what affect that has on
the rest of GHC's optimizers, which I cant answer: the strictifier
modifies the pipeline to be the *first* pass, and the remaining ones
run afterwords. Compilers are built on heuristics and built for
'average' code. Sometimes these heuristics interact in odd ways,
especially with code that may deviate from 'the norm.' Once you're
fighting the optimizer, it can become a very difficult battle to win.
Careful analysis and selective optimization is probably going to take
you farther than hitting it with a giant hammer.

Having lazy and strict data structures and knowing when/where to use
them is crucial for good performance, and both have their merits (same
with every other thing under the sun, like by-ref/by-val semantics in
`data` types, which you can control with UNPACK etc.) I think we could
most certainly use better tools for analyzing low-level performance
details and the tradeoff between strictness/laziness and (especially
in large codebases,) but I don't think systematically making
everything strict is going to be the right idea in a vast majority of
situations.

On Sun, Jan 29, 2012 at 4:12 PM, Chris Wong
<chrisyco+haskell-cafe at gmail.com> wrote:
> On Mon, Jan 30, 2012 at 10:13 AM, Marc Weber <marco-oweber at gmx.de> wrote:
>> A lot of work has been gone into GHC and its libraries.
>> However for some use cases C is still preferred, for obvious speed
>> reasons - because optimizing an Haskell application can take much time.
>
> As much as any other high-level language, I guess. Don't compare
> apples to oranges and complain oranges aren't crunchy enough ;)
>
>> Is there any document describing why there is no ghc --strict flag
>> making all code strict by default?
>
> Yes -- it's called the Haskell Report :)
>
> GHC does a lot of optimization already. If making something strict
> won't change how it behaves, it will, using a process called
> strictness analysis.
>
> The reason why there is no --strict flag is that strictness isn't just
> something you turn on and off willy-nilly: it changes how the whole
> language works. Structures such as infinite lists and Don Stewart's
> lazy bytestrings *depend* on laziness for their performance.
>
>> Wouldn't this make it easier to apply Haskell to some additional fields
>> such as video processing etc?
>>
>> Wouldn't such a '--strict' flag turn Haskell/GHC into a better C/gcc
>> compiler?
>
> See above.
>
>> Projects like this: https://github.com/thoughtpolice/strict-ghc-plugin
>> show that the idea is not new.
>
> Not sure what that does, but I'll have a look at it.
>
>> Eg some time ago I had to do some logfile analysis. I ended doing it in
>> PHP because optimizing the Haskell code took too much time.
>
> That probably because you're using linked lists for strings. For
> intensive text processing, it's better to use the text package instead
> [1]
>
> Chris
>
> [1] http://hackage.haskell.org/package/text
>
>> Marc Weber
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe



-- 
Regards,
Austin